目次

• 1．バグ密度・テスト密度を使った品質管理はなぜ意味がないと言われてしまうのか
• 2．定量的な品質管理を行うために必要なこと
• 3．新たな手法：観点カバレッジとDDPモニタリング
• 4．アジャイル開発での適用
• 5．まとめ

1．バグ密度・テスト密度を使った品質管理はなぜ意味がないと言われてしまうのか

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

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

品質管理の歴史

ソフトウェアの品質管理は、製造業の生産プロセスでの品質管理の考え方をベースにしています。製造業では、例えば「完成品を毎月1000個チェックしたとして、先月までは不良品が月に1個だけだったのに今月は10個もある。今月の作成過程に何か問題があるかもしれない。」と考えて生産プロセスにおける原因を調査します。このように、過去のデータと最新のデータを比較できるのは、材料や設備などの5M（表1）が統一されているためです。

表1：製造業の5M

製造業と同様の品質管理をソフトウェア開発で行うためには、これら5Mと同等の要素を統一する必要があります。逆に、5Mが統一されていないプロジェクト間のデータを比較しても意味がないと言えます。極端な例で言えば、過去にCOBOLで開発した際のデータ（例えばバグ密度・テスト密度の中央値）と、新たにJavaで開発した際のデータを単純に比較しても、正当に評価できる可能性は低いです。

つまり「バグ密度・テスト密度には意味がない」と言われることがあるのは、5Mが同じ、もしくは類似している比較対象データを準備できていないことが理由と考えられます。長期間にわたって開発を繰り返しているプロジェクトであれば、蓄積した自プロジェクトのデータを活用することができますが、そうでない場合はバグ密度・テスト密度の適用が難しいことが多いでしょう。

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

昨今の開発では、クラウド、ノーコード／ローコード開発、さらにはAIなど、様々な技術が利用されています。そのため、5Mが類似したプロジェクトを過去事例から見つけることが年々困難になってきています。加えて、前述の技術を用いた開発では、人がソースコードを書かないケースが増えるため、バグ密度・テスト密度を計算する際の規模としてソースコード行数（SLOC）を用いるのは適切でないと考えられます（※4）。

そこで当社では、バグ密度・テスト密度に依存しない新たな品質管理の実践に取り組んでいます。

2．定量的な品質管理を行うために必要なこと

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

バグ密度・テスト密度を用いた品質管理では、その測定値の良し悪しを判断するために、それぞれの上限値・下限値と測定値を比較して評価する管理図分析や、双方の上限値・下限値に基づいて分類したゾーンのどこに測定値が属するかによって評価するゾーン分析などが用いられます。これらの分析手法における上限値・下限値といった閾値は、過去のプロジェクトのデータから統計的に設定しますが、5Mをはじめとする前提条件が異なるプロジェクトのデータを使った場合は、比較対象として妥当でない可能性があることは前述の通りです。

さらに、これらの分析手法を用いて品質を評価する際に、「測定値が閾値の中に収まっているからOK、収まっていないからNG」と単純に判定するのは誤りです。一次評価として使用するのは問題ありませんが、テスト対象の難しさや検出したバグの傾向などを考慮して、正しいプロセスで開発（テスト）しているか否かを総合的に判断する必要があります。したがって、プロセス品質の問題を見つけるには、バグ密度・テスト密度では情報が不足していると言えます。

以降では、これらの問題を解決するための新たな品質管理手法を紹介します。

3．新たな手法：観点カバレッジとDDPモニタリング

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

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

観点カバレッジ

テスト密度では規模当たり何件のテストを行っているかを評価していました。例えば、あるWeb画面に対するテストで、画面レイアウトだけ10件テストした場合も、画面レイアウトを3件と入力チェックを7件テストした場合も、同じ10件となります。同じ画面に対するテストなので規模は同じであるため、テスト密度も同じになります。つまり、どのようなテストをしたかの違いはテスト密度には表れません。「何件テストをしたのか」より「どのようなテストをしたのか」の方が品質管理をする上では重要な情報なのですが、テスト密度ではそれを把握できないという問題があります。

観点カバレッジの手法ではテスト観点に着目して、テストの網羅性を確認します（※7）。具体的には表2や表3に示すようなテスト観点とテスト対象を軸にとった表を使います。表中のセルにはテスト件数（テストケース数）を記録するもの（表2）と、バグ数を記録するもの（表3）の2つがあります。

