【IPA】テストケース密度・バグ密度 指標と基準値の考察

システム開発におけるテスト工数密度及びテストバグ密度について、IPA独立行政法人情報処理推進機構が公開しているソフトウェア開発データ白書の内容をもとに、自分の感覚と照らしてみたいと思います。

プロジェクトマネジメントするうえでも、普段自ら実装するうえでも、だいたいどれくらいのテストケース密度で、どれくらいの不具合を出すべきかというざっくりとした目安を持っておくことは重要だと思うため今回はその指標について考察します。

パッケージシステムの導入におけるテスト工数密度、テストバグ密度は、通常のエンハンス開発や保守開発と同様に捉えてよいと考えていますので、そういう意味ではあらゆるシステム開発・導入に活かすことができる値かと思います。

残念ながら公開されているデータが結合テストと総合テストだけでした。したがって、単体テストに関するテストケース密度やバグ密度については取り扱いがされていませんでした。

スポンサーリンク

テストケース密度

テストケース密度とは、単位規模あたりのテストケースの濃さです。つまり、わかりやすくいえば、どれくらいきめ細かくテストしているかを測るための指標です。テストケース密度とは別に、テスト工数密度を利用する場合もあります。テスト工数密度の場合はケース数ではなくテストにかけた時間そのものになりますが、テストケース密度を採用することの方が多いと思います。

新規開発や改良開発、再開といった開発種別のデータも公表されていますが、いちいち覚えられないので数値に関しては全開発種別を合算したデータをもとに考察します。また、ファンクションポイント数（FP数）あたりと、ステップ数（SLOC数）あたりのデータがありましたので両方取り上げたいと思います。

結合テストにおけるテストケース密度

IPAによる指標では、1,000FPあたり平均3,860ケース、中央値2,055ケースとのことでした。

一方で、1,000stepあたり平均472ケース、中央値50.5ケースとのことでした。

なお、データの紹介はしませんが、新規開発よりも改良開発の方がケース数が多い傾向にあることもわかりました。

総合テストにおけるテストケース密度

IPAによる指標では、1,000FPあたり平均1,845ケース、中央値587ケースとのことでした。

一方で、1,000stepあたり平均161ケース、中央値14.8ケースとのことでした。

なお、こちらもデータの紹介はしませんが、結合テストと同様に、総合テストにおいても新規開発よりも改良開発の方がケース数が多い傾向にあることもわかっています。また、結合テストと比べて、総合テストの方がテストケースが少ないということもわかります。

テストケース密度の基準値、考察

FP数だとなかなかイメージがしづらいため、単純なステップ数をもとに考察したいと思います。また、標準偏差が大きいことからも分かる通り平均値はどうしても最大値に引っ張られているため、中央値を参考にしてみたいと思います。

テストケース密度を受けての考察

1,000行のプログラムに対して100件を超えるテストケースとなると非常に多い印象を受けました。これは、難易度の高い機能をテストした最大値に引っ張られた結果だというように受け取っています。

私の感覚として、１日にまともにテストできるケース数は20件ほどという目安を持っているため、これではテストだけで1週間、平均だと1か月はかかる計算になってしまいます。※IPA情報処理推進機構が公開するデータには工数あたりのテストケース数も公開されており、１日あたり3ケースほどというデータもあります。したがって、筆者の感覚値ではなくデータをもとに検証されたい方はそちらをご覧ください。

一方で、入念なテストが必要な機能もあるということが見てとれるため、難易度の高い機能とそうでない機能とで濃淡を付けながらテストケースを設計することが重要だといえると思います。

テストケース密度の基準値

標準偏差も大きく、平均値は最大値にかなり引っ張られている印象があるため、プロジェクトで採用するテストケース密度の基準値としては中央値を採用すると現実的だと感じました。

そこで、結合テストでは50.5件/KSLOCを、総合テストでは14.8件/KSLOCを１つの目安とするのがおすすめです。

テストバグ密度

テストバグ密度とは、単位規模あたりのテスト不具合の多さです。つまり、わかりやすくいえば、どれくらい不具合が検出されているかを測るための指標です。

新規開発や改良開発、再開といった開発種別のデータも公表されていますが、こちらもいちいち覚えられないので今回は全開発種別を合算したデータをもとに考察します。

バグ数に関しては現象数と原因数がありますが、不具合として発覚しカウントした現象数ではなく、現象数から更に原因分析した結果である原因数を採用します。

結合テストにおけるテストバグ密度

IPAによる指標では、1,000FPあたり平均122件、中央値90.3件とのことでした。

1,000ステップあたり平均25.89件、中央値1.21件とのことでした。

