システム開発のプロジェクトにおいて、ソフトウェアの品質評価は必須の作業と言えます。その際に使われる指標の一つである「テスト密度」について、「使ってはいるが、使っているだけになっている」「効果が良く分からない」という方もいるのではないでしょうか。これから品質評価を行う方、品質評価に迷いがある方に向けて、「テスト密度」を効果的に活用する手法をご紹介します。
テスト密度とは？
テスト密度とは、システムを新規に開発した場合や、既存のシステムに対して機能追加を行った際に、実行するテストの量が十分であるかを測定・評価するための指標の一つです。必要なテストの量が実施されているか、テストの量に不足がないか、テストを無駄に多く実施していないかを判断する目安となります。
テスト密度の計算式は、次の通りになります。
【テスト密度の計算式】
テスト密度＝テストケース数÷開発規模
このように表され、開発規模あたりのテストケース数を算出します。「テストケース密度」「試験密度」という名称が使用される場合もあります。開発規模は、評価するソフトウェアのプログラムの行数（SLOC：Source Lines Of Code、LOC：Lines Of Code）や機能の規模（FP：Function Point）を使用します。プログラムの行数については、例えば1,000行単位でカウントするKStepsを使用する場合があります。
テスト密度は、テストを実行するより前に目標値として設定し、テストの実行中や実行完了後には目標値と実績値を比較して評価を行います。目標値には幅・範囲を設ける場合が多く、±○○％のように上限・下限の値を設定します。
テスト実行をはじめて行うエンジニア向けのマニュアル型資料
テスト実施の基本とバク報告の書き方を解説
テスト実行者向け はじめてのガイドブック
例としては、次のようなものが挙げられます。
【テスト密度の目標値例】
・作成されたテストケース数：4,500
・開発規模：1,000KSteps
・目標テスト密度4.0
・目標範囲±20％
この場合のケースを考えてみましょう。この場合、テスト密度は、4,500（テストケース数）÷1,000（開発規模）＝ 4.5です。目標値として±20％の範囲を適用すると、
目標値下限 ＝ 4.0×（1－0.2）＝ 3.2
目標値上限 ＝ 4.0×（1＋0.2）＝ 4.8
で、3.2～4.8の範囲となります。このような場合、作成されたテストケース数から算出したテスト密度4.5を、目標値の3.2～4.8と比較すると、目標の範囲内に収まっていると言えます。テストからソフトウェアの品質を評価する指標として代表的なものは、他に「バグ密度（バグ発生率）」があります。テストを実行した結果で検出したバグの件数をもとに評価を行うための指標で、計算式は以下のとおりです。
バグ密度＝バグ検出数÷開発規模
ただし、ソフトウェアの開発においては、テストをただ実施すれば良いというものではありません。また、数値の比較をただ行っていれば良いというものでもありません。テスト担当者や品質分析の担当者は、「テスト密度」「バグ密度」に代表される指標を活用して、テスト期間中やテスト完了後に適切に品質を評価し、その結果によって対応策の要否を判断する必要があります。「テスト密度」と「バグ密度」はどちらも重要な指標ですが、次に「テスト密度」に絞ってご説明していきます。
プロジェクト・プロダクト全体の品質を向上させ、デジタル改革を加速させます
バルテスの品質向上サービスのご紹介
密度による評価が形骸化しているという問題
テスト密度の目標値は、開発マニュアル等で定められた社内の基準値があればそれを適用し、プロジェクトの特性を考慮して決定します。社内の基準値がない場合は、IPA（独立行政法人 情報処理推進機構）が公開している「ソフトウェア開発デー分析データ集に、「テスト工程別のテストケース数と検出バグ数」が掲載されていますので、参考にしてみましょう。
ソフトウェア開発分析データ集： https://www.ipa.go.jp/digital/chousa/metrics/index.html
「ソフトウェア開発分析データ集」で公開されているデータは、「新規開発」「改良開発」「再開発」ごとに分類されているものや、「金融・保険業編」のように業種別のデータもあります。みなさま自身のプロジェクトに適したものを参考にすると良いでしょう。実際のプロジェクトでは、設定した目標値と実績値を比較して分析を行うわけですが、皆さんの開発現場では以下のような事象や感想はないでしょうか？
- 密度や目標値による比較を、開発マニュアルに沿って、ただ実施するだけになっている
- 実績値による密度が目標値の範囲外になっても、何か理由付けをして結局OKにしている
- 設定している目標値が妥当なのかが分からない
例として、各テスト工程の完了時に、テスト密度やバグ密度を使用した定量的な評価と、その評価結果に対する所見を併せて記載して報告するケースを挙げます。
定量的な評価に対する所見には次のようなケースがあります。
- テスト密度が目標値の下限を下回っているが、修正の影響範囲が限定されていたためであり問題ない
- テスト密度は目標値の範囲内であるため、テスト結果は妥当である
- テスト密度が目標値の上限を上回っているが、多数の画面に同じ内容の修正が入ったためであり問題ない
このように、どのような結果であっても何かしら理由を探して「妥当である」と結論付けるだけになっていて、分析の効果を感じられていない状況です。
これは、テスト密度を使用した測定・評価を実施しているものの、その活用が形骸化してしまっているという問題です。背景には何があるのでしょうか？あらかじめ設定した目標値と、対象のソフトウェアの目標値を比較すると、次のような結果が見られます。
- 実績値が目標値の下限を下回る（実績値 ＜ 目標値下限）
- 実績値が目標値の範囲内である（目標値下限 ≦ 実績値 ≦ 目標値上限）
- 実績値が目標値の上限を上回る（目標値上限 ＜ 実績値）
このようないずれかの結果となります。そして、それぞれの結果については、以下のことが言えます。１はテスト密度が低いため、テストが不十分である可能性があります。テストケースに抜けている観点がないか、確認が必要です。２はテストの量は妥当な範囲に収まっていると言えます。３はテスト密度が高いため、必要以上にテストを実施している可能性があります。無駄に実施しているテストケースがないか、確認が必要です。そして、上記のような内容は分かるものの、それが妥当かどうかの判断がつかない場合があります。「何をどこまでテストすれば良いのかが分からない」という状態ですので、注意しましょう。
品質を高め、コストダウンができる効果を9つの事例でご紹介
テストアウトソーシングの効果とコストダウン実例ガイドブック
何をどこまでテストすれば良いのか
テスト密度を算出して、目標値に対する乖離は分かったものの、テストの量が十分かどうか分からない。このような場合は、どうすれば良いのでしょうか。テスト密度は、品質を評価する道具の一つととらえ、様々な視点と併せて評価を行うことが必要です。例えば、同じシステムの過去プロジェクトとの比較や、社内の同種・同規模のプロジェクトとの比較など、相対的に見て妥当と言えるかどうか判断する方法があります。
また、テストケース作成に入る前の段階で、目標値の範囲に対してテスト密度が上回りそうか・範囲内になりそうか・下回りそうか、予測を立てておくことも有用です。この際は、過去のプロジェクトに対する今回のプロジェクトの特性を考慮します。しかし、それでも「何をどこまでテストすれば良いのかが分からない」という壁が立ちはだかります。
これについては、テストの網羅性を可視化して判断を行います。具体的には、システムを俯瞰してテストの抜け漏れがないか、各機能に対して必要なテストケースが設定されているか、を表形式で表して確認します。以下は、テストを実施する機能と観点での例ですが、丸印の代わりに重要度（A・B・C）を付けると、テストケース数が妥当かどうかの判断を行う一助となります。
| 表示確認 | 入力確認 | 動作確認 | |||||||||||
| 画面レイアウト | 文言 | フォーカス | オブジェクト | 文字種 | 文字数 | 未入力 | ＤＢ操作 | メール送信 | 画面遷移 | 排他制御 | ファイル出力 | ||
| 機能1 | 画面1-1 | C | C | C | C | C | C | C | － | － | B | － | － |
| 画面1-2 | C | C | C | C | － | － | － | B | A | C | B | － | |
| 画面1-3 | C | C | － | C | － | － | － | － | － | C | － | C | |
| 機能2 | 画面2-1 | C | C | C | － | B | B | B | A | － | B | A | － |
| ・・・ | |||||||||||||
テスト密度についても、システム全体だけではなく機能ごとやサブシステムごとに算出し、上のようなテストの網羅性と併せて確認すると、十分なテストを行えているかを客観的に判断できるようになります。テスト密度は、その数値による評価と併せて、「何をどこまでテストするのか（したのか）」の確認が必要です。
まとめ
テスト密度とその有効活用について説明してまいりましたが、いかがでしたでしょうか。テスト密度は、品質を評価する道具の一つととらえ、「何をどこまでテストするのか（したのか）」と併せて評価を行うことが必要です。今回はテスト密度に絞ってお話ししましたが、プロジェクトの目的を考慮して適切な「道具」を使いこなして、プロジェクトを成功に導きましょう。
当サイトでは、テスト技法を学びたい方、アジャイル開発やマイグレーションのテスト手法について知りたい方、テストアウトソーシングサービスに興味のある方へ、ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。
