コラム

  • 2021.07.26
  • ソフトウェアテスト
  • #テスト実行
  • #テスト技法
  • #テスト計画
  • #テスト設計
  • #基礎知識

バグ密度とは システム開発における品質可視化のための指標について解説

ソフトウェア開発では、長年、定量的な品質管理の指標として、バグ密度・テスト密度が利用されてきました。それには大きく分けて二つの目的があります。

■判定基準とする指標として活用
品質面から見て次工程に進んでよいか、リリースを承認してよいかを判断をするための材料として数値を利用する。

■開発プロセス改善や振り返りに利用する指標として活用
バグ密度の比較などからプロジェクトの弱点を理解し、開発プロセスの改善や次回開発のために数値を参考にする。

例として、個人で50メートル走の記録を計測しても何もわからないですが、クラスや学校全体で記録をとることにより、基準値ができ、比較をすることで、個人が努力するための目標値が算出可能になるイメージです。
品質管理も同じ視点で、日常の開発現場において、テスト数やそのテスト実施にて検出されたバグ回数を計測し、過去や横並びの開発、プロジェクト(プロダクト)と比較し、傾向値から基準値と目標を策定、目標に至らなければ、至らない原因課題を見つけ、改善をしていくことで品質を管理していきます。

次に、開発現場でバグ密度とテスト密度はどのような前提のもと、何を判断していくための品質管理指標なのか、もう少し詳細にご説明します。

バグ密度とは

バグ密度とは、ソフトウェア開発規模に対してどのくらいバグが発生しているかを示す指標です。一般的には、「バグ数/規模」で算出し、規模の単位では*FP、*LOCなどで算出されることが多いです。
*FP:Function point=機能数、機能の複雑性
*LOC:Lines of Code=プログラムの行数

バグ数のみでは、開発規模の異なるプロジェクト(プロダクト)との単純な比較はできませんが、密度であれば人口密度のように、規模感の違う市区町村の都市化状況比較や過疎化進行状況推移のように確認が容易となります。バグ密度であれば、異なる規模のプロジェクト(プロダクト)や開発チームでのバグ総量推移や傾向比較などがしやすく、プロセスの課題をはじめ、開発工程の弱点把握など、バグの単純な量だけでは測れないバグの質に対しての問題にいち早く気づくことが可能となります。

バグ密度を測るうえで重要なテスト密度とは

テスト密度とはソフトウェア開発規模に対してどのくらいテストを実行したかを示す指標です。
バグ密度同様に、一般的には、「テスト数/規模」で算出し、規模の単位ではFP、LOCなどで算出されることが多いです。また、同様に基準値や次期テスト工程の参考になる指標として活用します。

バグ密度とテスト密度の関係性はシンプルです。
例えば、”リリースまでに10,000ケーステストを実施して、先月まではバグが10件だったのに対し、今月は同規模でのリリースでテスト数も同じだったのにバグが100件も発生。開発工程やテスト工程の途中に何か問題があるかもしれない” と考えることができるようになります。
また、バグ密度やテスト密度の計測を継続すると、基準値(標準値)や傾向値といった確認ができるようになり比較も可能になってきます。そうなると両者の関係性の法則が見えてきます。
例えば、”「バグ密度が低い」場合、本当に品質がよいと判断してよいのか、であったり、「バグ密度が低く、テスト密度も低い」場合テストがそもそも足りていないのではないのか” といった判断のきっかけを与えてくれます。
このようにテスト密度とバグ密度には関係性があり、品質評価をする際に有効な判断材料となる法則がある程度見えてきます。

ソフトウェアテスト入門動画

バグ密度を分析する方法「ゾーン分析」

「テスト密度」と「バグ密度」指標の法則性を活用した分析手法として、ゾーン分析があります。
ゾーン分析は2つの異なる指標の基準値を使って数値を可視化し評価を行います。
下記のようにマトリックスで表現し、9ゾーンに分けて可視化し、パターン化する手法になります。
それでは9つのゾーンについてご説明します。

マトリックスで可視化、パターン化するゾーン分析の手法イメージ

①ゾーン(品質良好)

①ゾーンは、品質良好となった結果(基準値)と考えます。
しかし、バグの結果を含め妥当性を確認し、重大なエラーが存在しないか念のため確認します。
ゾーン分析は「①ゾーン以外は問題あり」というのが基本となりますが、①ゾーンに入ってもあくまで傾向値となるため詳細確認は必要です。

