自動テストの作成を開始する必要があるのは、アジャイルのどの段階（SCRUM）ですか？

私のちょっとした背景-私はSCRUM（1〜2週間のスプリント）を使用したアジャイル環境内で約2年間、手動テスターです。そこで、Selenium WebDriver（Javaを使用）を使用した作業に自動化テストを導入したいと思います。

私の質問は、いつ機能を手動でテストする必要があるか、いつ自動化テスト用に変換する必要があるかです。

私は次のようなさまざまなアプローチを読んでいます。

1. 新しいスプリントの開始時に、ユーザーストーリーを以前のスプリントの自動スクリプトに変換するか、または
2. 同じスプリント内でユーザーストーリーを変換します。

アドバイスは非常にいただければ幸いです。前もって感謝します。

テストの自動化（および他のすべてのテスト）は、doneの定義の一部である必要があります。これは潜在的に出荷可能な製品を作るためです。テストされていない場合は発送できますか？

テストはチーム全体のアプローチであるべきなので、テストの自動化はテスターの責任ではありません。プロセスのできるだけ早くテストについて考え始めます。

アジャイルでは、テストの自動化が非常に重要です。

組織の俊敏性は、技術の敏捷性によって制約されます

言い換えると、製品の変更が遅い場合、チーム、組織、または採用するフレームワークをどのように構成しても、変更への対応が遅くなります。

https://less.works/less/technical-excellence/index.html

テストを次の反復まで延期すると、常に遅れが生じます。製品の外部動作をリファクタリングおよび保護することが困難になるため、製品の方向を変更することが困難になります。反復的な手動テストを行うことが、速度を落とし、自動化する鍵です。

多くのテスターは、製品のインターフェースが安定するまで、エンドツーエンドでテストを開始しないように指示します。待つのではなく、代わりにPageObjectsを十分に活用して、テストが保守可能であることを確認し、テストを作成して修正することを開発者の責任にするようにしてください。

重要なことは、そのストーリーの自動テストを作成しない限り、ストーリーを完了としてマークしないことです。

したがって、前のスプリントで完了したタスクのテストを書いているので、1は出ていないようです。テストが失敗した場合はどうなりますか？

理想的には、コードが書かれているのと同じスプリントで自動テストを書くべきです。自動テストが作成されるまで、コードは「完了」と見なすべきではなく、スプリントの終わりまでにコードを「完了」状態にする必要があります。

スプリントの初日に、開発者と協力してコードを理解し、テスターとしてのニーズを理解できるようにして、プロセスを開始する必要があります。たとえば、Webページを構築している場合、対話する必要のあるすべてのページ要素に一意の識別子を追加する必要性を理解してもらうことができます。

スクラムでは、あなたの仕事はテストを書くことではないことを覚えておいてください。あなたの仕事は、チームと協力してスプリントの目標を達成することです。これは、コミュニケーションとコラボレーションを意味します。これは、スプリントの非常に早い段階で行われる必要があります。コードをテストする準備ができる前に、テスト設計とテスト計画の作業を開始できます。

自動的にテストする場合は、事前にテストを作成することもできます。これは、期待する動作を定義するのに役立ち、クライアントのように考えるように刺激します。これにより、最終的にソフトウェアがより使いやすくなります。また、機能を実装しているので、すぐにテストを利用できます。

どちらでも実行できますが、通常は自動化テストを使用して回帰テストをターゲットにします。それは、あなたがそれが回帰テストになるのに十分堅固であると確信するまで、私が手動で行うことを意味します。これは、一部の機能ではスプリントの途中である可能性があり、他の機能では将来のスプリントになる可能性があります。

別の回答で述べたように、テストが発生したときは、完了の定義の一部である必要があります。しかし、私はその答えのいくつかに同意しないので、私は遭遇した経験で拡大したいと思いました。

真にアジャイルな環境では、誰もがすべてを行うことができます。100％テストに専念する人はいないでしょう。基本的なUI作業などを支援するスキルも身につけます。しかし、私たちはめったに理想的な世界に住んでいません。

私がお勧めするのは、少しハイブリッドなアプローチをとることです。完了の定義については、手動テストは作業がコード化されているSprintの一部である必要があると思います。それは機能し、Sprintが終了する前にバグをすぐに報告し、場合によっては修正して、次の計画を立てることができます。 1。手動テストに焦点を当てることで、コードが何をすることになっているかに慣れることができます。次のSprintの始めに、実行することがそれほど多くない可能性がある場合は、自動化されたテストをセットアップして、ビルドプロセスの一部として実行し、回帰エラーを防ぐことができます。