テスト件数を記録した表2はテストの網羅性を確認するために用いられ、主にテストが0件の箇所に問題がないかを確認します。注意すべき点は0件だから即問題があるとはならないことです。例えば、表2では検索機能ではDBは更新されないため、テスト観点「DB更新」のテストが0件でも問題ありません。一方、同じ検索機能ではテスト観点「入力チェック」も0件になっていますが、検索文字列の長さや種類に関する入力チェックのテストが漏れている可能性があります。また、表に整理することでテスト観点間の比較やテスト対象間の比較がしやすくなります。例えば、更新機能は登録機能とほぼ同じテスト件数ですが、入力チェックだけは数が少ないため、テストが漏れているかもしれないと気付くことができます。この表は、テスト設計、すなわちテストケースを作成した時点で作ることができます。したがって、テスト観点に対して網羅的に、かつバランスよくテストできているかをテスト実行前に確認することで、テストプロセスの品質を高めていきます。

表2：観点カバレッジの表の例（テストの網羅性）

一方、バグ数に対して同様の表を作ったものが表3です。この表を使うと、バグが多すぎたり、少なすぎたりといったバラつきを確認することができ、品質の低いテスト対象や、テストが不足している可能性があるテスト対象やテスト観点に気づくことができます。バグの数が多いか少ないかは、実行したテストの数（表2）と見比べながら判断してもよいでしょう。また、テストの網羅性の表との違いとして、テスト観点に「該当なし」という列があります。これは、別の観点のテストを実行しているときにたまたまバグが見つかったようなケースを想像していただければよいと思います。つまり、そのバグを本来検出すべきテスト観点が漏れていたことが分かるという効果があり、テストプロセスの改善につなげることができます。

表3：観点カバレッジの表の例（バグの網羅性）

このように、観点カバレッジはテスト観点に着目することでテストケースやバグの中身にまで踏み込んで品質を評価、分析することができます。各テスト工程におけるテスト設計完了時、およびテスト実行完了時にそれぞれテストの網羅性、バグの網羅性を確認して、テストプロセスの適切さを確認します。しかし、これらの情報だけでは本当に十分なテストができたのかまでは判断できません。それを補うために2つ目の手法であるDDPモニタリングを組み合わせます。

DDPモニタリング

DDP（Defect Detection Percentage）は日本語では欠陥検出率などと訳され、「あるテスト工程で検出すべきバグをその工程でどれだけ検出できたか」を測るメトリクスです。算出方法は以下の通りで、いわゆる「すり抜けバグ」が増えると値が下がる特徴を持っています。

図1：DDPの計算式

DDPは、各テスト工程の完了時に計算して評価することができますが、テストを実行しながらバグが見つかるたびに値が変化しますので、その推移をモニタリングすることも有効です。それを当社ではDDPモニタリングと呼んでいます。DDPモニタリングでは、DDPが何％まで下がったら対策を打つのかをあらかじめ定めておき、単体テストや結合テストなどテスト工程ごとにDDPの推移を日々モニタリングして、問題を検知したら対策を行います。

図2のグラフを例に説明しましょう。この例では、4月に単体テスト、5月に結合テスト、6月にシステムテストを実行しています。グラフでは単体テストのDDPの推移を示しています。単体テスト期間のDDPは必ず100％のため割愛し、結合テストとシステムテストの期間のみを対象としています。グラフを見ると、結合テストの期間に入ってDDPが徐々に減少し、システムテストに入ってすぐに60％を下回りました（※8）。DDPモニタリングをしていれば、システムテストの完了を待たずにDDPが悪化したことに気づくことができます。この時点で、実施中のシステムテストを一旦止めて、単体テストの見直しや必要に応じて強化テストを行うなどの対策を実施します。

他のテスト工程についても同様に行い、各テスト工程が完了した後もモニタリングを継続して対策をとることで、リリースまでに品質を高めていきます。

図2：DDPグラフの例

2つの手法を組み合せる

観点カバレッジとDDPモニタリングは、管理対象に合ったタイミングでそれぞれを適用することで、組み合わせて使うことができます。図3のように管理対象のテスト工程の期間中は観点カバレッジを、工程完了後はDDPモニタリングを適用するのが基本となります。例えば結合テストは、結合テストの期間中は観点カバレッジで確認し、その後のシステムテスト以降の期間では結合テストで検出すべきバグがすり抜けていないかをDDPでモニタリングしていきます。

