最近テストの抜け漏れをどうやってなくすか実験しています。これ、もっといい感じに取り組めたら、論文とかにしたいんですけど、まだいい塩梅にならないので、まぁブログでもいいかなぁとか思ってやっています。

やっていること

ざっくりと言えば

仕様書とテスト仕様書(テストコード)を形態要素解析して名詞の重複有無や頻出の傾向を比較する。

こうすると、「仕様書にある単語がテスト仕様書に出てきていないけど、テストないの？」とか「仕様書でちょっとしか出てきていない単語が、テスト仕様書にいっぱい出てきているけどそのテスト無駄じゃない？」とか。言えるのかな？って試している感じです。

ところでテストケースは不足しているものが多い

で、まぁ概ね使えないんですけど、もうちょっと工夫すればいい感じになりそうだなぁと思っています。これによって変わったのは、「やらないテストも実装する」ということですね。どんな理由でもいいので、「これはテストしない」というものもテスト仕様書やテストコードに書いておいてやらないっていうタグ付けをしておきます。テストメソッドだとIgnoreでもいいし、標準出力に「これは○○の理由でやらないテスト」とかしておく感じで、自然言語なドキュメントだったらやらないってタグ付けした上で理由を書いておく。

そうすると、なにがテスト抜けしていてなには想定通りなのかっていうのが、比較的テストを見たときにパッとわかる感じです。

組み合わせで存在しないから。。。っていうテストケースを書いていることはあったんだけど、いわゆるハイレベルテストケースとかテストスイートの単位、CucumberとかxUnitだとFeatureとかScenarioとかテストクラスとかテストメソッドの単位で、「やらないテストはこれです」って書いておくようになりました。

でもこれ、あんまりオススメできないですね。僕がいま抱えている課題に「範囲外の記述」というのがあって、よいテストはだいたい範囲外をうまく書いているんだよなーっていうのがありまして。でも、それも不完全でして、形式手法やらざるを得ない部分もあるし、そもそも想定していないものについて想定するという（ry　　って感じなので、際限ないんですけど、まぁこの方法は僕に限って言えばいまはうまくコントロールできていて、品質があがりつつあるなーと思っています。

話は戻って抜け漏れの定量化

で、なんでこの話になったかというと、「やらないと決めたテスト」と「考慮漏れだったテスト」が先の定量化のときにこれでハッキリするというメリットもあります。仕様書にあるけど、テスト仕様書にない単語がいくつかあったとして、それはテスト設計者やPOが「これはやらないテスト」としたのか「全然考えていなかったのか」とはまた別なわけですね。人間が判断するにしても機械が判断するにしてもそれなりの情報必要だしなぁと思いました。

ということで、なにもまとめとかないし、この取り組み自体は大した問題を見つけられない事はわかっているんですけど、なんか簡単にフリーライド出来るようなツールになったらうれしいなぁっていう程度の意味でごにょごにょやっています。なんか静的解析ツールみたいな感じでなんとなく見るにはいいかもー程度の。（組み合わせテストが抜けているとか状態遷移が抜けているとかは簡単には出来なさそうだったので、まず出来そうなものを試してる感じです）

なにかいいツールとか書籍とか論文とかあったら教えてくださるとうれしいです。