ソフトウェア開発では、長年定量的な品質管理（※1）の指標として、バグ密度（※2）・テスト密度（※3）が利用されています。
しかしインターネットで「バグ密度」と検索すると関連する検索キーワードに「意味ない」が上位に出てくるように、効果を疑問視する声が少なくありません。

定量的な品質管理が重要なことに異を唱える方はほぼいないと思いますが、バグ密度・テスト密度を利用する手法に対しては批判があがるのはなぜなのでしょうか。
バグ密度・テスト密度はどのような前提の下でどう判断する指標なのかを見ていきましょう。

品質管理の歴史

バグ密度・テスト密度を使った品質管理の歴史を紐解いてみると1980年にはすでに利用されていました。
製造業の生産プロセスでの品質管理の考え方がベースになっているようです。

製造業では、例えば「完成品を1000個チェックしたとして、先月までは不良品が1個だったのに今月は10個もある。作成過程の途中に何か問題があるかもしれない。」と考えて原因を調査します。
このような取り組みが効果を発揮するためには、材料や設備などの5M（以下の表を参照）を統一することが重要と言われています。

図1：製造業の5M

ソフトウェア開発も同様に、5Mの統一された比較対象データがあることによりバグ密度・テスト密度を使った品質管理が効果を発揮すると考えられます。逆に比較対象データの5Mが揃っていなければ意味のない取り組みとなりかねません。
極端な例で言えば、COBOLで開発した過去データ（バグ密度・テスト密度の中央値）と、今回Javaで開発したデータをそのまま比較しても、有効に評価できる可能性は低いです。

つまり「バグ密度・テスト密度には意味がない」と言われることがあるのは、5Mが揃っている比較対象データを正しく準備できているのか、疑問視されているのと同義と考えられます。

昨今の開発方法多様化の影響

昨今の開発では、業務パッケージソフトウェアやSaaS（Software as a Service）、開発自動化ツールなど、多種多様な方法が利用されています。そのため、バグ密度・テスト密度を使った品質管理で重要となる5Mの似た過去事例のデータを集めることが、年々困難になってきています。

そこで当社ではバグ密度・テスト密度に依存しない品質保証が可能となる、新たな手法の実践に取り組んでいます。

バグ密度・テスト密度は、開発したプロダクトそのものの品質ではなく、それに代わる情報（代用特性）として用いられています。
「正しいプロセスで開発すれば、正しいプロダクトができる」という仮説に基づいて、「プロセス品質」を確認しています。

またバグ密度・テスト密度では上限値・下限値といった閾値を定め評価を行っています。
もし、「実績値が閾値の中に納まっているから品質に問題ない」と判断されているようでしたら、”誤用”になります。
閾値から外れている場合には「これまでの開発と異なる事象が発生しているためプロセス品質に問題があるかもしれない」と考えるのが適切な使い方になります。

このようなプロセス品質の違和感を察知するという目的を、バグ密度・テスト密度を使わずに実現する手法を策定しました。

これからご紹介する手法は、ソフトウェア品質シンポジウム2020で発表しBest Presentation Awardを受賞したものです。（※4）
Best Presentation Awardはシンポジウムの聴講者から最も多く投票された発表に授与されるもので、当社以外の皆様も同じ課題を持たれ、解決策を探されていることの現れではないかと思います。

この手法は、観点カバレッジとDDPモニタリングという2つの手法を組み合わせて実現していますので、それぞれを紹介していきます。

観点カバレッジ

テスト密度では規模当たり何件のテストを行っているかを評価していました。例えば画面レイアウトだけ100件テストした場合も、画面レイアウトを30件と動作を70件テストした場合も、同じ100件となり、どのようなテストをしたのかといった内容が表現されません。
「何件テストをしたのか」より、「どのようなテストをしたのか」の方が品質への寄与が大きいのですが、テスト密度ではそれを把握し辛いという特性がありました。

観点カバレッジの手法ではテスト観点を軸とし、その網羅性を確認していきます。（※5）
具体的には以下の表のようなテスト観点とテスト対象を軸にとったマトリクスを使います。中のセルにはテスト件数を集計します。
テストが0件の箇所に問題が無いか確認し、問題がある場合にはテストを追加するなどの対策をとります。

注意すべき点は0件だから即問題があるとはならないことです。例えばバッチ処理のテスト対象において画面レイアウトの正当性のテスト観点のテストが0件でも問題ありません。
重要なのは0件で問題があるのかないのか精査する点にあります。
このように、テスト観点に対して網羅的にテストを行えているか確認することでプロセス品質を高めていきます。

図2：観点カバレッジ表の例

スペースの関係で割愛しますが、バグ数に対しても同様の表を作って確認していきます。
ソフトウェア品質シンポジウムの発表では紹介をしているため、そちらを参照してください。（※4）

ただ観点カバレッジは、プロセス品質のテスト観点に着目した問題点は検知できますが、その妥当性を判断できません。
それを補うために2つ目の手法であるDDPモニタリングと組み合わせて実施します。

DDPモニタリング

DDP（Defect Detection Percentage：欠陥摘出率）というメトリクスがあります。
算出方法は以下の通りで、すり抜けバグが増えると値が下がる特徴を持っています。

図3：DDPの計算式

DDPモニタリングは、何％までDDPが下がったら対策を打つのかあらかじめ定めておき、結合テスト・総合テストなどの各テストフェーズのDDPの変遷をモニタリングし、問題を検知したら対策を行うという手法です。

以下のグラフを例にして説明します。
総合テストで見つけるべきバグのDDPの値は、総合テストの期間で見つけられればすり抜けバグではないため100％のまま推移します。

その後、受け入れテストの期間に入りすり抜けバグが見つかり、DDPは60％まで落ちています。
この場合には、実施中の受け入れテストを一旦止めて総合テストの強化テストを行う等の対策を実施します。

このように実施の完了したテストフェーズの対象へのモニタリングと対策を継続することで、リリースまでに品質を高めていきます。

図4：DDPグラフの例

2つの手法を組合せる

観点カバレッジとDDPモニタリングは、以下の図のように組み合わせて使います。
例えば結合テストは、結合テストの期間中は観点カバレッジで確認し、その後の総合テスト以降の期間では結合テストで検出すべきバグがすり抜けていないかをDDPでモニタリングしていきます。

DDPグラフの例では分かりやすくするためにDDPが悪化するパターンを載せましたが、実際には観点カバレッジの手法を行うためDDPが悪化するケースは稀です。
もし品質問題の見逃しがあったとしても後のDDPモニタリングで検知できるため、観点カバレッジでの確認に時間をかけ過ぎることなく、経済合理性のある品質管理を行うことができます。

図5：実施タイミング

ソフトウェア開発における定量的な品質管理で、現在主として使われているバグ密度・テスト密度の利用前提と、昨今の開発方法多様化による影響を解説しました。
これを乗り越えるために当社で実践している新たな定量的品質管理の手法である、観点カバレッジとDDPモニタリングをご紹介しました。

40年以上に渡り使われてきたやり方を変えるのは容易ではないと実感しています。1社のみで突破するには障壁が高く、業界全体の取り組みとしていきたいと考えて本件などの社外発信をしています。
業界内で一緒に挑んでいただける仲間を増やし、日本のソフトウェア開発業界の長年の課題を乗り越えることを目指します。