JSTQB(ALTM) シラバス学習：4 欠陥マネジメント
2019.08.17更新
- 4.1 イントロダクション
- 4.2 欠陥ライフサイクルとソフトウェア開発ライフサイクル
- 4.2.1 欠陥ワークフローと状態
- 4.2.2 無効および重複した欠陥レポートのマネジメント
- 4.2.3 クロスファンクショナルな欠陥マネジメント
- 4.3 欠陥レポート情報
- 情報の内容
- 4.4 欠陥レポート情報によるプロセス能力の評価
4.1 イントロダクション
ソフトウェアの開発ライフサイクルでは、発生した欠陥をどのようにマネジメントするかが、当該プロジェクトおよび将来のプロジェクトの発展のために重要となります。
テストマネージャは以下について適切なアプローチを行い、テストプロセスやソフトウェア開発プロセスについて継続的な改善を行います。
- 取得すべき重要データへの精通
- 長期的なデータの収集と分析
- 使用する欠陥マネジメントツールの選択
4.2 欠陥ライフサイクルとソフトウェア開発ライフサイクル
欠陥は成果物を作成するときに人が犯す誤りから混入します。
欠陥はソフトウェア開発ライフサイクルのいずれの場所にも混入する可能性があるため、常に欠陥の検出と除去をするための活動が必要となります。
欠陥は早い段階で、できれば混入と同じフェーズで検出と除去が行われるほど品質コストは低下します。品質コストは欠陥自体を直接見つける静的テストの方が低くなります。動的テストでは、偽陽性や偽陰性でデバッグに時間がかかる可能性があり、コストが高くなる傾向があります。
静的テスト（欠陥を見つける）
- 要求仕様
- ユーザストーリー
- テクニカルドキュメント
- テストケース
- プログラムコード
動的テスト（故障を見つける）
4.2.1 欠陥ワークフローと状態
欠陥レポートはテスト担当者が正確にレポートして、ソフトウェア開発者が欠陥を解決していくために必要な情報です。RedmineやBugzillaなどが多く使われます。
欠陥状態の遷移
初期状態：オープン、新規
一人または複数のテスト担当者が不正を再現させるための情報を収集します。
返却状態：拒否、明確化
テスト不十分によるレポートの受け入れ拒否、または再現情報の追加収集を依頼されています。
確認テスト状態：解決済み、検証
確認テストで修正内容の確認をします。
確認テストの結果により状態をクローズまたはオープンに遷移させます。
終了状態
- クローズ：欠陥が解決して確認テストによる検証が終了
- キャンセル：無効な欠陥レポートと判断
- 不再現：不正・故障が観察できない
- 延期：欠陥をそのプロジェクト内で修正しない
4.2.2 無効および重複した欠陥レポートのマネジメント
不正（結果と期待値が異なる）が欠陥の兆候としてではなく、何らかの誤解により発生する場合があります。できるだけ正確なレポートの発行が必要ですが、誤りの排除を意識しすぎるとレポート発行が遅れたり、未発行となる要因にもなるので対策を行う場合は注意が必要です。
誤解が生まれる要因
- テスト環境
- テストデータ
- テストウェア
- テスト担当者
終了方法
- 無効：偽陰性となった欠陥レポートはキャンセルあるいはクローズします。
- 重複：不正の兆候は異なるが根本原因が同じと判明した場合はクローズします。
4.2.3 クロスファンクショナルな欠陥マネジメント
クロスファンクショナルなチームは、欠陥レポートのマネジメントを部門横断的に担当します。欠陥マネジメント委員会は、不正が欠陥マネジメントツールに登録されると、欠陥を解決する場合と解決しない場合に生じるメリット、リスク、コストから解決すべきか判断します。
解決すると判断された欠陥は、相対的な重要度から優先度を決めて解析を進めます。
欠陥を効率的に解決するには、以下のすべてをバランス良く取り入れることが必要です。
- コミュニケーション
- 欠陥追跡ツール
- 欠陥ライフサイクル
- 欠陥マネジメント委員会
4.3 欠陥レポート情報
欠陥あるいは故障を観察した場合には、プロジェクト全体で意味ある比較ができる情報を収集して欠陥レポートに登録します。
情報の内容は対面的なコミュニケーションで補足できたとしても、適切にアセスメントするという点では、すべての情報は、完全、簡潔、正確、客観的、適切、タイムリーに欠陥レポートに記録されることが重要となります。
情報の目的
- 欠陥ライフサイクル全体でのレポートのマネジメント
- プロダクトの品質とテスト進捗に関するプロジェクトステータスのアセスメント
- プロセス能力のアセスメント
情報の用途
欠陥データは以下に示すような分析を行い、テスト進捗のモニタリング、コントロール、終了基準の評価をするために使用できます。
- 欠陥密度分析
- 解決した欠陥の傾向分析
- 検出から解決までの平均時間
- 故障強度
情報の内容
収集する必要のある情報は、ISO9126、IEEE829、IEEE1044などを参考にできます。
- 発見者の名前
- 発見者の役割（エンドユーザ、開発者、など）
- 発見したときのテストタイプ（性能テスト、回帰テスト、など）
- 問題の概要
- 問題の詳細
- 故障の再現手順、実際の結果と期待する結果、ログ、など
- 欠陥の混入、検出、除去が発生したライフサイクル
- 欠陥が混入した成果物
- ステークホルダへのインパクトの重要度
- 問題解決の優先度（ビジネスインパクトによる）
- 欠陥が存在するサブシステムまたはコンポーネント
- 問題検出時のプロジェクト活動
- 問題検出時の識別方法（レビュー、動的テスト、など）
- 欠陥の種類
- 欠陥により影響を受ける品質特性
- 欠陥を観察したテスト環境
- 問題が存在するプロジェクトとプロダクト
- レポートの所有者（レポートが最終状態にない場合）
- レポートの状態
- 問題を観察した成果物、解決した成果物
- 問題解決のためのアクションに関する結論、提案、承認
- 欠陥を解決する場合としない場合のリスク、コスト、機会、メリット
- 欠陥ライフサイクルの遷移が発生した日付とそのときのアクションなど
- 解決した方法の説明と解決策をテストするための方法
- 欠陥を観察したテスト、リスク、要件、など
4.4 欠陥レポート情報によるプロセス能力の評価
テストプロセスの効果と効率を評価するため、欠陥レポートが何を意味するのか見極める必要があります。メトリクスが示すプロセスの状態を正確に理解して、テストプロセスとソフトウェア開発プロセスの能力の評価やプロセス改善の取り組みを行います。
プロセスの改善
検出効率改善
欠陥総数改善
-
混入情報から、最多数の欠陥が混入したフェーズを分析して欠陥の総数を削減する
-
根本原因情報から、欠陥混入の基となる理由を分析して欠陥の総数を削減する
コスト改善
-
混入、検出、除去の情報から、品質コストを分析して欠陥により発生するコストを最小化する
欠陥の追跡
欠陥は根本原因まで追跡すべきですが、効率性やプロセスオーバーヘッドなどのコストを削減する名目で追跡をしないことがあります。しかし、これらの行為は信頼できるデータを残さないことを意味し、プロセスの改善の実行を困難にします。そのため、状況に応じてリスク分析して判断する必要があります。
また、事象から根本原因の特定が難しく、暫定的に根本原因の除去はせず事象のみ対処するケースもあると思います。しかし、表に見える事象は1つではない可能性があるため、除去を延期した場合でも確実に根本原因を特定して早急に対処する必要があります。これは、プロセスの改善だけではなく、重大な欠陥が隠れていることによってプロダクトリスクが発生することを防ぐ目的でもあります。
