はじめに
ゾーン分析とは、品質管理で使われる手法の一つです。
2つの指標を縦軸と横軸にし、それぞれの基準値や上限下限で区切ったグラフを作成し、そのグラフ上にプロジェクトの状況を当てはめていくことで、グラフに作成したゾーンのどの位置にあるかによって品質を客観的に評価・分析できるというものです。
ここでは、テスト密度、バグ密度という指標を用いた分析を紹介したいと思います。
ゾーン分析の目的
ゾーン分析の目的は、データに基づいてプロジェクトの状況を可視化し、客観的な目で分析し、さらに深堀していくことにあります。
主に以下の観点で分析を始めます。
-
テストの妥当性 実施したテスト規模が、開発規模に対して過不足ないかを見ます。
-
品質の可視化 品質状況を視覚的に把握し、問題のある個所を判別します。
-
リスクの早期発見 「テストは少ないが、バグが多い」などの兆候を早い段階で検知します。
-
プロセス改善 分析結果から、どのゾーンに入ったのか、なぜそのゾーンに入ったのかを分析し、開発プロセスやテストプロセスの改善につなげます。
テスト密度とバグ密度によるゾーン分析の具体例
テスト密度
- 開発規模あたりのテストケース数
- テスト数÷開発規模（LOCやFPなど）
バグ密度
- 開発規模あたりのバグ検出数
- バグ数÷開発規模（LOCやFPなど）
これらの値を縦軸、横軸に取り、過去の実績などから算出した、上限、下限で区切ると以下のような9つのゾーンを持つマトリクスが作成されます。
ゾーン1（中央） : 理想
テスト密度も、バグ密度も標準的な範囲であり、開発・テストが順調に進んでいると思われる。
ゾーン2、4 : テストが過剰な可能性
テスト数は多いが、バグは標準か少ない状態。テストケースの見直しや効率化が必要と思われる。
ゾーン3、9 : 品質が良い or テスト不足
テスト数は少なく、バグも少ない状態。品質が良いか、観点不足やパターン不足の可能性がある。
ゾーン5、6 : プロセスに問題がある
テストも多く、バグも多い状態。テストケースが多すぎる、パターンが多すぎる、また、バグの内容によっては品質に問題がある可能性もある。
ゾーン7、8 : 危険な状態
テストが少ないにもかかわらず、バグが多い状態。設計、開発に問題がある、また、潜在バグも多数ある可能性がある。
ゾーン分析の注意点
基準値とデータが絶対ではない
過去の実績データに基づいた基準値を使用するようにしましょう。感覚で設定した基準値では意味がなく、基準値が甘ければ理想ゾーンに入ってしまい、厳しければ問題なくとも危険ゾーンに入ってしまいます。過去の実績データがなければIPAが提供している指標値を使用しても良いと思います。
なぜそのゾーンに入っているかを考える
ゾーン分析はあくまできっかけであり、ここからさらに、各ゾーンに入った理由を考えることが重要です。理想ゾーンに入ったからOK、危険ゾーンに入ったからNG、と短絡的に判断するのではなく、結果からさらに掘り下げて、品質管理・保証の第一歩としていければと思います。
