テスト設計自動化の補足
ギア本第1章では、テスト設計自動化についてはまだ過渡期の技術であるとして簡単な紹介に終わっています。ギア本が刊行されて15年。その間にテスト設計自動化は次のような進化を遂げています。
ソースコードベースのテスト設計自動化
「プログラムを静的解析し、if文などの分岐点を探し出し、分岐の全パスを網羅する」ようなテストデータを自ら生成してテストを実行するツールは、特に商用ツールを中心に発展してきました（Jtest, LDRAなど）。最近では「Concolic Testing」というテストケース生成技術が注目を浴びています。
Concolic Testingとは、一部具体値を入れることで静的解析で解きづらい問題を解きやすし、網羅的なテストケース自動生成を容易にする技術です。詳しくは、テスト自動化研究会のコミッターでギア本の翻訳にも参加された井芹洋輝さんのSIG資料「Concolic Testingの用途紹介【回帰テストの場合】」をご覧ください。
仕様ベースのテスト設計自動化
最近では、仕様からテストケースを生成するツールがいろいろと出てきました。中にはOSSのツールもあります。このタイプのツールで基本になっているのは「仕様をなんらかのモデルとして表現し、そこからテストケースを自動生成する」いう考え方です。これをモデルベースドテスト（MBT：Model Based Testing）といいます。
筆者が公の場で最初にモデルベースドテストについて聞いたのは、2007年に東京で開催されたソフトウェアテストシンポジウム（JaSST Tokyo）でした（モデルベースドテストに関する発表資料）。
当時のモデルベースドテストは、開発で作成したモデルからテストケースを生成することを目指していました。そのため、モデルを記述する言語U2TP（UML2 Testing Profile）は、かなりややこしいメタモデルになっています。これを見た筆者は、技術的ハードルが高すぎると感じ、敬遠してしまいました。事実、この方向ではIBM Rhapsodyなど主に組み込み系の一部の商用ツールという形に結実したものもありますが、一般に普及するにはほど遠いと感じています。
こうしたフルセットのやり方に対して、一部の関心事をモデリングし、そこから必要なテストケースだけを生成するやり方が出てきました。このやり方については、テスト自動化研究会のコミッターでもある朱峰錦司さんが、「モデルベースドテスト入門」というスライドにまとめてくださっています。
このスライドからは、フルセットのMBTでなくても現場に導入可能であることが見えてきます。つまり、何を目的にして何を見るか、それに必要な技術とツールは何かという技術選択の王道をやっていけばよいのです。それに必要なツールも、商用・OSSともにそろってきています。
