2023.11.30

バグ密度とは？ソフトウェア開発における品質可視化のための指標について解説

著者株式会社SHIFT　マーケティンググループ

バグ密度とは、ソフトウェア開発において、開発規模に対して発生しているバグの割合を示すものです。開発したソフトウェアの品質基準として活用したり、開発プロセスの改善や振り返りに使用されたりする指標ですが、どのように計算するのかよくわかっていないという人もいるでしょう。

本記事では、バグ密度の概要とテスト密度との関係、計算式やゾーン分析について詳しく解説します。バグ密度の計算式がわからない方や活用方法がわからない方は、ぜひ参考にしてください。

株式会社SHIFTでは、ソフトウェアテストに関して豊富な実績とテストナレッジを保有しており、あらゆるお客様のニーズを満たしたテスト・品質保証を上流～下流（テスト計画・テスト設計・テスト実行・テスト品質管理）まで一気通貫でご依頼いただけます。

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ

バグ密度とは

バグ密度とは、ソフトウェア開発規模に対してどのくらいバグが発生しているかを示す指標です。一般的には、「バグ数／規模」で算出し、規模の単位ではFP（Function Point：機能数・機能の複雑性）、LOC（Lines Of Code：プログラムの行数）などで算出されます。ドキュメントの場合も「バグ数／ページ数」でバグ密度を評価することがありますが、ここではソフトウェアに絞って説明を進めます。計算式の詳細は「バグ密度の計算式」で詳しく解説します。

バグ数で評価した場合、大きなもののバグ数が小規模なものに比べてどうしても多くなります。しかし、密度であれば人口密度のように、規模感の違うソフトウェアでも同じ基準で比較することができます。

バグ数として絶対的な評価することも必要ですが、バグを密度で表すことで、異なる規模のプロジェクト（プロダクト）や開発チームでのバグ総量推移や傾向比較などがしやすくなります。また、プロセスの課題をはじめ、開発工程の弱点把握など、バグの単純な量だけでは測れないバグの質に対しての問題にいち早く気づくことができるようになるでしょう。

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

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

バグ密度とテスト密度の関係性はシンプルです。例えば、以下のように考えることができるようになります。

リリースまでに10,000ケーステストを実施して、先月まではバグが10件だったのに対し、今月は同規模でのリリースでテスト数も同じだったのにバグが100件も発生。開発工程やテスト工程の途中に何か問題があるかもしれない。

また、バグ密度やテスト密度の計測を継続すると、基準値（標準値）や傾向値といった確認ができるようになり、開発規模にかかわらず比較も可能になります。そうなると現在のプロジェクトの状況が見えてくることがあります。

・バグ密度が低い場合、本当に品質がよいと判断してよいのか
・バグ密度が低くテスト密度も低い場合、テストがそもそも足りていないのではないのか

上記のような判断のきっかけを与えてくれます。このようにテスト密度とバグ密度には関係性があり、品質評価をする際に有効な判断材料となる法則がある程度見えて来るのです。詳細は「バグ密度を分析する方法「ゾーン分析」」で詳しく解説しています。ぜひ参考にしてください。

＞＞テストケースとは？書き方や満たすべき要件について解説

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

バグ密度の計算式

バグ密度を計算するには、開発規模の評価方法はFPやLOCなどの選択肢がありますが、いずれも同じ計算式で求めることができます。

バグ密度＝検出バグ数（件）÷開発規模

分母は、機能数に着目する場合はFP、純粋に開発量に着目するのであればLOC（もしくは1,000倍のKLOC）を使用します。どちらも開発規模に関係なく、バグの割合を定量化できるのが特徴です。また、テスト密度に関しても、同じような計算式で求められます。

テスト密度＝テスト件数÷開発規模

こちらも同様に、機能に着目するのであればFP、開発行数であればLOCを使用して算出します。いずれの場合も開発規模を分母にすることで、開発規模に関係なく密度を計算することができるのです。

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

「テスト密度」と「バグ密度」指標の法則性を活用した分析手法として、ゾーン分析があります。ゾーン分析は2つの異なる指標の基準値を使って数値を可視化し評価を行います。

以下のようにマトリックスで表現し、9ゾーンに分けてバグ密度とテスト密度を可視化し、パターン化する手法です。ここでは9つのゾーンについて、一般的な評価と確認すべきことを解説します。

①ゾーン（品質良好）

ゾーン分析は「①ゾーン以外は問題あり」というのが基本です。
①ゾーンは、品質良好となった結果（基準値）と考えます。

ただし、①ゾーンに入ってもあくまで傾向値となるため詳細確認は必要です。バグの結果を含め妥当性を確認し、重大なエラーが存在しないか念のため確認してください。

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

②ゾーンはテスト密度が高くて、バグ密度は通常のゾーンです。
④ゾーンはテスト密度が高くて、バグ密度が低いゾーンです。
いずれもテスト密度が標準より高いにも関わらずバグが適切に発見できていないので、テスト効率が悪い可能性が疑われ、テスト内容の点検が必要です。

