バグ密度とは、ソフトウェア開発において、開発規模に対して発生しているバグの割合を示すものです。開発したソフトウェアの品質基準として活用したり、開発プロセスの改善や振り返りに使用されたりする指標ですが、どのように計算するのかよくわかっていないという人もいるでしょう。
本記事では、バグ密度の概要とテスト密度との関係、計算式やゾーン分析について詳しく解説します。バグ密度の計算式がわからない方や活用方法がわからない方は、ぜひ参考にしてください。
株式会社SHIFTでは、ソフトウェアテストに関して豊富な実績とテストナレッジを保有しており、あらゆるお客様のニーズを満たしたテスト・品質保証を上流～下流（テスト計画・テスト設計・テスト実行・テスト品質管理）まで一気通貫でご依頼いただけます。
ソフトウェアテストのことならSHIFT
「3分で知るSHIFTのテストサービス」の資料ダウンロードページへ
＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ
バグ密度とは
バグ密度とは、ソフトウェア開発規模に対してどのくらいバグが発生しているかを示す指標です。一般的には、「バグ数／規模」で算出し、規模の単位ではFP（Function Point：機能数・機能の複雑性）、LOC（Lines Of Code：プログラムの行数）などで算出されます。ドキュメントの場合も「バグ数／ページ数」でバグ密度を評価することがありますが、ここではソフトウェアに絞って説明を進めます。計算式の詳細は「バグ密度の計算式」で詳しく解説します。
バグ数で評価した場合、大きなもののバグ数が小規模なものに比べてどうしても多くなります。しかし、密度であれば人口密度のように、規模感の違うソフトウェアでも同じ基準で比較することができます。
バグ数として絶対的な評価することも必要ですが、バグを密度で表すことで、異なる規模のプロジェクト（プロダクト）や開発チームでのバグ総量推移や傾向比較などがしやすくなります。また、プロセスの課題をはじめ、開発工程の弱点把握など、バグの単純な量だけでは測れないバグの質に対しての問題にいち早く気づくことができるようになるでしょう。
ソフトウェアテストに外注の選択肢を
「ソフトウェアテストを外注すべき5つの理由とは！？」の資料をぜひご覧ください。
バグ密度を測るうえで重要なテスト密度とは
テスト密度とはソフトウェア開発規模に対してどのくらいテストを実行したかを示す指標です。バグ密度と同様に、一般的には「テスト数／規模」で算出し、規模の単位ではFPやLOCなどで算出されます。また、同様に実施するテストケースの基準値や次期テスト工程の計画に参考となる指標として活用します。
便利なテストケーステンプレートはこちらからダウンロードいただけます。
＞＞テストケーステンプレートのダウンロードページへ
バグ密度とテスト密度の関係性はシンプルです。例えば、以下のように考えることができるようになります。
リリースまでに10,000ケーステストを実施して、先月まではバグが10件だったのに対し、今月は同規模でのリリースでテスト数も同じだったのにバグが100件も発生。開発工程やテスト工程の途中に何か問題があるかもしれない。
バグ密度の計算式
バグ密度を計算するには、開発規模の評価方法はFPやLOCなどの選択肢がありますが、いずれも同じ計算式で求めることができます。
分母は、機能数に着目する場合はFP、純粋に開発量に着目するのであればLOC（もしくは1,000倍のKLOC）を使用します。どちらも開発規模に関係なく、バグの割合を定量化できるのが特徴です。また、テスト密度に関しても、同じような計算式で求められます。
こちらも同様に、機能に着目するのであればFP、開発行数であればLOCを使用して算出します。いずれの場合も開発規模を分母にすることで、開発規模に関係なく密度を計算することができるのです。
バグ密度を分析する方法「ゾーン分析」
「テスト密度」と「バグ密度」指標の法則性を活用した分析手法として、ゾーン分析があります。ゾーン分析は2つの異なる指標の基準値を使って数値を可視化し評価を行います。
以下のようにマトリックスで表現し、9ゾーンに分けてバグ密度とテスト密度を可視化し、パターン化する手法です。ここでは9つのゾーンについて、一般的な評価と確認すべきことを解説します。
①ゾーン（品質良好）
ゾーン分析は「①ゾーン以外は問題あり」というのが基本です。
①ゾーンは、品質良好となった結果（基準値）と考えます。
ただし、①ゾーンに入ってもあくまで傾向値となるため詳細確認は必要です。バグの結果を含め妥当性を確認し、重大なエラーが存在しないか念のため確認してください。
②、④ゾーン（テスト密度は高いが、バグ密度は低い、やや低い）
②ゾーンはテスト密度が高くて、バグ密度は通常のゾーンです。
④ゾーンはテスト密度が高くて、バグ密度が低いゾーンです。
いずれもテスト密度が標準より高いにも関わらずバグが適切に発見できていないので、テスト効率が悪い可能性が疑われ、テスト内容の点検が必要です。
②、④ゾーンは一見テストが十分実施されていて、品質が高いように見えます。ところが、テスト密度に比べバグ密度が低い状態なので、バグを見つけられないテストを多く実施しているということになります。特に④のゾーンはいつもの傾向値よりバグ密度が低いので、バグがまだ潜んでいる可能性があるでしょう。
テストケースの妥当性や網羅性を確認し、テストメンバーのスキルに差が生じてないか、また見当違いなテストを実施していないかなどの確認をしてください。
便利なテストケーステンプレートはこちらからダウンロードいただけます。
＞＞テストケーステンプレートのダウンロードページへ
③、⑨ゾーン（テスト密度が低く、バグ密度も低い、やや低い）
⑤、⑥ゾーン（テスト密度が高く、バグ密度が高い）
⑤ゾーンは通常のテスト密度、⑥ゾーンは高いテスト密度でテストを実施し、いずれもバグ密度が高いゾーンになります。テストを多く実施し、バグが多く検出されているので一見問題なさそうに見えますが、バグが通常より多く出ていることを問題と捉えなければなりません。その前の工程までのレビューやテストで検出されるべきバグが、この工程で見つかっているという可能性があります。
まずは、検出されているバグが、本来その工程で摘出されるべきバグであったかを確認しなければなりません。もし、前工程までに摘出されているべきバグが多いのであれば、その工程に立ち返ってレビューやテストをやり直す必要がでてきます。そうでなければ作りこみの品質が悪いということなので、通常と何が違うのかを明確にしましょう。また、⑥ゾーンはテスト密度が高いことから、不要なテストケースが発生していないかなどを確認し次回以降のテスト工数削減につなげられる可能性があります。
⑦、⑧ゾーン（テスト密度が低く、バグ密度が高い、やや高い）
⑦、⑧ゾーンはテスト密度が低いにも関わらず、バグが多く摘出されているゾーンです。テスト密度が低いのでテストが十分にできていないといえますし、それでもバグが多く見つかっていることから、前工程のレビューやテストにも問題があった可能性が高いでしょう。追加テストを実施するとさらにバグが出ることも想定されるので、この状況になっている要因を洗い出して対応を検討後にテストを再開することをおすすめします。
また、テストケース数が少ないことから、テストの網羅性を確認しつつ、不足のテストがないかを確認してください。もし前工程に問題があった場合、その工程のレビューやテストに立ち返り、まだ確認されていないバグの検知を目指しましょう。
ゾーン分析の利用注意点
いずれかのゾーンに入っても、ゾーン分析において開発者や開発プロセスの良し悪しが判断できるわけではありません。プロジェクトおよびプロダクトの特性などを考えて、なぜそのゾーンに入ったかということを分析することが一番の品質向上につながっていきます。
ゾーン分析を念頭に計測をはじめると、計測方法によっては①ゾーンに入るようにテストケース数やバグ数を調整するという本末転倒な状況に陥る可能性もあるため注意が必要ですが、計測結果を一つの判断基準として捉え、品質向上のために活用することは大いに意義のあることです。
関連サービスについて
まとめ
バグ密度とテスト密度は、ゾーン分析を行うために必要な指標です。母数が大きくなってバグ数が少なくなれば、それだけソフトウェアの信頼度も高くなります。母数が少ない場合も分析を行うための基準値を作成する準備と捉え、分析の環境を整えるようにしましょう。
バグ密度やテスト密度の母数が少なくソフトウェアの信頼度の確認ができないとお悩みの場合は、SHIFTまでご相談ください。SHIFTにはこれまで蓄積してきた数多くの実績がございます。バグ密度やテスト密度などの信頼できる分析環境が整っていない場合も安心してソフトウェアの信頼度を確認できます。分析環境が整っておらず、分析できない状況でお悩みの方は、ぜひSHIFTまでお問い合わせください。
＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ
ソフトウェアテストの悩みはSHIFTが解決できます！
「自社で効率よくソフトウェアテストを実施できない…。」
「どうしてもテスト工数が膨らんでしまう…。」
「期日に間に合わない…。」
「リリース後に不具合が発生してしまっている…。」
といった悩みを抱えている企業は多いでしょう。
監修
株式会社SHIFT
「ヒンシツ大学」クオリティ エヴァンジェリスト 永井 敏隆
大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。
担当講座
ダウンロード
