ソフトウェア開発において、欠陥（Defect）は避けて通れないものです。
しかし「欠陥をどう管理するか」によって、プロジェクトの品質と効率は大きく変わります。
今回は、**ISTQB Test Management v3.0（Chapter 2.3.1）「Defect Lifecycle（欠陥ライフサイクル）」**について、
テストマネージャーが理解しておくべきポイントを、図解イメージと具体例を交えてわかりやすく解説します。
🔍 欠陥ライフサイクルとは？
**欠陥ライフサイクル（Defect Lifecycle）**とは、
「欠陥が報告されてから最終的にクローズ（解決完了）されるまでの一連の流れ」を指します。
欠陥は、単に「バグ報告して終わり」ではありません。
報告後、分析・修正・再確認・クローズと、いくつもの段階を経て管理されます。
🧩 欠陥はどこで見つかる？
ISTQBでは、欠陥が発見されるタイミングを「静的テスト」と「動的テスト」に分類しています。
|
種類 |
タイミング |
例 |
メリット |
|---|---|---|---|
|
静的テスト |
コーディング前（レビューなど） |
仕様書レビュー、コードレビュー |
修正コストが低い |
|
動的テスト |
実行中（テスト実施時） |
機能テスト、統合テスト |
実際の動作で発見できる |
例えば、仕様書レビューで「条件分岐の誤り」を早期に発見すれば、
リリース後にユーザーから苦情が来るよりもはるかに安価に修正できます。
このように「早く見つけて早く直す」ことが、品質向上の鍵です。
⚠️ すべての失敗が欠陥とは限らない
テストで「失敗（Failure）」が発生しても、それが必ず欠陥（Defect）とは限りません。
以下のようなケースでは、欠陥ではなくテスト環境やデータの問題であることがあります。
例：
-
テストデータが誤っていた
-
テスト環境の設定ミス（例：旧バージョンのDBを使用）
-
テスターが手順を誤った
-
TDD（テスト駆動開発）で「まだコードが未実装」の段階
したがって、テストマネージャーは「失敗の原因分析（root cause analysis）」を行い、
本当に欠陥として登録すべきか判断する必要があります。
🌀 欠陥ライフサイクルの基本ステータス
組織やツールによって多少異なりますが、基本的な欠陥ステータスは以下の通りです。
|
ステータス |
意味 |
実務例 |
|---|---|---|
|
New（新規） |
欠陥が報告された直後 |
テスターが初めてバグ報告を登録 |
|
Open（オープン） |
トリアージで承認され、処理待ち状態 |
テストリーダーがレビューして開発チームに回付 |
|
In Progress（処理中） |
開発チームが修正対応を開始 |
開発者が修正作業中 |
|
Resolved（解決済み） |
修正が完了し、再テスト待ち |
「Fixed」「Ready for Retest」なども同義 |
|
Closed（クローズ） |
テストで修正が確認され、完了 |
再テスト合格後、正式に完了 |
|
Rejected（却下） |
再現できない、または誤報 |
環境ミスや重複報告など |
|
Reopened（再オープン） |
修正後も再発した場合 |
再テストで失敗し、再修正へ戻す |
|
Deferred（保留） |
修正を次リリースに延期 |
影響が小さい・優先度が低い場合 |
🧠 ポイント：
ISTQBは特定のライフサイクルを推奨していません。
各組織が自社の開発プロセスやツールに合わせてカスタマイズしてOKです。
ただし、**「New → Open → In Progress → Resolved → Closed」**の流れは必須です。
🧮 実際のトリアージ（Defect Triage）とは？
「トリアージ」とは、報告された欠陥を分析し、**優先度（Priority）と重大度（Severity）**を決める会議のことです。
具体例：
|
欠陥内容 |
重大度（Severity） |
優先度（Priority） |
対応方針 |
|---|---|---|---|
|
ログインできない |
高 |
高 |
即時修正 |
|
文言の誤字 |
低 |
低 |
次回リリースで修正 |
|
特定環境でのみ発生 |
中 |
低 |
再現条件を精査 |
このように、すべての欠陥を同じ扱いにせず、
リスクベースで対応優先順位をつけることが欠陥管理の重要ポイントです。
🏗 欠陥ライフサイクル設計のベストプラクティス
ISTQBでは、欠陥ライフサイクルを設計する際に以下の点を推奨しています。
-
全社共通のワークフローを定義する
→ プロジェクトごとに異なるよりも、標準化すると混乱が減る。
-
重複（Duplicate）や誤報（False Positive）には専用ステータスを設定
→ たとえば「Duplicate」「Invalid」など。
-
終端ステータス（Closed）は1つに統一
→ 「完了」を明確にし、曖昧さを排除。
-
他の開発タスク（例：User Story）と状態名を統一
→ 「To Do / In Progress / Done」などで一貫性を持たせる。
-
状態遷移は双方向に可能とする
→ 「誤って進めた場合に戻せる」ように設計する。
-
状態変更時に必要な情報だけを入力させる
→ 無駄な項目を減らし、入力疲れを防止。
（例：再テスト時は「担当者」「修正日」「修正内容」など最小限）
💡 まとめ：欠陥管理はチームの共通言語
欠陥ライフサイクルを明確にすることで、
「今、この欠陥はどんな状態なのか？」が誰でも理解できるようになります。
つまり、欠陥管理とは単なるバグ追跡ではなく、
チーム全体の透明性と品質意識を高める活動なのです。
🏁 この記事のまとめ
-
欠陥は「報告→分析→修正→確認→完了」の流れで管理する
-
すべての失敗が欠陥とは限らない（環境・データ・テスト手順の誤りもある）
-
ステータスは「New / Open / In Progress / Resolved / Closed」が基本
-
トリアージで優先度と重大度を決定する
-
ワークフローを標準化し、誰でも同じ意味で理解できるようにする
コメント