②、④ゾーンは一見テストが十分実施されていて、品質が高いように見えます。ところが、テスト密度に比べバグ密度が低い状態なので、バグを見つけられないテストを多く実施しているということになります。特に④のゾーンはいつもの傾向値よりバグ密度が低いので、バグがまだ潜んでいる可能性があるでしょう。

テストケースの妥当性や網羅性を確認し、テストメンバーのスキルに差が生じてないか、また見当違いなテストを実施していないかなどの確認をしてください。

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

③ゾーンは、テスト密度は通常であるのにバグ密度が低いゾーン、⑨ゾーンはテスト密度もバグ密度も低いゾーンです。特に⑨ゾーンはテスト密度が低く、バグも検出できていない状態のため、テストを実施していると語ることがむずしい状況です。早急な改善が必要な状況にあたります。

対応策としてはテスト計画に沿いテストの網羅性や抜け漏れを確認しましょう。そのうえでテストケース、テストリソースを確認し、必要であれば追加テストを実施します。

＞＞SHIFTが考える理想的なテストリソース量とは？2つの観点とフェーズにおける算出方法について解説

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

⑤ゾーンは通常のテスト密度、⑥ゾーンは高いテスト密度でテストを実施し、いずれもバグ密度が高いゾーンになります。テストを多く実施し、バグが多く検出されているので一見問題なさそうに見えますが、バグが通常より多く出ていることを問題と捉えなければなりません。その前の工程までのレビューやテストで検出されるべきバグが、この工程で見つかっているという可能性があります。

まずは、検出されているバグが、本来その工程で摘出されるべきバグであったかを確認しなければなりません。もし、前工程までに摘出されているべきバグが多いのであれば、その工程に立ち返ってレビューやテストをやり直す必要がでてきます。そうでなければ作りこみの品質が悪いということなので、通常と何が違うのかを明確にしましょう。また、⑥ゾーンはテスト密度が高いことから、不要なテストケースが発生していないかなどを確認し次回以降のテスト工数削減につなげられる可能性があります。

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

⑦、⑧ゾーンはテスト密度が低いにも関わらず、バグが多く摘出されているゾーンです。テスト密度が低いのでテストが十分にできていないといえますし、それでもバグが多く見つかっていることから、前工程のレビューやテストにも問題があった可能性が高いでしょう。追加テストを実施するとさらにバグが出ることも想定されるので、この状況になっている要因を洗い出して対応を検討後にテストを再開することをおすすめします。

また、テストケース数が少ないことから、テストの網羅性を確認しつつ、不足のテストがないかを確認してください。もし前工程に問題があった場合、その工程のレビューやテストに立ち返り、まだ確認されていないバグの検知を目指しましょう。

ゾーン分析の利用注意点

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

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

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

まとめ

バグ密度とテスト密度は、ゾーン分析を行うために必要な指標です。母数が大きくなってバグ数が少なくなれば、それだけソフトウェアの信頼度も高くなります。母数が少ない場合も分析を行うための基準値を作成する準備と捉え、分析の環境を整えるようにしましょう。

バグ密度やテスト密度の母数が少なくソフトウェアの信頼度の確認ができないとお悩みの場合は、SHIFTまでご相談ください。SHIFTにはこれまで蓄積してきた数多くの実績がございます。バグ密度やテスト密度などの信頼できる分析環境が整っていない場合も安心してソフトウェアの信頼度を確認できます。分析環境が整っておらず、分析できない状況でお悩みの方は、ぜひSHIFTまでお問い合わせください。

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ

監修

株式会社SHIFT
「ヒンシツ大学」クオリティエヴァンジェリスト　永井敏隆

大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。

担当講座

・コンポーネントテスト講座
・テスト自動化実践講座
・DevOpsテスト入門講座
・テスト戦略講座
・設計品質ワークショップ
など多数

――――――――――
ヒンシツ大学とは、ソフトウェアの品質保証サービスを主力事業とする株式会社SHIFTが展開する教育専門機関です。
SHIFTが事業運営において培ったノウハウを言語化・体系化し、講座として提供しており、品質に対する意識の向上、さらには実践的な方法論の習得など、講座を通して、お客様の品質課題の解決を支援しています。
https://service.shiftinc.jp/softwaretest/hinshitsu-univ/
https://www.hinshitsu-univ.jp/
――――――――――

この記事を書いた人

著者株式会社SHIFT　マーケティンググループ

SHIFTは「売れるサービスづくり」を得意とし、お客様の事業成長を全力で支援します。無駄のないスマートな社会の実現に向けて、ITの総合ソリューションを提供する会社です。

サービスサイト：https://service.shiftinc.jp/
コーポレートサイト：https://www.shiftinc.jp/
X（旧Twitter）：https://twitter.com/SHIFT_cp

ご支援業種

製造、金融（銀行・証券・保険・決済）、情報・通信・メディア、流通・EC・運輸、ゲーム・エンターテイメント

など多数

前のページへ

次のページへ

コラム一覧に戻る

バグ密度とは？ソフトウェア開発における品質可視化のための指標について解説

バグ密度とは

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

バグ密度の計算式