欠陥マネジメント
欠陥マネジメントは、欠陥の検出、報告、追跡、解決、再発防止を行うプロセスです。
静的テストについても同様の方法で処理する必要があります。
欠陥のライフサイクル
欠陥のライフサイクルは以下になります。
認識
テスターが欠陥を発見し、欠陥レポートを作成します。
原因やスケジュールへの影響などを分析します。
調査
テストマネージャーが欠陥の有効性を確認し、必要に応じて追加情報を収集します。
原因を追求し、影響範囲を調査します。
対応
欠陥が有効である場合、開発者に割り当てられ、修正が行われます。
修正することによる影響範囲も調査します。類似の欠陥の予防などがあります。
処理
修正が完了した後、テスターが再テストを行い、欠陥が解決されたかを確認します。
欠陥ワークフロー
欠陥を検出してから完了するまでのワークフローを欠陥ワークフローといいます。
以下のようなワークフローになります。

初期(オープン)
初期の状態で、テストチームが実施して欠陥を再現できるように必要な情報を収集している状態です。
欠陥管理ツールを使用している場合、登録した状態になります。
プロジェクトによっては、登録すべきかの選別を事前にする場合もあります。
選別
登録されたインシデントを選別します。
プロジェクトマネージャ・テストマネージャー・テストリーダーなどがインシデントを確認してステータスを変更します。
拒否
テストチームに対応が必要か更なる情報を求めている状態です。
テストチームは、対応の可否または必要な情報を収集してステータスを変更します。
延期
現在のテストプロジェクトまたはテストレベルでは実施しせず、対応を延期します。
一旦、インシデントはクローズします。
解決
開発チームは、インシデントを解決するように対応します。
情報が不足していたり、対応が難しい場合はテストチームに返却します。
確認テスト
インシデントが対応されて確認できる状態です。
テストチームは、修正された成果物を確認して問題がなければクローズします。
再オープン
確認テストで修正されたことを確認できなかった場合は、再オープンします。
確認テストで問題がなくクローズしてもその後のプログラムのアップデートなどでデグレートした場合は再オープンする場合もあります。
欠陥ワークフローの注意事項
テストチームは、欠陥ではないインシデントやすでに起案済みの欠陥を登録してしまう場合があります。
これらは不要な作業で無駄な工数が発生していますが、完全に排除しようとすると欠陥を見逃したり欠陥起票が遅れたりします。
クロスファンクショナルな欠陥マネジメント
テスト組織とテストマネージャは、欠陥マネジメントプロセスとツールを所有し管理しますが、特定のプロジェクトの欠陥マネジメントはクロスファンクショナルチームが担当します。
欠陥マネジメント委員会には、開発者、プロジェクトマネージャ、プロダクトマネージャなど利害関係者が参加します。
欠陥が発見されツールに登録されると、委員会は欠陥が有効で解決すべきかを判断し、メリット、リスク、コストを慎重に検討します。
解決を決定した場合、欠陥の解決活動の優先度を他のタスクと比較して設定します。
ただし、優れたコミュニケーションと欠陥追跡ツールの使用は欠陥マネジメント委員会のミーティングを完全に置き換えるものではありません。
欠陥レポート
欠陥レポートには、欠陥を検出した担当者がデータを収集します。
欠陥レポートには以下の目的があります。
- 欠陥ライフサイクル全体のレポートマネジメント
- プロジェクトステータスのアセスメント
- プロセス能力のアセスメント
欠陥データは、テスト進捗のモニタリング、コントロール、および終了基準の評価に使用され、欠陥密度分析や傾向分析に役立ちます。
収集される欠陥データには、発見者の名前、役割、問題の概要・詳細説明、ライフサイクルフェーズ、解決優先度など多岐にわたる情報が含まれます。
この情報は、静的テスト、動的テストを問わず、欠陥の特性や影響を評価し、適切かつ一貫した報告を行うために重要です。欠陥データの正確な収集と報告は、プロジェクトの進行管理、品質評価、およびプロセス改善に不可欠です。
テストマネージャーは、テスト担当者に欠陥をレポートさせる場合に以下が重要であることを伝えます。
- 完全
- 簡潔
- 正確
- 客観性
- 適切
- タイムリー
偽陽性と偽陰性
テストを実行して結果が正常だった場合を陰性といい、欠陥だった場合を陽性といいます。
実際に正常と報告して、欠陥を検出できなかったことを偽陰性といいます。
欠陥と報告しましたが、欠陥でない場合を偽陽性といいます。