DDP（Defect Detection Percentage）を考えてみた

JaSST'13Tokyoに行ってきた。

レポートはおいおい書くとして、基調講演のGrahamさんが言っていたDDPという指標について考えてみる。

http://gihyo.jp/news/report/2013/01/3101

【DDPの定義】

DDP＝（テスト中に見つかった欠陥数）／（テスト中～リリース後に見つかったすべての欠陥数）のパーセンテージ

テスティングの価値を測る指標ということで、以下の前提を置いて具体的に見てみる。

【設定条件】

良いソフト（内在バグ20件）
悪いソフト（内在バグ100件）

良いテスト（内在バグの8割検出）
悪いテスト（内在バグの2割検出）

市場で使う人が多い（残存バグの全てを検出）
市場で使う人が少ない（残存バグの20%を検出）

Excelで計算してみると、こんなになった。

社内で発見されるバグの数だけで見ているとソフトウェアの作りが入ってくるため、テストの良し悪しが分からない。以下の黄色の箇所は件数で見ると同じ16件。

でもそこをDDPで見るとソフトウェアの作りによらず、良いテストは80%、悪いテストは20%。なるほど！テスティングの価値を測る指標だ。

ただ気をつけないといけないのは、市場での不具合の検出率。

ユーザーがたくさんいる場合はいいが、少ない場合はDDPに差異が生じる。

この場合は期間を長めにとって調整するしかないだろうなぁ。

自分の中の結論。

「DDPはソフトウェアの作りの良し・悪しを取り除くことができる指標である。ただし市場ユーザーの数を考慮して、期間を設定する必要がある。」

他にも小さなプロダクトだとバグの件数が少ないため、たまたま市場バグが多いとDDPの値の変化が大きくなるとかはGrahamさんも言っていたなぁ。

後、個人的に気になっているのはフィードバックが遅くなりそうなこと。もう少し他の指標と組み合わせていくといいと思う。

簡単な計算だけど、自分で考えてみるって重要だと思ったToday！