総合テストにおけるテストバグ密度

IPAによる指標では、1,000FPあたり平均76.6件、中央値27.4件とのことでした。

1,000ステップあたり平均2.92件、中央値0.26件とのことでした。

テストバグ密度の基準値、考察

こちらもFP数だとなかなかイメージがしづらいため、単純なステップ数をもとに考えます。また、平均値はどうしても最大値に引っ張られているため、こちらも中央値を参考にします。

テストバグ密度を受けての考察

1,000行のプログラムに対して１件から３件ほどの不具合といったところでしょうか。こちらも平均値は最大値に引っ張られており、標準偏差が大きくなっているため、中央値や75%タイルを現実的な目標とするとよさそうです。

私の感覚としても、1,000行実装したら「結構やったな」という印象があり、簡単な１機能もしくは複数機能は実装できていると思います。その中で、超ざっくり言って結合テスト時に1~3件の不具合と考えば適当な値かなと思いました。

一方で、やはりテストケース密度と同じことが言えますが、入念なテストが必要な機能もあるということが見てとれるため、難易度の高い機能では不具合が多くでる傾向にあると思います。当然の傾向ではありますが、その点は理解しておく必要がありそうです。

テストバグ密度の基準値

標準偏差が大きく、平均値は最大値にかなり引っ張られている印象があるため、テストケース密度の基準値としてプロジェクトで採用するには中央値が現実的だと感じました。

そこで、結合テストでは1.2件/KSLOCを、総合テストでは0.3件/KSLOCを１つの目安としたいです。

まとめ

IPA情報処理推進機構が公開してくれているデータをもとに考察などしてきました。

細かい数字は覚えられませんが、今回の内容を受けて超ざっくりと覚えておきたいことは次の３点になるかと思います。数値は覚えやすいように丸めます。

• 高難易度の機能はテストケースを多く用意し、多くの不具合が出すことを心得ておく。
• テストケース密度の基準値は1,000行のプログラムあたり50ケースを目安とする。だいたい2.5日で実施できる量が現実的。（基準値には中央値を採用）
• バグ密度の基準値は1,000行のプログラムあたり1~2件の結合バグを目安とする。（基準値には中央値や75%タイルを採用）

スポンサーリンク

レビュー工数密度、レビュー指摘密度に関して分析結果をどう考察していくか、ゾーン分析をどのように行っていくかについてはこちらをご覧いただければ、今回の考察をもとにした時の品質管理の方法まで理解することができると思います。

【品質管理】【レビュー】【テスト】 ゾーン分析図の見方【４つのポジションの考え方】

今回はプロジェクトマネジメントにおける品質分析に関して、新人PM向けに解説したいと思います。メンバであっても考え方を理解しておくことは重要ですので、ぜひご覧ください。この記事を読んだら分かること設計レビューや単体テもっと見る

chaki-study.com

2024.07.08

出典元：IPAソフトウェア開発データ白書

本記事に登場するグラフやデータはすべてIPA ソフトウェア開発データ白書2018-2019を引用元としております。出典元は以下からご確認ください。

Copyright 2018-2019 IPA ソフトウェア開発データ白書2018-2019

「ソフトウェア開発データ白書」のダウンロード | アーカイブ | IPA 独立行政法人 情報処理推進機構

情報処理推進機構（IPA）の「「ソフトウェア開発データ白書」のダウンロード」に関する情報です。

www.ipa.go.jp

本記事は以下、使用条件に沿って利用しております。

独立行政法人情報処理推進機構は、以下の著作権表示を明記することを条件として、「本グラフデータの全部又は一部を複製、改変、公衆送信、又は翻訳/翻案し、第三者に有償又は無償で再配布すること」を許諾します。
著作権表示：「Copyright ○○○○（発行年） IPA」
なお、複製し再配布する場合は本使用条件を添付し、本使用条件に記載されている条件を配布先に遵守させて下さい。改変又は翻訳/翻案した場合は、新しく使用条件を設定することが可能ですが、「改変又は翻訳/翻案を行ったこと、(可能な限り)どの部分にどのような改変又は翻訳/翻案を行ったかの概略、当該図表等についての責任主体は利用者にある旨」を付記し、著作者人格権を行使しない旨の宣言条項を必ず含めて下さい。

グラフデータの注意点

前述の通り、工程定義が違えば、工程の割合も変わってきます。

本記事のデータの出典元である「IPA ソフトウェア開発データ白書2018-2019」における工程定義は次のようになっており、各工程別工期比率及び、工数比率における総合テストとは総合テスト（ベンダ確認）となります。