背景

にしさんの以下のツイートをきっかけに、「規模あたりのテストケース数」というメトリクスについて考えてみた。
https://mobile.twitter.com/YasuharuNishi/status/1203344174864453634

規模あたりのテストケース数はもはや意味をなさないという意見に賛成する人は、その理由を最低2つと、じゃあ何をするかを答えられるようにしておくこと。ここ試験に出すからな。
— Yasuharu NISHI (@YasuharuNishi) December 7, 2019

(注意)
規模はソースコードの規模であることを前提とする。
"もはや"ではなく、"以前から"意味をなさない理由とした。

問いに対する考え

前提：しっかりテスト設計をしている
- テスト観点ツリーを作成し、テスト観点の不足がないか検証している
- デシジョンテーブルを作成し、テストケースに不足がないか検証している
- 状態遷移表を作成し、テストケースに不足がないか検証している
- 同値分割と境界値分析の方針を決め、方針に従ってテストケースが抽出されているかを検証している
「規模あたりのテストケース数」が過去の案件と比べて少ないと判断されたとしても、具体的にどのようなテストケースが不足しているか不明。「規模あたりのテストケース数」のデータだけでは、どのようなテストケースを追加すればよいか判断できない。
同じようなテストケースを無駄に追加し、「規模あたりのテストケース数」が過去の案件と比べて同等にすることができてしまう。
人は、認知バイアスにより、データの傾向が把握しにくいと、自分の都合のよいほうにデータ分析してしまいがちである。
- 感情バイアス：好ましくない，精神的苦痛を与えるような厳しい事実を受け入れたがらない人の特性
- 正常性バイアス：自分にとって都合の悪い情報を無視したり，過小評価したりしてしまう人の特性

前提：派生開発
- 変更箇所とその影響箇所に対するテストをする
- ソースコードを変更してない影響箇所に対するテストも実施する
影響箇所も含めた規模を算出することが難しい
変更していないところ、つまり変更規模0のところで、変更漏れというバグが発生していることもある。規模0の場合、1件でもテストを実施していれば、規模あたりのテストケース数が∞となってしまう。

※オープンソースを使う、ライブラリを使う、再利用資産を使うなど、自分でソースコードを作成せず、大きな価値を生み出す開発では、規模の計測の仕方が更に難しくなるはず。

単純にテストが不足しているという情報ではなく、ソースコードのどの箇所に対するテストが不足しているかの情報があれば、テストケースを追加するアクションが起こしやすい。

影響波及パス分析法によりテストケースの不足箇所を特定し、テストケースの追加要否判断をする

Difference Statement Covarage分析法によりテストケースの不足箇所を特定し、テストケースの追加要否判断をする

規模あたりのテストケース数は、単体テストでのみ活用する
関数単体テストで、テスト設計のルールに従っているかを確認するために、活用する。
関数毎に、規模あたりのテストケース数を算出する。
規模あたりのテストケース数が、基準値を大幅に上回る/下回る関数を特定し、テスト設計のルールに従っているか確認する。
実開発で適用してみた結果、無駄にテストケースを増やしていた関数を特定することができた。ただし、テストケースの不足は、レビューをしていたこともあり、検出できなかった。
全体を集計したデータではなく、小さい単位でたくさんのデータを収集すれば、傾向が分析しやすい。異常がある箇所を特定しやすい。

ゴールに繋がるアクションを生み出すデータ分析活動の事例
http://www.jaspic.org/event/2019/SPIJapan/session3C/3C3_ID019.pdf

データ指向のソフトウェア品質マネジメント
https://www.juse-p.co.jp/products/view/442