テストの本質を探る　――30年の歴史を持つ 「ソフトウェア工学」の知恵に学ぶ

　「テスト」というのは，自分が不安だから試しに手元でちょっと動かしてみるもの．あるいは，「どうしてこんなまちがいをしたんだ！」としかられて，しぶしぶやるもの．そんなふうに思っている技術者が多いかもしれません．まじめなあなただったら，どこまでやれば許してもらえるのかを考えて，頭を抱えるかもしれません（図1）．

　それもしかたのないことだと思います．本屋に行くと，「作る」ための書籍は多数あります．しかし，そこに「テスト」のコーナを見たことがあるでしょうか．たぶん，何かがおかしいのです．

　テストもまた，「作る」作業の一部です．実装まで迅速に進んだとしても，そのあとのテストの工程に時間がかかってしまっては意味がありません．テストが順調に進まない場合，終了が見えないだけ，たちが悪いともいえます．

　良い設計（ソフトウェア，HDL記述，回路など）は，一般にテストも容易です．逆を考えます．例えば奇々怪々な構成のソース・コードがあったとき，パス・テスト（プログラムの制御フローに基づいてテスト・ケースを定める方法．詳しくは後述）のための入力ベクトルを見つけることができるでしょうか．仕様書が不十分な状態で，システムをテストするためのテスト・ケースを第三者が見つけることができるでしょうか．仕様書を書いた本人でさえ，見つけられないかもしれません．

　ここでは，主にソフトウェアの世界を例に，「テスト」と呼ばれているものを整理してみました（コラム「ソフトウェア・テストの歴史」を参照）．ソフトウェアの世界を例に説明していますが，HDL（hardware description language）設計や回路設計，システム設計などにも応用のきく議論だと思います．これまでどのようなことが議論され，どういう手段があって，どこに問題があったのかをできるだけわかりやすく書きました．ダメになりつつあるプロジェクトに放り込まれ，ぼう然としそうになったとき，テストについてどのように考えるべきかなどのヒントになれば幸いです．

〔図1〕テスト担当者の苦悩