リリース判定基準・テストの量はテスト密度で測る
リリース判定でのテスト品質ではまずはテストの量の十分性を見る
ソフトのリリース判定を行う時に使う４つの判定基準（テストの品質、残存バグ、プロダクト品質、プロセス品質）のうち、この記事ではテスト品質の良し悪しを判定す方法について紹介します。グータラ親父はテストの品質をテストの量と個々のテストの種類とテストの実施状況とバグの状況の４つの視点から見ていました。この記事に続くいくつかの記事では、テストの品質の判定の考え方について紹介していきましょう。まず最初は比較的考えやすいテストの量から見ていきます。
テストの品質をテストの量という面から見た場合には単純に、テスト量が多いほうが良いと解答は簡単です。テストしなけりゃバグはゼロですし、少量のテストと多量のテストとでは多量のテストのほうがバグを多く見つけられるのは誰が考えても明らかですね。ではテストはどの程度の量を実施すれば十分なのでしょうか？ この判断はなかなか悩ましいですね。この記事では、テストの量が充分なのか不足しているのか、リリース判定をする時にどんな情報を元にどんな視点で判断するのが良いのか、グータラ親父の使ってきた考え方を紹介していきます。
テストの量を判断する基本はソースコードに対するテスト密度
テストの量を考える時には、テスト項目数（XX件）という絶対数ではなくテスト密度（XX件/KLOC)というソースコードの規模で正規化したテスト密度で考える事が必要です。例えば 100項目のテストは、100行のソースコードに対しては十分な量ですが100,000 行のソースコードに対しては不足です。ソースコードの規模で正規化したテスト密度でないと、テスト量が十分かどうかの判断はできません。
全てのソースコードが新規開発ならば、単純に XX件/KLOC というテスト密度の目標値を決めて、必要なテストの規模を決めてしまえば良いです。 目標値の決め方は、IPAによる組み込みソフトウエア開発向け品質作り込みガイド等にも載っていますので、これを参考にするのも良いですね。 ただし、テスト密度の値は、何を１件のテストと数えるかというテスト項目の粒度によって変わるので、自社向けに読み替える必要はあります。
改造開発では新規・修正以外のコードも少しは評価に反映する
ところで、ゼロから全てのソースコードを開発する事はソフトウエアが大規模化した最近のソフトウエア開発の現場では、実は稀な場面です。 一番多いのは既にあるソフトウエアに対して改造を加える改造開発（派生開発とも呼びますね）です。 改造開発では改造元になるソースコード（ベースラインコードと呼ぶことも有ります）を持ってきて、そこに必要な機能をつけ足したり、不要な機能を削除したり、という足し算引き算の開発をしてソフトウエアを作ります。
そのような場合、新規に追加したソースコードや修正したソースコードの箇所に関連するテストをするだけで良いかというと、そういう訳には行きません。 相互に依存関係のあるソフトウエアでは、機能の追加/削除による影響で、削除/修正していないソースコードに潜在していたバグが顕在化する事もよくあります。 かといって、全てのベースラインコードに対して、新規開発部分と全く同じテスト密度でテストを実行しようとすると、かなりのテスト費用が掛かるので、なかなか悩ましいです。
テスト量は新規コードと既存コードに分けて考える
結果として、新規に作ったソースコードや修正したソースコードに関係する機能に関しては充分なテストを実施して、今回の開発では触っていない箇所のソースコードで実装されている機能については、テスト密度を少し下げる、という必要なテスト密度の調整というかテストの簡略化が必要になります。 この場合には、必要なテストの総量（＝テストの項目数）は大雑把に言うと以下のような計算で決まる事になります。
①テストの総量＝②新規や修正したモジュールのテスト量＋③未修整モジュールのテスト量
②新規/改造モジュールのテスト量＝
新規/改造モジュールのソースコード数（KLOC)Ｘ （α）新規/修正箇所のテスト密度（件/KLOC)
③未修整モジュールのテスト量＝
未修整モジュールのソースコード数（KLOC)Ｘ （β）未修整箇所のテスト密度(件/KLOC)
まず、（α）新規/修正箇所のテスト密度（件/KLOC)を、組み込みソフトウエア開発向け品質作り込みガイド等を参考にして決めます。この値にある程度エイヤっで決めた０から１までの（γ）調整値を掛け算して、（β）未修整箇所のテスト密度(件/KLOC)エイヤッで決める、というのがよくある決め方ですね。 （β＝α X γ ）
（β）未修正箇所のテスト密度を計算するための（γ）調整値を０から１の間でどの程度にすれば良いのかは、新規/修正したソースコードとそれ以外のソースコードとの依存関係で決まる修正の影響範囲にも関係するので、開発の全体構成が判っている人でないと判断は難しいです。
何かの実績に基づく値ではなく、単なる経験則というか勘でしかありませんが、グータラ親父は依存関係が薄い（個々のモジュールの独立性が高い）ソフトの場合ではこの調整値として 0.1 程度、相互の依存関係が濃い（お互いのモジュールが相互に依存しあっている）場合で 0.3 程度というのをひとつの参考値として使っていました。
しかしまあ、どれだけテストすれば良いかという判断は実は誰にも正解は判らないので、開発の全体構成を一番良く把握している人がエイヤッで決めて、何人かでその内容をレビューして、この値でいいか！ と決定するのが現実的でしょう。できればその時に、色々な製品でのテスト設計の経験がある人が参加して、これまでの製品での実績経験から、適切な値を提示できるのが、一番良いと思います。 ソフトの世界は、まだまだ熟練したエキスパートによる判断が最重要な職人の世界です。
テストの量を確認する時には実際実施したテストの量も確認します
テスト品質の良し悪しを判定する時にはまずテストの量を確認するのですが、ここまでで紹介してきたのは、計画したテストの量という視点です。テストの量を見るときには、計画したテストの量に加えて実際に実施したテストの量も見ると、また別の視点からテスト品質を判定する情報が得られます。
次の記事ではテストのグータラ親父が見ていたテストの実施状況の見方について紹介してきます、興味のある方はご覧ください。