私が所属していたQAチームでは、過去にDDP（Defect Detection Percentage：欠陥摘出率）を観測して欠陥検出力（テストによって欠陥を検出する力）をモニタリングしていました。しかしながら、ある時DDPの観測をやめてしまいました。 本記事では、DDPの観測をやめた経緯について私が想像した内容*1を記載したいと思います。
DDPについては、こちらの記事がわかりやすいのでご参照ください。 www.kzsuzuki.com
また、上記の記事や以下の記事のようにDDPを上手く活用しようとしている事例もあります。
そのため、私が所属していたQAチームでは単にDDPの活用方法を誤っていただけの可能性もあります。
上記を踏まえた上で本記事を読んでいただければと思います。
目次
本記事の前提
- Webサービスの事業会社
- 事業ごとに内製の開発チームがある
- 新規開発も派生開発も同じ開発チームが担当する
- 小規模な改修を頻繁にリリースするスタイル
- 各テストレベルにおけるテスト担当者
- QAエンジニアの役割は、欠陥の検出だけでなく、欠陥の埋め込み削減にも貢献する
過去のDDPの利用方法
DDPの利用目的は、QAエンジニアが担当するテストレベルにおける欠陥検出力の観測です。 集計期間は毎月・半期・年間単位、集計範囲は開発チーム毎・会社全体で観測していました。
当時QAチームで用いていた計算式は、以下の通りです。100%に近いほど良い数値となります。
DDP = QAが検出した欠陥数 / (QAが検出した欠陥数 + 本番に流出した欠陥数) * 100
欠陥数に対しては、ビジネス影響の大きさといった重みづけを付けたこともありました。 なお、QAチーム全体でのDDPの数値は約2年間80%以上を維持していました。
DDPをやめた理由
DDPの数値を見ても正確な欠陥検出力はわからない
欠陥検出力が最高の状態を雑に「検出すべき重要な欠陥を全て検出している状態」と定義すると、欠陥検出力が高い状態、低い状態は以下のようなイメージになると思います。
| 欠陥検出力 | 説明 |
|---|---|
| 欠陥検出力が高い | 検出難易度が低い重要な欠陥も検出難易度が高い重要な欠陥も検出漏れがない |
| 欠陥検出力が普通 | 検出難易度が低い重要な欠陥は検出漏れがないが、検出難易度が高い重要な欠陥は検出漏れがある |
| 欠陥検出力が低い | 検出難易度が低い重要な欠陥も検出漏れがある |
DDPの数値が良くても本番に流出した欠陥がリリースした機能の正常系ど真ん中であれば、上記定義だと欠陥検出力は低くなります。 したがって、DDPの数値だけでは正確な欠陥検出力がわかりません。*2
DDPの数値に影響を与えるのは欠陥検出力以外のことが多い
DDPは検出難易度が低い欠陥が多いと数値が良くなります。 例えば、以下のような場合です。
- 規模の大きめな改修
- 複雑なロジックに対する改修
- JavaScriptの改修*3
- 新人の方が担当した改修
DDPの数値が良いときと悪いときを比較すると、殆どの場合は上記改修の有無が影響していました。
欠陥の埋め込み削減を目指すとDDPの数値が悪化する可能性がある
欠陥の検出だけを頑張るのではなく、欠陥の埋め込み自体を削減した方が望ましいことはよく言われていることだと思います。
欠陥の埋め込みを削減した際に検出難易度の低い欠陥と検出難易度の高い欠陥が同様の割合で削減できればDDPの数値には影響はありません。
しかしながら、欠陥の埋め込みを削減した際に検出難易度の低い欠陥だけ減少した場合は、DDPの数値は悪くなります。（逆の可能性もあります）
DDPの観測の代わりにやったこと
本番障害の件数とビジネス上の影響度を観測
テストを通じて目指すことは、ビジネス上の損失が生じる本番障害が0件になることです*4。 そのため、本番障害の件数とビジネス上の影響度を観測するようにしました。
本番障害について検出漏れの原因分析
DDP観測時代も行っていましたが、本番障害については欠陥検出漏れの原因分析と再発防止策の検討を行います。 欠陥検出漏れの原因分析*5を通じて欠陥検出力を調べます。 なお、欠陥の埋め込み原因分析*6も併せて行います。
解決できていない課題
欠陥検出力をリリース前にチェックできない
本番障害を欠陥検出力の評価に用いるため、リリース前にテストケースの欠陥検出力を評価することができません。リリース前のテストケースの欠陥検出力の評価はレビューやチェックリスト等を用いて判断することになります。
本番障害がない場合に欠陥検出力がわかりづらい
本番障害は「欠陥の埋め込み」と「欠陥の未検出」の2つが重なった時に発生します。 本番障害だけ観測すると、本番障害がなかった理由が「欠陥の埋め込みがないのが良かった」のか「欠陥検出力が高かった」のか「両方良かった」のかがわかりません。 テストフェーズで検出した欠陥の性質を分析すれば欠陥検出力がわかるかもしれませんが、分析に工数がかかり過ぎるかもしれません。
複数の開発チームで欠陥検出力を比較しにくい
欠陥の埋め込みやすさや欠陥検出の難易度はプロダクトによって変わります。 そのため、単純な本番障害の件数などで複数の開発チームにおける欠陥検出力の優劣をつけるのが難しくなります。
まとめ
欠陥検出力を観測する方法をDDPから「本番障害の件数」や「本番障害の欠陥検出漏れの原因分析」に変えた経緯を私の想像で説明しました。 冒頭で紹介した記事と本記事でのDDPの活用方法を比較すると、私が所属したQAチームでDDPをうまく活用できなかったのはDDPの観測対象が1つのテストレベルだけだったり、他の指標とDDPを合わせて確認しなかったからかもしれません。
冒頭で紹介した記事や本記事をきっかけに皆さんの組織に適した良い指標が見つかれば幸いです。
