テスト密度とバグ密度の関係

テスト密度とバグ密度については、それぞれ「品質メトリクス　－テスト密度－」、「品質メトリクス　－バグ密度／欠陥密度－」で記しているが、お互いの関係はどのようになっているのかを整理する（考察する）。
例えば、テスト密度が標準値を超えているのにバグ密度が標準値未満の場合、これは品質が良いと考えるべきなのか、それとも何か問題があるのか、という問いである。
テスト密度もバグ密度も標準値の範囲内である場合は、一般論として、あまり問題にならない。
一般論として、といったのは、これ以外にも品質の評価尺度はあるだろうし、定性的な評価も必要だから、テスト密度とバグ密度だけで品質を判断することは現実にはありえない、という意味である。さらに、設定した目標値自体が誤っていたというケースも現実にはある。
テスト密度とバグ密度が標準値から外れる場合の組み合わせとして、以下の4つが考えられる。
①テスト密度が標準値を下回っていて、バグ密度が標準値以上
②テスト密度が標準値を下回っていて、バグ密度も標準値以下
③テスト密度が標準値を上回っていて、バグ密度が標準値以下
④テスト密度が標準値を上回っていて、バグ密度も標準値以上

①テスト密度が標準値を下回っていて、バグ密度が標準値以上
テスト密度が標準値を下回っているにもかかわらず、バグ密度が標準値を超えている場合は、さらにテストを行えばまだバグが出る可能性があることを示唆している。すなわち、品質が悪い可能性が高い。
まず、テスト網羅度に問題がなかったのか、すなわち、テストの観点や粒度に問題がなかったのかを点検すべきである。
次にバグの混入工程と原因分析を行い、対策を検討する。
このケースは、単体テストが不十分であったことが要因になることが多い。混入工程を分析した結果が単体レベル（詳細設計やコーディング）の場合は、単体テストの結果を再点検する必要があり、場合によっては単体レベルの追加テストが必要になる。

②テスト密度が標準値を下回っていて、バグ密度も標準値以下
これだけで品質を判断することは困難である。さらにテストを行えば、標準値と同程度のバグが検出される場合もあるし、標準値以下の場合もあり得るし、標準値以上のこともあり得る。
従って、①の場合と同様、まずテスト網羅度に問題がなかったのか、すなわち、テストの観点とテストケースに漏れが無かったのか、を点検する。

③テスト密度が標準値を上回っていて、バグ密度が標準値以下
この場合は、品質が良いか、あるいはテストの観点に漏れがあるか、の何れかである可能性が高い。
従って、まずテストの観点に漏れがなかったのかを再点検する必要がある。テストの観点に問題がなければ品質上の問題は少ないと考えられる。

④テスト密度が標準値を上回っていて、バグ密度も標準値以上
テストを多く実施したのだからバグも多く出るのは当然だと思われるかもしれない。しかし、テスト項目数とバグ数の関係は一般にＳ字カーブ（ゴンペルツ曲線など）を描いて収束する。従って、バグ密度が標準値を超えている場合は、単体テストなど前工程のテストに問題がなかったのか、混入工程や原因の分析を行なう必要がある。

IPA（情報処理推進機構）が刊行している「定量的品質予測のススメ」では、テスト密度とバグ密度（欠陥密度）の組合せを、9つのゾーンに分けて品質分析している。
上記の説明よりも領域の数が多いのは、テスト密度とバグ密度のそれぞれについて閾値を設けているからである。閾値は、UCL（上部管理限界線）とLCL（下部管理限界線）から構成される。
例えば、バグ密度の目標値が「10（件/KSLOC）±10%」の場合、9～11が目標の範囲内であり、LCLが9、UCLは11となる。
以下同書籍から引用する。

ベンダー内の最終テスト（一般には総合テストと呼ばれるが、ベンダーによって呼称は異なる場合がある）が終わると、ユーザー側のテスト（ユーザ企業のＩＳ部門によるテストや業務部門によるテスト）が始まる。
ベンダー側のテストが終わっているにもかかわらず、ユーザー側のテストで多くの不具合が検出されるということがある。場合によっては、ユーザー側のテストで検出されたバグのバグ密度が、ベンダー側の最終テストのバグ密度よりも高いということさえある。
Ｓ字カーブを使って表すと、以下のようなイメージになる。
ベンダーのテストでバグが収束したかに見えたが、ユーザ側のテストでバグ曲線が再び立ち上がりをみせる。

①ベンダーの業務仕様理解不足
ベンダーの業務理解（あるいは業務仕様理解）が不十分だと、自ずとテストの観点やテストケースに漏れが出る。この結果、ユーザー側のテストで多くの不具合が出ることになる。
これは、当該システムを担当するベンダーを変更した場合などに見受けられるケースである。
このようなリスクを軽減するためには、ベンダーのテスト工程において、ベンダーが作成したテストケースをユーザー側が十分にレビューする、などの対策が考えられる。

②ベンダー試験におけるテスト観点の漏れ
先の①が原因でテスト観点が漏れる場合があるが、それ以外にも条件の組み合わせの漏れなどが要因になっている場合がある。
条件の組合せの漏れを防ぐために、条件のマトリクスを作るなどの手法が採られる。
しかしながら、条件が多いとマトリクスの数も増えるので、条件の組み合わせが多すぎる場合は、（コストと時間の制約から）条件を絞り込む方法も検討する必要がある。

③単体テストレベルの潜在バグが多い
テスト工程は後工程になるほど（すなわち、単体テストよりは結合テストの方が）テストの粒度が粗くなる（テスト密度が小さくなる）。従って、単体レベルのバグが潜在バグとして残ると、後工程のテストで検出できないことがある。