3人の開発者からなるスクラムチームには、専用のテスターがいます。現在、テスターは2週間のスプリントの最初の週のほとんどで何かがテストされるのを待っているようです。通常、スプリントの最初のリリースは、スプリントの第1週の木曜日または金曜日に行われます。この時点で、テスターは初期のソフトウェアを「テスト」できます。
これは私の頭の中に疑問を投げかけます-このような機能テストは、成果物の開発の早い段階でどれほどの価値があるのでしょうか？
開発のこの段階（スプリントの第1週の終わり）では、通常、重大なバグ/機能の欠落があり、テストが数日（たとえばスプリントの第2週）だけ延期された場合に修正されます。
この場合のベストプラクティスは何ですか？
優れた管理手法であるスクラムについて言及している間は、使用しているテスト手法については説明していません。
ベストプラクティスを使用している場合は、テスト駆動開発を使用する必要があります。
テスト駆動開発とは、テストを最初から行う必要があることを意味します。プログラマーは、テストを作成し、それらのテストに合格するクラスに入力する必要があります。
テスターは、アプリケーションが1日目に絶対に合格しなかった1日目に機能テストを作成する必要があります。最終的に、アプリケーションはこれらのテストに合格し始め、スプリントが完了したと呼ぶことができます。
テスト駆動開発を行っていない場合は、そうする必要があり、テスターは統合テストケースを作成する必要があります。
テスターがコーディングできない場合は、コーディングを教えてください。コーディングできるテスターが必要です。そして、 1日目に機能テストのコーディングを開始させます。
テスターは、仕様を確認し、テストスクリプト/受け入れ基準の手順を記述している可能性があります。
開発者はタスクを完了しようとしていますが、チェックイン前にミニテストレビューを行うこともできます。つまり、開発者が作業を完了しているときに5分間の目玉を使用すると、いくつかのバグが発生することがよくあります。
既存のアプリケーションを常にテストしています（これが新製品の最初のスプリントではないと想定しています）。常にバグを見つける必要があります。
次に、既存のバグのトリアージがあります。優先度が高いか低いかです。
次に、開発者が修正したバグのテストとクローズがあります。
もちろん、最も重要なのは、コーヒーを淹れ、手を上げた開発者の熱狂的な眉を拭くことです。
製品バックログの問題を発見しました。テスト可能/リリース可能なコードがない状態で3日間コーディングしている開発者が3人いる場合は、ストーリーが大きすぎます。これは、この事実をバーンダウンに反映していることに注意してください。フラットライン->スプリントの終わりに大きなドロップ。統合は、テストに常に利用できる新しい機能を備えた日常業務である必要があります。
上記に同意します。春のユーザーストーリーを選択するときは、それらがどのようにテストされるかを定義し始める必要があります
どうですか：
手作業でテストされた最後のスプリントからのストーリーテストの一部を自動化します
テストデータ（および/またはマシン）の設定を自動化して、次の回帰テストをより迅速に実行できるようにします。
いくつかのストーリーのテスト仕様を作成して、開発者がそれらのストーリーを実行するときに、より良い情報を入手できるようにします。