欠陥マネジメントの目的
欠陥マネジメントは、検出した欠陥を確実に修正まで導くことと、欠陥データを分析して プロセス改善の材料にすることの2つを目的とします。単なるバグ票の管理ではなく、 プロダクトとプロセスの品質を可視化する活動です。
欠陥レポートに書くべきこと
良い欠陥レポートの条件は「開発者が最短で再現・修正できる」ことです。
- 再現手順（期待結果と実際の結果を対比する）
- 発生環境（OS・ブラウザ・ビルド番号など）
- 重要度（severity: プロダクトへの影響）と優先度（priority: 修正の緊急性）
- ログ・スクリーンショットなどの証跡
重要度と優先度の区別は定番の出題ポイントです。「軽微な表示崩れだが、デモで真っ先に 目につくので優先度は高い」のように、2つは独立に決まります。
欠陥ライフサイクル
欠陥は状態遷移で管理します（名称はツールにより異なります）。
新規 → 割り当て済み → 修正済み → 確認テスト待ち → クローズ
途中には「却下（欠陥ではない・仕様どおり）」「保留（次リリースで対応）」 「再オープン（確認テストで直っていない）」といった分岐があります。 テストマネージャは、滞留している欠陥（長期間 open のまま等）をモニタリングし、 トリアージ（優先順位づけ会議）で処理の流れを維持します。
欠陥データの分析で何がわかるか
- 欠陥密度（欠陥数 ÷ 規模）: コンポーネント別に比較して高リスク領域を特定 → リスクベースドテストの入力になる
- 検出フェーズ vs 混入フェーズ: 要件起因の欠陥が多ければ、レビュー強化など 上流のプロセス改善につなげる
- 欠陥除去率・再オープン率: テストと修正の効果を評価する
「欠陥データは個人の評価に使う」は典型的な誤り選択肢です。データはプロセスの改善に 使うものであり、担当者を責める道具にすると報告が歪みます。
学習のポイント
本試験では、欠陥レポートの不備を指摘させる問題や、欠陥データから次のアクションを 選ばせるK3/K4のシナリオ問題が出ます。重要度/優先度の区別とライフサイクルの分岐を アプリの演習で固めておきましょう。