テスト密度とバグ密度の指標について

はじめに

テスト密度とバグ密度は、下流工程で定量的な品質指標として使用され、案件品質の分析評価に欠かせないものです。これらの指標の下限値～上限値と実績テスト密度と実績バグ密度を組み合わせることで、どの機能に品質面の懸念があるかを確認することが可能です。

これにより該当する機能のテスト項目の網羅性をレビューしたり、バグ内容を深く検証したり、現象発生区分/原因区分/原因工程/バグ重要度などの品質についてより詳しく分析したりすることができます。そこで今回はテスト密度とバグ密度についてご紹介します。

目次
１．テスト密度とは
２．バグ密度とは
３．どのようにバグ密度を分析するか

１．テスト密度とは

テスト密度とは、案件の規模単位（SLOC・FP）でテスト項目の件数を示す指標です。テスト密度はテスト件数を規模単位で割るという方法で算出します。
（SLOC：ソースコードの行数、FP：ファンクションポイント）

テスト密度の指標設定は、下流工程のスケジュールなどの作成の時に社内の品質指標と案件の特性などを組み合わせ、対応範囲の各テスト工程の指標の下限値/標準値/上限値を設定します。

テスト密度の分析・評価は、以下のように行います。

各テスト工程におけるテスト設計の段階で、設定されたテスト密度の指標を使用し、実際テスト設計の件数がその指標を達成するかどうかを確認します。ただ、実績テスト設計の件数が多ければ多いほど、テストの網羅性が高いという意味ではないため、テスト設計の成果物の品質を保証するためには、テスト密度の指標評価だけではなく、各機能のテスト項目の網羅性が高いかを徹底的にレビューすることが重要です。

各テスト工程のテスト実行段階においては、普段、テスト工程の途中での判定やテスト工程修了時の判定で、指標と実際バグ密度、[NN1] テスト項目の消化件数の差異を分析評価します。

２．バグ密度とは

バグ密度とは、案件の規模単位（SLOC・FP）でバグの量を示す指標です。バグ密度はバグ数を規模単位で割るという方法で算出します。

マスタスケジュールを作成または、詳細スケジュールを作成する時に、以下の要素に基づいて、対応範囲に応じたバグ密度の下限値/標準値/上限値を設定します。

· 対応範囲
· 社内指標
· 案件の背景（流用案件/改造案件/既存案件）
· テクノロジー、業務の難易度
· 要員スキル
· 環境的な制約

ここで欠かせないのは、案件の品質に関する評価観点の認識をしっかりすり合わせておくことです。また、案件の品質ゴールを達成するために、お客様に設定したバグ密度の指標に同意していただくだけでなく、案件を担当するメンバーもバグ密度の指標を認識することが必要です。

また、バグ密度の指標をうまく分析・評価するために、プロセスの標準化を一貫性して行い、妥当性データ（機能ごとに対して、予定・実績の規模、正しく分類されたバグ、テスト項目の消化件数）を日次収集することも重要です。

３．どのようにバグ密度を分析するか

案件のスケジュールに沿って各工程の途中判定、工程移行判定、工程修了を判定する際に以下の通り、ゾーン分析を通して、バグ密度の指標とバグ実績の量、テスト密度の指標とテスト項目の消化件数を組み合わせて案件の品質を分析・評価します。

それでは次にゾーン分析の具体例を示しながら、詳しく解説していきます。

3.1 ゾーン５（品質基準値の範囲内）

上記図の例で言えば、バグ密度がゾーン5の範囲に収まる場合、ゾーン５が品質の基準値の合格範囲となります。ただ、なるべくバグを次工程に持ち越さないよう現工程で抜け漏れなくバグを検出するためには、該当する機能に対するテスト項目において網羅性が高いかどうかを確認する必要があります。また、バグの内容を現象区分/原因区分/原因工程/バグ重要度の各項目でそれぞれ分析することも欠かせません。

3.2 ゾーン６（バグ密度の基準値範囲内で、テスト密度の基準値範囲外）

次に別の例を見ていきましょう。上記図はバグ密度がゾーン6の範囲に収まるケースです。この場合、テスト件数の上限値以上でテストを実施しても、最も多いバグを発見する可能性が低いということになります。つまり、この状況ではテスト効率が良くないと判定することができるため、テスト項目が過剰またはテストの網羅性が低い可能性があります。

3.3 ゾーン２、３（バグ密度の基準値範囲外）

今度は上記図のようにバグ密度がゾーン2と3に収まる場合を見ていきましょう。この状況はテスト件数の下限値で検出バグの量が多いことから、プログラムの品質が悪いということを意味します。こうした状況に対しては、なるべく早い段階でバグ密度を見極めることが重要になります。

さらに、以下のように検出バグの内容を細かく分析することが必要です。

・どの機能にどの問題があるかを確認する
・担当者のスキルにどの程度問題があるかを確認する
・現象区分/原因区分/原因工程/バグ重要度の各項目についてバグを分析する

3.4 ゾーン1、4（少数のテスト量でバグ密度が高い）

さらに、上記図のようにバグ密度がゾーン1と4の範囲に収まる場合は、少数のテスト項目で検出バグの量が下限値および上限値を超えているため、プログラムの品質が悪すぎるという状況を意味します。

この場合、バグ密度がゾーン2と3に該当する場合のバグ分析と同様に、テクノロジー・業務の難易度、担当者のスキルのレベルを見極めた上で、検出バグの状況を日次収集して見極めることが重要です。

その上で現象区分/原因区分/原因工程/担当者/バグ重要度の各項目において正しく分類されたバグの内容に基づき、機能ごとの品質を原因工程/担当者のグラフ・散布図などで分析し、妥当な対策を立てることが必要です。

3.5 ゾーン7（テスト密度が低すぎる）

では、上記図のようにバグ密度がゾーン７に収まる場合はどうでしょうか。この場合はテスト密度が低く、テスト項目が不足しているため、プログラムの品質が評価できない状態を意味します。

このようなケースでは、テスト観点チェックリストで各機能のテスト項目の網羅性を確認し、テスト項目を追加することが必要です。

3.6 ゾーン8、9（バグ密度が低い）

最後にバグ密度がゾーン8と９に収まる場合です。これはバグ密度が低い状態を意味しています。ゾーン8のバグ密度に対してテスト効率が良いかどうかは、テスト観点チェックリストを活用し、該当機能のテスト網羅性が高いかを確認しましょう。

また、ゾーン9のバグ密度に対しては過剰なテストや重複するテストが存在していないかどうかを確認します。このほか、バグ密度が低いため該当機能のテスト内容の網羅性が高いかどうかをチェックすることが欠かせません。

おわりに

今回はテスト密度とバグ密度についてゾーン分析を交えながらご紹介しました。特に難易度の高い業務のほか、新たな技術や経験が浅い要員を活用するような新規案件ではテストの品質やコストの安定を担保するためにデータを日次収集した上で、機能や要員のスキルレベルに応じてバグ密度を判定し、なるべく早い段階で品質を分析・評価することが重要です。