6. テストを作る際の留意点

6.1. 障害密度とは

「人間は、一定の作業量において、同じような頻度で障害を作り込む」という仮説を前提とし、作業内容(工程)、開発言語、開発スタイルにより、開発規模と発生した障害数を集計した結果、およその目安として、単位開発規模に潜在障害数を、品質指標における「障害密度」としています。 前述の仮定が正しいとすれば、開発した規模よりも、障害数が指標とかい離している場合には、かい離の理由を説明するために詳細な分析が必要になります。

6.2. テスト密度とは

テスト密度は、集計したプロジェクトの、作業内容(工程)、開発言語、開発スタイルに応じて、開発規模と作り込んだテスト項目数を平均化したものです。これは単なる項目数の平均値であり、直接的に品質に影響を与えるものではありません。指標のテスト密度を満たしていることが、品質の保証に結びつくわけではないのです。いうなれば、「世間並みに頑張ってテストしたかどうか」という指標に過ぎないのです。

従って、TestSuiteやTestCaseの単位について、あまり悩む必要はないと考えます。プロジェクトの内部で通用するテスト規模の目標値のようなものです。

6.3. テストのポイント

効率よく障害を検出するためのポイントがあります。「プロジェクトの難易度が一定ならば障害密度が一定である」という仮定を置けば、障害数に一定の上限があるという帰結が得られます。障害数に上限があるならば、障害が発生しそうなテストパターンを抽出すれば、必要なテスト数が最小になるはずです。 つまり、バリエーションをよくよく考えてテストを設計することが、効率的に品質を高めるポイントになります。

実際に、テストの内容を吟味せずに項目数だけ増やすようなケースでは、コストがかかるだけで、品質に寄与しないことが多いものです。それだけではなく、実際の品質以上に良好な品質に見えたりするので、かえって、品質評価を誤りかねないリスクが増大するでしょう。一方、指標のテスト密度よりもはるかに少ないテスト密度でも、バリエーションを適切の選択したテストを行えば、より少ないコストで、指標のテスト密度をはるかに下回る場合においてさえも、潜在障害を十分に顕在化させることが可能になります。

よくよく考えて、バリエーションを作りましょう。