【ISTQB /JSTQB FL 4.0解説】欠陥管理（Defect Management）とは？欠陥報告書の書き方と具体例

ソフトウェアテストを学ぶうえで、**「欠陥管理（Defect Management）」**は非常に重要なテーマです。

テストでバグ（欠陥）を見つけること自体も大切ですが、「どう報告するか」が品質向上のカギを握っています。

今回はISTQB Foundation Level シラバス4.0の**Chapter 5.5「欠陥管理」**を、初心者にもわかりやすく解説します。

🔍 欠陥（Defect）とは？

まず基本から整理しましょう。

欠陥（Defect）とは、期待される結果と実際の結果の間に生じた不一致のこと。

たとえば：

ISTQBでは、欠陥を「期待値と実測値の差異（Deviation）」として定義しています。

テスト中に不具合を見つけたとき、「口頭で伝えればいいのでは？」と思う人もいるかもしれません。

しかし、口頭報告だけでは大きなリスクがあります。

テスターだけが不具合の再現手順を知っている状態では、開発者やマネージャーは判断できません。

欠陥報告書を書くことで、「どこで」「何をしたら」「どうなったか」を共有できます。

欠陥報告は単なる記録ではなく、製品品質を測る指標にもなります。

たとえば：

このように、欠陥分析からプロセス改善のヒントを得ることができます。

欠陥を体系的に記録・分析することで、次回のプロジェクトでは同じミスを防止できます。

たとえば、「要件定義の段階で見落としが多かった」とわかれば、次からはレビューを強化するなどの対策が可能です。

ISTQBでは、**ISO/IEC 829（IEEE 829）**の国際標準をベースに、欠陥報告書に含めるべき項目を推奨しています。

ただし、プロジェクトや組織に応じてカスタマイズ可能です。

以下に代表的な項目を示します。

項目	内容	具体例
1. 一意のID	欠陥を特定するための番号	DEF-00123
2. タイトル（概要）	問題を一文で説明	「ログインボタンをクリックしても反応しない」
3. 発生日・報告日	いつ見つけたか	2025-10-21
4. 報告者・所属・役割	誰が報告したか	山田太郎（QAチーム）
5. 対象オブジェクト・環境	どの環境で発生したか	Android 14／アプリVer.1.2.0
6. 再現手順	ステップごとに説明	①ログイン画面を開く→②正しいID/PWを入力→③ボタンを押す
7. 期待結果	本来どうなるべきか	ホーム画面へ遷移する
8. 実際の結果	実際の挙動	画面が固まって動作しない
9. 添付資料	ログ・スクリーンショット等	「error_log.txt」「video_capture.mp4」など
10. 重大度（Severity）	システムへの影響度	High（機能が利用できない）
11. 優先度（Priority）	修正の緊急性	P1（即時対応が必要）
12. ステータス	現在の進捗	New / Open / Fixed / Closedなど
13. 参照情報	関連するテストケースや仕様書	「TC_012_Login」「REQ_001_LoginFunction」など

欠陥は報告して終わりではありません。

実際には以下のようなライフサイクル（状態遷移）をたどります。

このように、欠陥の状態を管理することで、進捗を可視化し、チーム全体の品質意識を高めることができます。

欠陥報告書は単なる不具合記録ではなく、「品質向上の宝の山」です。

たとえば、100件の欠陥のうち：

このように、欠陥を分析することで「どの工程に問題が集中しているか」を特定し、**継続的改善（Continuous Improvement）**に活かせます。

欠陥管理（Defect Management）は、テスト工程の中でも特に「品質を測る鏡」のような役割を果たします。

これらを実践することで、単なる「バグ修正作業」から一歩進んだ「品質文化」を築くことができます。