②、④ゾーン(テスト密度は高いが、バグ密度は低い、やや低い))

②ゾーンはテスト結果がやや悪い、テスト内容点検が必要となります。
④ゾーンはバグが適切に発見できずテスト効率がやや悪い可能性、テスト内容の点検が必要となります。
②、④ゾーンは一見テストが十分実施されていて、品質が高いように見えますが、テスト頻度に比べバグ密度が低いことから、バグがまだ潜んでいる可能性を疑うことをお勧めします。特に、いつもの傾向値より低い場合は、何か変更や問題があるかもしれません。
テストケースの妥当性や網羅性を確認し、テストメンバーのスキルに差が生じてないか、また見当違いなテストを実施していないかなどの確認をしましょう。

③、⑨ゾーン(テスト密度が低く、バグ密度も低い、やや低い)

③ゾーンはテスト内容が適切か点検となり、⑨ゾーンはテスト不足、内容点検となります。
特に⑨ゾーンはテスト密度が低く、バグも検出できていない状態のため、品質について語ることがむずかしい状況です。対応策としてはテスト計画に沿いテストの網羅性や抜け漏れを確認しましょう。そのうえでテストケース、テストリソースを確認し、必要であれば追加テストを実施します。

⑤、⑥ゾーン(テスト密度が高く、バグ密度が高い)

⑤、⑥ゾーンは前開発工程やテスト工程の品質確保不足、内容点検となります。
テストを多く実施し、バグが多く検出されているので一見問題なさそうに見えますが、一般的には工程を追うごとにバグは収束していくものと考えます。そのため前工程において、開発難易度の高さや前テスト工程でのテストケース流出などを疑い、本来摘出されるべき工程でのバグであったかを確認します。
さらにテスト密度が高いことから、不要なテストケースが発生していないかなどを確認し次回以降のテスト工数削減につなげていきます。

⑦、⑧ゾーン(テスト密度が低く、バグ密度が高い、やや高い)

⑦、⑧ゾーンはテスト不足、前開発工程やテスト工程の品質確保不足、内容点検となります。
テストも少なく、バグが多く摘出されていることから、前開発工程やテスト工程に問題があった可能性が高い想定をします。追加テストを実施するとさらにバグが出る可能性が高いので、要因を洗い出し、対応を検討後にテストを再開することをお勧めします。

また、テストケース数が少ないことから、テストの網羅性も確認します。もし前工程に問題があった場合、その観点についても十分考慮し、まだ確認されていないバグの検知を目指します。

ゾーン分析の利用注意点

いずれかのゾーンに入っても、ゾーン分析において人や開発の良し悪しが判断できるわけではありません。プロジェクト(プロダクト)の特性などを考えて、なぜそのゾーンに入ったかということを分析することが一番の品質向上につながっていきます。

ゾーン分析を念頭に計測をはじめると、計測方法によっては①ゾーンに入るようにテストケース数やバグ数を調整するという本末転倒な状況に陥る可能性もあるため注意が必要ですが、計測結果を一つの判断基準として捉え、品質向上のために活用することは大いに意義のあることです。

ソフトウェアテスト入門動画

まとめ

テスト密度とバグ密度を活用し、今回ご紹介したゾーン分析をはじめるためには、どのくらいの計測が母数として必要になるのかという疑問があると思います。
結論から申し上げますと、ゾーン分析も傾向値分析となるので、母数が多くなれば信頼度も比例して高くなります。一方で、母数が少ない場合は、まず現状の把握や基準値を作成する準備と捉え、分析環境整備を進めていくことをお勧めいたします。
テスト密度とバグ密度の現状が可視化されれば、そこからの課題を明らかにし、効率的に向き合うことが可能になります。
また、過去の傾向値がたまっていけば、ゾーン分析だけではなく未来の品質予測をする分析に活用し、データドリブンに品質を向上していくことも可能です。ぜひそのような視点をもってテスト密度、バグ密度と向き合ってみてください。

資料ダウンロード/動画視聴

ソフトウェアテスト入門動画

テスト計画入門動画

SHIFTサービス資料

テストサービス導入事例集

関連サービス