この記事はCarol Brandsによるゲスト投稿です。
以前に、難航するプロジェクトでどのように リリース日に間に合わせるための最小限のテストを決めたかについて書きました。 次のリリースで同じ罠にはまらないためには、何ができるでしょうか。
今回の記事は、リリース後のテストで、今後、納期による困った事態を避けるのに役立つかもしれない、実践中の新しいアプローチを紹介します。
問題の確認
最優先事項は、そもそも、このプロジェクトに至るまでに背後でどのようなプロセスが動いているかを認識することでした。次の3つの課題が判明しました。
1. バックログアイテムが作成されてからテスターに渡されるまでの間に充分なレビューを経ていなかった
プロジェクトではおおむね、プロダクトマネージャーが開発マネージャーと共同でバックログアイテムを作成していました。マネージャーたちは、実装を指示しなくても理解とテストが可能な受け入れ条件を定義することに取り組みました。しかし、そのバックログアイテムはテストチームにとって不明な点があることが多かったのです。
受け入れ条件は、単独では問題がないが、他の作業や連携する機能を考慮すると調整が必要な場合もありました。バックログの大半は、既存の製品に関連して定義されたものでしたが、既存の製品で可能なワークフローが考慮されていないケースが多々ありました。
このような問題が開発のテストフェーズで見つかることは、さまざまな混乱を意味しました。テストチームは次々と欠陥レポートを作成し続けており、すべてのバックログアイテムをまるごと開発チームに戻さなければならないこともよくありました。
2.テスターだけがテストを担当していた
開発の初期段階で、開発チームの処理能力がテストチームの処理能力を上回っていることがあきらかになりました。プロジェクトに開発者は5人いるのに対して、テスターは2人だけでした。開発はテストチームが入るずっと前から始まっていたので、私たちテストチームがプロジェクトに手を付けたときには、すでに50個のストーリーが「テスト待ち」の状態でした。
当初は、すべてのストーリーのテスト優先度は同じだと考えていたので、一番古いストーリーから始めて、積まれた作業をこなしていこうとしました。時間が経つにつれて、開発チームの作業に追いつけないことが明白になってきました。そこで、最近開発されたストーリーからテストしていくことに方針を変更したのです。これで状況は改善されましたが、開発者の数はテスターの倍以上だという事実はどうやっても覆せませんでした。これに、テストフェーズに入る前のバックログアイテムのレビューが不十分だったという問題が合わさったのです。
3.欠陥はたまにしか優先順位付けされず、ディスカッションではなく欠陥レポートによって優先順位付けされていた
テストサイクルが終わるころには、どの変更をリリースに含めるかを慎重に判断する必要がありました。不要な変更を含めると、修正とテストの時間がかかりますが、その時間はありませんでした。
プロダクトマネージャーが欠陥をレビューして、修正するべきものと先送りにするものを決定できるよう、潜在的な欠陥をすべて文書化する必要があると私たちは判断しました。それまでバックログアイテムがテスターのレビューを受けていなかったため、多数の欠陥が見つかりましたが、間近に迫ったリリース期日や他の重要タスクのために忙しいプロダクトマネージャーがそれらの欠陥をレビューできるよう、詳しくレポートする必要がありました。
混乱を解消する
私たちの業界では、リリースと初回の販売の間にいくらかリードタイムがあるのは珍しいことではありません。リリース日までのステークホルダーの話し合いで、このリードタイムを使って追加のテストを完了させるという案について議論しました。そして、この機会に、新しいやり方を試すことになりました。
まず、すべての開発者にテストに対する支援を求めました。開発者にはいくつか基本的な指示が出されました。
- ローカル環境でいわゆるHappy Path（例外やエラーが発生しないシナリオ）をテストするのではなく、テスト環境を使って徹底的に検証すること。
- 何をテストしたかを書き留めること。「この特定のシナリオをテストしましたか？」という質問に答えることができなければなりません。
- 欠陥を見つけたら、まずプロダクトマネージャーに話をすること。
- 欠陥が修正されることになった場合、ごく基本的な欠陥レポートを作成すること――プロダクトマネージャーがリリースノートに書く時の元になるような記述で十分です。
- 欠陥が先送りされることになった場合、将来欠陥に関して決断を下すとき、判断の基礎となる十分な情報があるよう、詳細な欠陥レポートを作成すること。
このようなやり方を採用したことで、開発者のテストに関する理解が深まり、バックログアイテムのテストに責任を持つことが習慣になったほか、開発およびテスト中に行われるコミュニケーションが増えました。これは、テストフェーズをテスターにだけ関係するものとして扱うのではなく、開発者を開発プロセス全体に巻き込むためのすばらしい第一歩であるように思えます。
私たちは、開発に入る前にテスターをバックログのレビューに参加させ、テスターの処理能力を超える「テスト待ち」ストーリーのバックログが発生したら、開発者にもテストフェーズへの参加を求めることで、次のプロジェクトでもこのプラクティスを繰り返していきたいと考えています。このプロジェクトが終わりに近づくにつれて、過ちから学んだレッスンに感謝しています。
Carol Brandsは、DNV GL Softwareのソフトウェアテスターです。出身はニューオーリンズですが、オレゴンで生活するようになって13年になります。Association for Software Testingのボランティアも務めています。
（この記事は、開発元Gurock社の Blog 「Tester’s Diary: Getting Ahead With Post-Release Testing」2019年7月16日の翻訳記事です。）