テストのないソフトウェア開発はあり得ない

プログラマには、たとえば配偶者などの家族や友人など、コンピュータに詳しくない人に自分の仕事の難しさ、大変さを話す時、比輸を使う癖があるようです。特にたとえに使われやすいのが、橋の建設などの建築、土木作業です。ただ、この比轍は突き詰めると簡単に破綻します。ソフトウェア開発の作業には、建築、土木作業とは根本的に違っている点がいくつもあるからです。

ソフトウェア開発の世界では、橋の建設にたとえれば、「橋を作ってから重い物を上にのせてみて、耐えられるかどうかを見る」というようなことをしています。重い物に耐えられれば成功ですが、そうでなければ、製図から見直すのです。しかし、実際の橋の建設は、そういう進め方にはなっていません。過去何千年にもわたり、技術者たちが、建築物、構造物に使える数学や物理学を発達させてきたからです。現在では、それを利用することで、実際に作らなくても、どういうものになるか、かなりの程度までわかるようになっています。しかしソフトウェアの世界には、そういうものはありません。多分、永久にできないでしょう。やはり土木、建築とは根本的に違っているからです。ソフトウェア工学と、その他の工学の違いについて深く考察した例としては、1992年にJack ReevesがC++ Journal誌に寄稿した”What is Software Design? (ソフトウェアデザインとは何か)”という記事がよく知られています。もう20年近くも前に書かれた記事ですが、今でも驚くほど真実を言い当てていると思います。Reevesがこの記事で書いているのは、ソフトウェア開発に携わる者が憂欝になってしまうようなことですが、当時と今とで、は違っていることもあります。それはテストを巡る状況です。

橋のように形のあるものを「テスト」するのは容易なことではありません。テストをするには、まず作る必要があります。しかし作るにはコストがかかり、いったん作ったものを壊したり修正したりするのも難しいので、「取りあえずだ、いたいの見当で、作って、テストしてみる」ことはなかなかできません。一方ソフトウェアの場合、とりあえず作る、ということにかかるコストは橋などに比べると圧倒的に安くなります。また、テストを容易に進めるための手法、ツールもこれまでに数多く産み出されています。ユニットテスト、モックオブジェクト、テストハーネスなどはその例です。他の分野の技術者だと、テストをするとすれば、まず実際の物を作って、現実の環境下でテストということになるわけですが、ソフトウェアの技術者の場合は、作りながらテストする、テストしながら作るということをします。テストが、品質保証のための第一の手段なのです(もちろん、他にも品質保証の手段はありますが、テストが重要であることは間違いありません)。土木工事などのように数学、物理学は使えませんが、その代わりにテストをすることで、品質を保証するというわけです。そう考えると、「テストなんでしている時間はない」などと言い放つマネージャは非常に困った存在ということになります。橋の建設をする技術者が、上司から「今回は構造解析しなくていいよ何しろ工期が迫っているからね」などと言われることがあり得るでしょうか。テストは、ソフトウェアの品質、再現性を保証するためにどうしても必要なものなのです。それがわかっていれば「テストなんでしていられない」と言うプログラ マに対し、「それは無責任だ」と反論することができるでしょう。

橋の構造解析に時間がかかるように、テストにもやはり時間がかかります。しかし、どちらも最終的な成果物の質を一定以上に保つためにすることです。ソフトウェアを開発する者にとって、テストをするということは、作るものに責任を持つということなのです。テストをしさえすればそれで十分ということはないですが、まずテストをしないことには話になりません。テストは、ソフトウェア開発の中でも特に難しく、そして重要な部分と言っていいでしょう。