品質向上のテクニック

  1. Qbook+
  2. 品質向上のテクニック
  3. ソフトウェアのテスト品質を測る指標「テスト密度」「バグ密度」について解説

ソフトウェアのテスト品質を測る指標「テスト密度」「バグ密度」について解説

ソフトウェアのテスト品質を測る指標「テスト密度」「バグ密度」について解説

「テスト密度」と「バグ密度」。どちらもソフトウェア品質の生命線と言える、テスト工程において分析すべき項目ですが、その品質評価は正しく行えているでしょうか。テスト工程で品質評価が正しくされないと、検出すべきバグに気づかず、稼働後の障害につながる場合もあります。
今回はテスト密度とバグ密度を分析することで、問題点の発見、および効果的な対策を行う方法を解説します。

テスト密度とは

8607-00052-2

テスト密度とは、テストの量が十分であるかを示す指標です。「テストケース数/規模」で算出します。テストケース数だけでなく規模も考慮することで、テストの量が十分かを判断する目安となります。
規模については、プログラムの行数(LOC:Lines of Code)や機能数、機能の複雑性(FP:Function point)によって数値化することが一般的です。

テスト密度などの定量的な値は、テスト計画時に目標値を決めておき、テスト期間中や完了時に目標値との差異を比較し、品質評価の参考にします。もし、テスト密度が目標値より低ければ抜けているテストケースがあり、反対に高ければ過剰にテストを行っている可能性があります。

目標値は、社内の標準値を設定します。社内の標準値がなければIPA(独立行政法人 情報処理推進機構)などが公表している指標値をもとに、プロジェクト特性を考慮して決定しましょう。
プロジェクト特性とは「新規案件なのか、もしくは改修案件なのか」「言語は何か」「人員は経験豊富か」などのことです。それらによって、各指標値は大きく変わることもあります。

テスト密度はソフトウェアのテスト品質を測るのに役立つ指標ですが、テストの網羅性を測ることはできないため注意が必要です。
例えば、テスト密度が十分であっても、テスト内容が重複ばかりしていたら、テストできていないケースがある可能性があります。そのため、ブラックボックステストやホワイトボックステストも活用してテストケースの過不足をチェックしましょう。

バグ密度(欠陥密度)とは

8607-00052-3

バグ密度(欠陥密度)とはバグの量を示す指標です。「バグ数/規模」で算出します。バグ数だけでは、規模が異なる別のプログラムとバグの多さを比較できませんが、バグ密度であれば比較することができます。バグ密度を収集、分析することで、バグが多いか少ないかが分かるだけでなく、プログラマーのスキル不足やテスト不備などの問題を発見するきっかけにもなります。

バグ密度の活用方法は、テスト密度と同様にテスト計画段階で目標値を定め、テスト期間中や完了時に目標値との差を確認します。もし、バグ密度が目標値より低ければ品質が良い、もしくはテストケースが不足している場合があります。バグ密度が目標値より高ければ品質が悪い、もしくはプログラムの難易度が高い可能性があると言えます。
バグ密度が低ければ品質が良い、高ければ悪いという単純なことではなく、あくまで指標として活用していく姿勢が必要です。

テスト密度とバグ密度の関係

8607-00052-4

ここまで、テスト密度とバグ密度をそれぞれ解説してきましたが、この2つは同時に分析することで有益な情報を開発者たちに与えてくれます。

例えば、「バグ密度が低い」という情報だけだと、品質が良いと判断してしまいそうになりますが、「バグ密度が低く、テスト密度も低い」となるとどうでしょうか。この場合は、テスト不足を疑う必要があるでしょう。
このように、定量的品質評価をするうえで、テスト密度とバグ密度との組み合わせは有効活用できます。

ゾーン分析について

8607-00052-5

「テスト密度」と「バグ密度」の指標を分析する手法として、ゾーン分析があります。今回は、横軸をテスト密度、縦軸をバグ密度とし、9つのゾーンに分けた図を解説します。

ゾーンに分割することで、各指標の特徴が見えやすくなり、デバッグの際に原因や対策をある程度パターン化することができるのです。

それでは、9つのゾーンについてご説明します。

ゾーン分析

ゾーン1

ゾーン分析

ゾーン1は良好な結果であったと考えます。テスト工程および前段階である設計・開発工程の品質が適切だったということができます。

ゾーン7、8(テスト密度が低く、バグ密度が高い)

ゾーン分析

