検出バグ数を、作り込み工程と検出工程で管理する理由
検出バグ数は、作り込み工程と検出工程で管理します。
この理由を説明します。
１）テストの検出対象
各テストの位置づけを次のようなモデルで考えます。
この図は、次のような開発の流れを示しています。
ａ）設計、製造
①要件定義書を正として（要件定義書の内容を満たすように）外部設計をし、外部設計書を作成します。
②次に、外部設計書を正として（外部設計書の内容を満たすように）内部設計をし、内部設計書を作成します。
③更に、内部設計書を正として（内部設計書の内容を満たすように）製造をし、ソースコードを作成します。
ｂ）単体テスト
内部設計書をを正として（内部設計書の内容を満たすように）単体テストをします。
③により、内部設計書の内容を満たすようにソースコードを作成しているはずですが、ソースコードが内部設計書の内容を満たしていない場合、つまり製造バグを検出します。内部設計書が間違っている場合（内部設計バグ）や、内部設計書の元となる外部設計書や要件書のバグは検出できない可能性があり、テストの主な検出対象とはしません。
Ｃ）結合テスト
外部設計書をを正として（外部設計書の内容を満たすように）結合テストをします。
②により、外部設計書の内容を満たすように内部設計書を作成しているはずですが、内部設計書が外部設計書の内容を満たしていない場合、つまり内部設計バグを検出します。外部設計書が間違っている場合（外部設計バグ）や、外部設計書の元となる要件書のバグは検出できない可能性があり、テストの主な検出対象とはしません。
製造バグ（ソースコードのバグ）については、単体テストでテストしているので、原則として、製造バグについては検出の対象としません。
ｄ）システムテスト
要件定義書書をを正として（要件定義書書の内容を満たすように）結合テストをします。
①により、要件定義書の内容を満たすように外部設計書を作成しているはずですが、外部設計書が要件定義書の内容を満たしていない場合、つまり外部設計バグを検出します。要件定義書が間違っている場合（要件バグ）は検出できない可能性があり、テストの主な検出対象とはしません。
内部設計バグや製造バグについては、それぞれ、結合テストや単体テストでテストしているので、原則として、内部設計バグと製造バグについては検出の対象としません。
ｅ）ユーザテスト
同様に、ユーザテストで要件定義バグを検出します。
しかし、要件定義工程の際の正となる文書である要求事項が、必ずしもすべて、明文化されていない場合があり、実際には、課題管理なとでユーザとのやりとりをすることにより、要件バグを検出することもあります。
ｆ）「テストの検出対象」のまとめ
以上をまとめると、次の表になります。
２）レビューの検出対象
各工程で作り込んだバグは、主に、その工程内での検出を前提とします。他のレビュー工程で検出される場合もありますが、主な検出対象とはしません。
このため、検出状況は、次の表になります。
３）検出対象
上の２つの表を合わせると、次のようになります。
これを、
- レビュー工程での検出対象（○）→レビュー検出バグ（青）
- テスト工程での検出対象（○）→テスト検出バグ（緑）
- 主な検出対象ではない（△）→意図せず検出したバグ（薄緑）
- 対象外（×）→漏れバグ（黄）
としたものが、元の表（下表）となります。
このため、計画時には、次の３種類のバグを決めます。
- レビュー検出バグ（青）
- テスト検出バグ（緑）＋意図せず検出したバグ（薄緑）
- 「意図せず検出したバグ」は個別に計画することが困難なため、「テスト検出バグ」に含めて計画します。
- 漏れバグ（黄）
- テスト検出までですべてのバグを検出する前提ですので、原則として「漏れバグ」は０とします。
このように、バグの作り込み工程によって、レビューやテストの検出対象となる工程が異なります。このため、検出バグ数は、作り込み工程と検出工程で管理する必要があります。