テスト技法でテスト設計をしたとき

イロイロ調べて今更ながらわかったのだが、ソフトウェアテストでのデシジョンテーブルっていうのは、効率的なテストケースを抽出するのに使うというイメージだったけれど、実は複雑な仕様なんかをわかりやすく表現するのが本来の機能なんだ。たぶん。

==

下流工程のテスト(動的テスト)をするにあたっては、

より多くの欠陥を見つける

より少ないテストケースで実施

網羅性を確保する

という目的でいろいろなテスト技法・ツールを扱う。開発者が単体テストなどで無意識的に実施している同値分割や境界値分析、エラー推測。あるいは体系的なテスト技法としては原因結果グラフ、デシジョンテーブル、CFD、直交表、、HAYST法、All-pair法、etc。で、毎回思うのだが、特に後半の体系的な技法を使った場合、どうやってレビューするのが最適なんだろうか。テスト技法に詳しい人がいればその人に見てもらうことは可能だが、たいていそんな人は少ない。「このテストケースがなぜ必要か？」についてはまだ何とかなるにしても「なんでこのテストケースだけで十分なの？」とか「このテストケースはやらないの？」とかってプレゼンテーションが難しいなあ、って思った。

うまく説明できる技術はまだ僕にはあまりないかも。