タイトルを見て「何か面白そう」と思ってもらえた方。あるいは「当り前じゃないか」と思われた方、そして、何で上流工程なのに「テスト」なんだ？ と思われた方。ぜひ、少しの間お付き合いいただければ幸いです。

テスト担当者の仕事の中で、実はあまり知られていないことのひとつに「仕様を考えること」があります。あれ？ それは開発者の仕事じゃないの？ もちろんそれはそうなのです。しかし、「⁠完璧な仕様書」などこの世の中には存在しないもの。むしろ「足りない仕様書」が少なくないのが現場の現状です。テスト担当者は、テストを設計する際に、仕様の空白に行き当たって、そもそもこれはどういう仕様であるべきか、それを考えていることがよくあります。

たとえば、同時動作テストにおいて、機能Aが作動しているときに、機能Bを割り込ませると、どのような処理がなされればOKなのか。テストケースを作ろうにも、その「期待値」が仕様書に書いていない。

こんな時、開発者の方に電話をして、どうなっているんですか？ と聞くと「俺にもわからない。テストの結果を書いといて。それが仕様だから」というはなはだ心もとない回答が返ってくることも（もちろん、これは極端な例ですが⁠）⁠。

かくして、テスト担当者の仕事に「期待値」すなわち「あるべき仕様」を考えるという作業が加わることになります。

もっとも、それで問題が発生しなければいいのですが、システムテストの実施段階になって、実装抜けが発見された場合や、未定義の部分がシステムダウンなどのクリティカルな不具合を起こした場合、その手戻りのコストは手痛いものになります。

上流工程において要求定義を行うとき、あるいは基本設計を行うとき、「⁠この仕様をテストするにはどうすればいいか」と考えること。それがこのコラムの提案です。

上流工程において、開発者が意識の中心に置くのは「どうやったら動くものができるのか」ではないでしょうか。それはもちろん、大切なことです。それに対してテスト担当者は「どう動けば合格なのか」を考えます。どちらが大切、というものではなく、どちらも大切です。その両方を、出来る限り上流工程の設計段階から考えておくと、大きなメリットが期待できます（あるいは手戻りのリスクを大きく抑えられます⁠）⁠。

本コラムが提案するのは「テストの視点を設計に取り入れる」という発想の転換です。通常下流工程で使われる「テスト技法」の考え方を、上流工程でも使える便利なものであることを皆さんと一緒に考えていきたいと思います。是非、テストをする方はもちろん、ソフトウェア開発に携わる全ての皆さんに、何らのヒントになれば頂ければ幸いです。

次回は、『⁠境界値・同値クラス』を設計に活用することを、皆さんと一緒に考えていきたいと思います。