アジャイルでのスプリントテスト計画はどのくらい重要ですか？
現在のスプリントのテストを計画するだけのマスターテスト計画がある場合でも、すべてのスプリントのテスト計画を準備しています。私は次のようなトピックを含めています：
- 前書き
- 目的
- 機能の概要
- 範囲内
- アウトスコープ
- 仮定とリスク
- アプローチ
- テスト成果物
- テストタスクと提案されたスケジュール
最近、仲間や同僚と話し合ったところです。彼らはスプリントテスト計画を作成しないことを提案し、マスターテスト計画でカバーされています。スプリントテスト計画を作成せず、マスターテスト計画を続行しても問題ありませんか？
これで私が目にする最大の問題は、あなたがスプリントではなくミニ滝を見ていることです。上記の説明では、チームがすべてまたは何も提供しないように強制しています。スプリントに12のアイテムがあり、9を配信するとどうなりますか？つまり、行われたことをテストまたはリリースしないということですか？もしそうなら、私はあなたのリリーススケジュールを恐れています。チームメンバーが展開に失敗するワークアイテムを見逃すたびに、毎週の展開はすぐに数か月になります。
私の提案は、あなたが上に置いたすべての情報はすでに利用可能であるはずだということです。
- はじめに-スプリント名、日付、および目標-仕事完了！
- 目的-上記を参照
- 機能の概要-スプリント内のストーリーのリスト
- Inscope-上記のとおり
- Outscope-バックログから上記のものを差し引いたもの
- 前提条件とリスク-これは会社が何を期待しているかによって異なりますが、バックログの調整中にストーリーへのリスクをキャプチャできない理由はありません。繰り返しになりますが、重要なのは、それはストーリーへのリスクであり、リリースへのリスクではないということです。製品/チームのリスク管理は、スプリントフレームワークの外で処理する必要があります。
- アプローチ-ストーリー自体の一部
- テスト成果物-ストーリーをテストせずに提供できますか？
- テストタスクと提案されたスケジュール-上記のとおり
私が強調しようとしている点は、これらの情報はすべて、スプリントへのリンクまたはストーリーへのリンクのいずれかを介して、それを望むすべての人が利用できるようにする必要があるということです。
私の最大のアドバイスは、テストはフェーズではなく、ストーリーを完成させるために必要なタスクの1つです。開発作業を特定すると同時に、各ストーリーで行うテストを特定します。
それは多くの「私は...である必要がありますか？」の質問への回答であるため、「依存する」で質問に回答するのは非常に魅力的です。
ただし、この場合の答えはnoです。スプリントテスト計画は作成しないでください。少なくとも、正式なものではありません。スプリントに必要な唯一のテスト計画は、「完成したすべてのストーリーが十分にテストされていることを確認する」ことです。
スクラムチームのQAエンジニアとしての責任の一部は、製品の所有者および開発者と協力して、スプリントが始まる前に適切な受け入れ基準を特定することです。したがって、スプリントの開始時には、各ストーリーの承認基準によって表される計画がすでにあるはずです。