スキルアップ
テストマネジメントの勘所 ~欠陥マネジメント会議~

はじめに
立案したテスト計画通りに、テストは完了していますか?
私は、コンサルタントとしてさまざまなテストの現場を見てきていますが、テストが計画通りスムーズに進んでいる現場が多いとは言えません。
それはなぜでしょうか?
1つ目は、リスクが適切に識別されていないためにリスクマネジメントがうまくいかず、発生したプロジェクトの問題に対して対処的にアプローチしているケースが挙げられます。2つ目は、適切にリスク識別は行われているもののリスクマネジメントが上手でないため、リスク軽減を含むリスクへの対応がうまくいっていないケースです。
いずれにしても、テストマネジメントをうまくやるためには、リスクマネジメントは非常に重要な要素となります。
今回は、テストマネジメントの勘所として、特にテスト実行における欠陥マネジメントについて、私がこれまで重視してきた「欠陥マネジメント会議」の活用を説明したいと思います。
なぜ欠陥マネジメントが重要なのか?
冒頭、テストマネジメントにおいてはリスクマネジメントが重要であることを書きました。では、なぜ欠陥マネジメントを取り上げるのかを説明します。
それは、テスト対象で検出される欠陥はテストプロジェクトの成功を目指すのに、最も影響のあるリスク要因の1つであるためです。当たり前のことですが、欠陥はソフトウェアのどこにいくつ存在しているか、ソフトウェアを動かさなければ分かりません。そのため時間とコストをかけてテストを行うのです。
もちろん、欠陥は全くコントロールできないリスク要因なのかというとそうではありません。例えば、組織にて蓄積されたメトリクスを活用して統計的アプローチにより存在しているであろう欠陥数を予測したり、統合テストまでのテスト結果を分析することで、どのモジュールに欠陥が残存していそうかを予測して、以降のテストレベルの活動にて対策を立てたりすることはできます。
しかし、基本的にはテスト対象のどこにいくつ欠陥が存在しているかは分からないのです。
通常、欠陥が検出されると、欠陥レポートを起票して、対象のテストケースのテスト結果を「Fail」にします。加えて、その欠陥の影響でテスト実行できない、もしくはテスト実行しても(欠陥修正により)意味がなくなってしまうテストケースを「Block」ステータスに設定すると思います。
プロジェクトの規模が小さい場合や、テストプロセスの成熟度が低いプロジェクトでは、関連するテストケースをBlockに設定まではしないこともあるようです。
その後、欠陥が修正されると、確認テストを行った上で、Blockしていたテストケースを実行していくという運用をするプロジェクトが多いかと思います。
欠陥がどこにあるか分からない以上、これらの欠陥検出のタイミングや回数を完全にコントロールすることはできません。そういう意味で欠陥マネジメントが、テストプロジェクトを成功に導くため重要な要素の1つだと言えるのです。
欠陥マネジメント会議とは?
欠陥マネジメント会議(※1)は、多くの場合、テストチームの代表者、開発チームの代表者をはじめ、プロジェクトマネージャなど欠陥に関心があるステークホルダを集めて行います。この会議では、欠陥レポートを基に対応の要否や、対応する場合の優先度などを議論し、決定します。
これまで私がコンサルタントとして見てきたプロジェクトでは、この欠陥マネジメント会議は、必ず行われているものではなく、むしろ行われている割合の方が少ないように感じます。また、行われていた場合でもテストチーム内、もしくは開発チーム内だけで行われており、上記の説明とは異なる目的で行われていることが多いようです。
この欠陥マネジメント会議をどれだけ有効に活用できるかが、テストプロジェクトの成功に大きな影響を与えます。そのため、もし行われていないのであれば、独立したテストチーム(※2)が主導して行うことを強くお勧めします。
(※1)「ISTQB® テスト技術者資格Advanced Level シラバス日本語版 テストマネージャ」(2024年5月時点ではVersion 2012.J04)では「欠陥マネジメント委員会」が開くミーティングとして説明されています。
(※2) 「テスト技術者資格制度 Foundation Levelシラバス」(2024年5月時点ではVersion 2023V4.0.J01)では、テストの独立性として4段階のレベルが説明されています。そのうち「作成者のチーム外だが組織内のテスト担当者が行う場合(独立性が高い)」および「組織外のテスト担当者が行う場合(独立性がとても高い)」の場合をここでは想定しています。
欠陥マネジメント会議をどのように有効活用するか?
私は、この欠陥マネジメント会議を、欠陥の対処要否や対処優先度の情報を得るほかに、欠陥修正のスケジュール、欠陥の影響範囲、他の欠陥との関連性などを得るために活用しています。従って、この欠陥マネジメント会議の主導もテストチームが行った方が良いと考えています。
自分で設計・実装したプログラムであれば、これらの情報は会議をしなくとも入手できますが、特に独立したテストチームの場合には、故障となって表面化している現象から想定できる情報には限度があります。
この会議で取得した情報は、その後のテスト実行のマネジメントで活用していきます。具体的には以下です。
欠陥の修正スケジュール:
テストで欠陥が検出された場合、その欠陥の影響でテスト実行できない、もしくはテスト実行しても(欠陥修正により)意味がなくなってしまうテストケースを「Block」として管理します。そのBlockしている(つまり現在実行対象外となっている)テストケースがいつから再び実行可能(Block解除)となるのかの重要な入力情報となるため、その予定を加味してテスト実行スケジュールを変更します。
欠陥の影響範囲:
先にも記述しましたが、特に独立したテストチームがテストを行っている場合、見つけた故障から想定できる影響範囲は限度があります。そのため、限られた情報のみに頼ってテスト実行をコントロールしていると、特定の欠陥を修正したことにより、すでに実行済みのテストをやり直す必要も出てきてしまいます。これを極力避けるために、欠陥マネジメント会議で獲得した情報を基に、より精緻なテストケースのBlock情報を設定します。
他の欠陥との関連性:
Blockしているテストケースは必ずしも1つの欠陥で実行不可となっているわけではありません。一方で、欠陥レポートとして管理しているのは原則個々の欠陥になります。そのため、開発チームではそれぞれの欠陥について、例えば修正の難易度やユーザへのインパクトなどを基に修正の計画を立てて、実際に修正していくことになります。
テスト全体を成功させるために、この修正計画に対してテストチームとして提案します。テストチームが主張すべきは、効率的かつ効果的にテスト実行するための、欠陥の修正順序です。ここで「効率的かつ効果的」と表現したのは、テストがより早く終わる順序(効率的)だけを考慮していては駄目で、効果的な側面も考える必要があります。
ただし、Blockされているテストケースが多い順に欠陥の修正順を提案すればよいという話ではありません。例えば、該当の欠陥が他の欠陥と比較して、あまりテストがされていない機能領域で発生しているものであれば、その欠陥の修正優先度を上げて、該当する機能のテストを進めることで、一定の確信度合いを獲得するといった具合にです。その時点のテストプロジェクトのさまざまな状況を考慮して欠陥の修正順序を検討する必要があります。
そのため、欠陥マネジメント会議にはテスト計画、テストケースの全体、テストプロジェクトの状況を一番理解しているテストマネージャが参加して、会議を主導していくことを強くお勧めしているのです。
さいごに
今回は、テストマネジメントの勘所として、欠陥マネジメント会議の活用を説明しました。テストプロジェクトを成功させるためには、テスト分析やテスト設計の技術はとても大事です。同様にテストの全体像を把握した上で、その時々のテストプロジェクトの状況を考慮し、以降のテスト計画を見直し続けるテストマネジメントの技術も非常に重要となります。
特にテストマネージャの方は、テストチームのパフォーマンスと成果を最大化するようにしっかりとテストマネジメントの技術を勉強して身に付けることをお勧めします。
この記事は面白かったですか?
今後の改善の参考にさせていただきます!