DDPモニタリングの例では、分かりやすくするためにDDPが悪化するパターンを載せましたが、実際には観点カバレッジを事前に使って網羅的なテストができていればバグのすり抜けを防ぐことができるため、DDPが悪化しないこともあるでしょう。もし、ある工程での品質問題を見逃したとしても、後のDDPモニタリングで検知できるため、観点カバレッジでの確認に時間をかけ過ぎることなく、経済的合理性のある品質管理を行うのが理想的です。

図3：適用する手法と実施タイミング

4．アジャイル開発での適用

紹介した2つの手法は、特に開発スタイルを問わないため、現在主流となりつつあるアジャイル開発でも適用することができます。しかし、アジャイル開発では開発期間が短いことや、反復的な開発であることなどに起因して、これらの手法がうまく適用できない場合があります。ここでは、アジャイル開発に適用した事例に基づき、適用時の注意点を紹介します。

そもそも、アジャイル開発ではバグが見つかったらすぐに修正してしまうことがあります。そのときにバグを記録せずに、バグ数をいちいちカウントしないこともあるでしょう。バグの情報がないと観点カバレッジ（バグの網羅性）やDDPモニタリングを適用することはできません。とはいえ、これらの手法を適用するためにバグの記録を義務づけて、アジリティが下がるのは本末転倒です。そのため、例えば「結合テスト以降はバグを記録しよう」というように、どのタイミングからバグを管理するかを決めて、その範囲で本手法を適用するのがよいでしょう。

その上で、まず観点カバレッジをアジャイル開発に適用するケースを考えてみます。2週間程度の短いイテレーション（スプリント）の期間では、すべてのテスト対象、すべてのテスト観点を開発・テストすることはできません（※9）。そのため、範囲を絞ってテストすることになります。範囲の絞り方としては、開発する対象を絞る方法（図4の例1）や、テスト観点を絞る方法（図4の例2）などが考えられ、現実的には2つの例を組み合わせる形になるかもしれません（※10）。この場合、図4を見ても分かる通り、最初のイテレーションの時点では表はすべて埋まっていません。そのため、テストの網羅性とバグの網羅性のいずれでも、その時点で数のバラつきを判断するのが難しい可能性が高いです。テストが0件という場合でも、以降のイテレーションで実施する予定という可能性があるため、それが問題か否かの判断が難しくなります。したがって、アジャイル開発で観点カバレッジを使う際は、イテレーションが進むにつれて情報量が増えていくことで品質評価ができるようになる点に注意が必要です。そのため過去のイテレーションにさかのぼって評価するケースも出てきます。

図4：アジャイル開発での観点カバレッジの適用イメージ（イテレーション1完了時）

続いてDDPモニタリングをアジャイル開発に適用するケースを考えてみます。アジャイル開発では、2週間程度の短いイテレーションの中で単体テストから結合テスト、場合によってはシステムテストまで実施することになります。各テスト工程は並行して実施されるか、順次行われるとしても非常に短い期間で実施されます。そのため、テスト工程を評価対象としたDDPのモニタリングが非常に難しくなります。また、イテレーションが変わるとDDPはリセットされるため、継続的なモニタリングができないという問題も生じます（※11）。そこで、テスト工程をすり抜けたバグではなく、イテレーションをすり抜けたバグに着目してDDPを計算するという工夫が考えられます。例えば、図5ではイテレーション1を評価対象としたDDPをグラフ化したものになります。本来イテレーション1で検出すべきだったバグがイテレーション2以降の開発中に見つかったり、既にリリースされたプロダクトをユーザーが使用する中で見つかったりした場合にDDPが下がっていきます。この分析を行うためには、バグを検出した際に「本来検出すべきイテレーション」の情報を記録する必要がある点に注意が必要です。

図5：アジャイル開発でのDDPモニタリングの適用イメージ

実際のアジャイル開発では、テストだけを行うイテレーションを設けるケースなどもありますので、いずれの手法を適用する場合でも、適切な評価ができるように自身のプロジェクトの進め方に合わせる必要があります。

5．まとめ

ソフトウェア開発における定量的な品質管理で、主として使われているバグ密度・テスト密度の利用前提と、昨今の開発方法多様化による課題を解説しました。この課題を乗り越えるために当社で実践している新たな定量的品質管理の手法である観点カバレッジとDDPモニタリングをご紹介しました。当社ではこれらの手法の活用を進めており、プロジェクトマネジメント学会をはじめとした様々な場で適用事例を公開しています。

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