ゾーン7、8はテストが不十分であるにも関わらず、バグが多く検出されていることから、設計や開発工程に問題があった可能性が高いと言えます。追加テストを実施するとさらにバグが出る可能性が高いため、テストの早い段階でバグの内容と原因を確認し、対応した方が良い場合もあるでしょう。

また、テストケース数が少ないことから、テストの網羅性も確認すべきです。設計や開発工程の品質に問題があるとすれば、発見されていないバグが存在する確率は高くなります。
テストケースに抜けている観点がないかどうかをチェックし、追加テストを実施する必要があります。

ゾーン5、6(テスト密度が高く、バグ密度も高い)

ゾーン分析

ゾーン5、6はテストを多く実施し、バグが多く検出されているので問題なさそうですが、まずはソフトウェアの品質が悪いのではないかと疑ってみましょう。
テストをどれだけ多く実施しても、一般的にバグ数はS字カーブ(ゴンペルツ曲線)を描いて収束し、バグ密度は標準的な値に落ち着くことが多いものです。

ゾーン5、6の場合、まず検出されたバグの内容を確認します。開発内容の難易度の高さや、テスト環境不備が原因であり、かつバグ検出数がテスト終盤に向けて収束しているようであれば問題ないと考えられます。
該当工程で検出されるべき妥当なバグであれば、特定の機能や担当者ごとにバグ密度を確認します。もし、バグが特定の開発担当者に集中している場合は、スキル不足の可能性があるため、その担当者の成果物を再レビューしましょう。

さらに、テスト密度が高いことから、無駄なテストケースがないか確認することで、次回以降の開発のテスト工数削減につなげることができます。

ゾーン3、9(テスト密度が低く、バグ密度も低い)

ゾーン分析

ゾーン3はテスト密度が低く、バグも検出できていない状態のため、品質の判断すらできません。追加テストの実施により、バグが多く検出される場合もあれば、ほとんど検出されない場合もあります。
対策として、まずはテストケースの網羅性を確認しましょう。具体的にはテストの観点、テストケースに抜けがなかったかを確認し、追加テストを実施します。

ゾーン2、4(テスト密度が高く、バグ密度は低い)

ゾーン分析

ゾーン2、4はテストが十分実施されていそうですが、バグ密度が低いことから、バグがまだ潜んでいる可能性を疑うべきです。見当違いのテストを実施している場合、バグを発見することはできません。テストケースの妥当性や網羅性に問題がないか確認しましょう。

もし、テストの実施内容に問題なければ、そのソフトウェアの品質は良いと言えます(開発内容の難易度が高いためテストケース数は多かったが、バグはあまり出なかった)。

テストケースに問題がある場合は、いくらテストを実施してもバグが検出されません。なかには、テスト密度の目標値を達成するためにテストケースを無理やり増やすといった事例もあるようですが、それではソフトウェアの品質は向上しません。
テストの網羅性をチェックし、必要であれば追加テストを実施しましょう。

ゾーン分析を現場で活用する

9つのゾーンそれぞれについて解説してきましたが、現場で活用するには各指標値の分析目的に応じて方法を変えていく必要もあります。
今回は9つのゾーンを均等に分けた図を使用しましたが、開発の規模や難易度によって各エリアの面積を変えることも少なくありません。
また、システム全体ではなく、サブシステムごと、人員ごとにテストケース密度、バグ密度を確認することも有効です。

おわりに

いかがでしたでしょうか。テスト密度とバグ密度をそれぞれ単独でチェックしても、見えてくる情報は少ないですが、同時に分析することで問題点を発見するきっかけになります。ソフトウェアの品質管理においては、定量的データだけでなく、定性的な観点も考慮する必要がありますが、まずは基本的な指標である「テスト密度」と「バグ密度」を正しく活用していきましょう。

資料ダウンロード

  • 状態遷移テストの基本の「き」

    テスト技法「状態遷移テスト」について解説しているミニ冊子です。技法の概要から使い方とポイントについて、初心者にもわかりやすく解説しております。

  • デシジョンテーブルの基本の「き」

    テスト技法「デシジョンテーブル」について解説しているミニ冊子です。技法の概要から使い方とポイントについて、初心者にもわかりやすく解説しております。

  • 境界値分析・同値クラス分割の基本の「き」

    テスト技法「境界値分析」と「同値クラス分割」について解説しているミニ冊子です。技法の概要から使い方とポイントなど、初心者にもわかりやすく解説しております。

Qbook+編集部
ライター:
Qbook+編集部

バルテス株式会社 Qbook+編集部。 ソフトウェアテストや品質向上に関する記事を執筆しています。

関連記事