単体テストの意義とは？

主に、プログラムの受託開発や常駐での開発作業に関する話題です。ソフト開発の仕事では、プログラムだけ作って納品しておしまい、という仕事は非常に希で、多くの場合、ドキュメントも納品することになります。ドキュメントは、

・基本設計
・詳細設計
・画面設計
・DB設計
・プロトコル設計

などの設計書の他に、テスト成績書が要求されます。テストは一般的に、

・単体テスト
・結合テスト
・総合テスト

の3段階と考えられています。この中で、私が毎回疑問に感じているのが、「単体テストのテスト仕様書・成績書」の必要性です。

単体テストは、いわゆるホワイトボックステストで、ソースコードを網羅するような確認が対象です。私が何を疑問と感じているかというと、「ソースコードを網羅するようなテスト仕様書を作成するのは、ソースコードを書くこと以上に手間がかかる」ということです。

できるプログラマーは、ソースコードを少し書いたらすぐにコンパイルして動きを確認するものです。なぜなら、書いた直後が一番頭の中に「どう動くべきか」が明確になっているからです。何千行ものソースコードを書いて、後からソースコードを網羅するような確認など、現実的に無理です。

しかも、条件分岐や関数を書いた際に、その確認をするためには、場合によっては確認用のテストプログラムを別に作って確認したり、あるいは与えるデータを無理矢理ソース上で加工してテストをしたりするものです。それをいちいちドキュメントにしていたのでは、コーディングの効率が呆れるほど低下してしまうのみならず、「ドキュメントを書く」という作業に頭や思考を奪われてしまい、肝心のコーディングの質が下がってしまいます。

私は、テスト仕様書が必要なのは、少なくとも結合テスト以降で、別々に開発を進めたもの同士を結合してみたり、要件に合う動きをするかどうかの確認を行うために、要件からテスト項目を作成して、一通り動きを確認するためにテスト仕様書が役立つ、という感じだと考えています。

それでは、なぜ単体テスト仕様書・成績書を要求されるのでしょうか。私の予想では、問題が起きたときに、問題箇所の確認をしていたかどうかを、成績書から検索し、合格していたのに問題が出たのであれば、そもそもテスト自体を疑う根拠とし、あるいは、テスト自体の対象になっていなければ、網羅度が低いと責任追及したいからでしょう。納品物が分厚ければ、払った費用に対してボリュームがあると満足できる、ということもあるかもしれません。

プログラムの開発には多少なりとも試行錯誤があるものです。仕様が変更になることもありますし、開発側の都合で作りかえることもあるでしょう。基本的に、進めながらよりよい方向にするために、試行錯誤や変更が入るものです。ところが、ドキュメント要求が厳しすぎると、プログラムの修正の数倍、ドキュメントの修正に手間がかかりますから、ドキュメントを修正するくらいなら止めよう、という考えになってしまうことも多いものです。そんなことになるくらいなら、ドキュメントなど、開発が落ち着いた後に、ソースコードを元に書き起こせば良いのではないかと思います。テスト関連のドキュメントも、分厚さを要求するよりも、むしろ、本当に自信を持ってリリースしてくれと依頼した方が、本当に動作確認するための時間がたっぷり作り出せるものです。

実際に、私も受託開発を中心に仕事をしていた時期がありますので、自分で良くわかっているのですが、あまりにもドキュメント要求が多すぎると、はっきり言ってドキュメントを書く時間だけでいっぱいいっぱいになり、本当に丁寧に動作確認を行ったり、ソースを整理したりすることなど、時間が足りなくてできなくなります。最初からドキュメントを見込んだ工数を認めてもらえることなどまずなく、可能な限り値切ることしか考えない調達経由の交渉などから、ただでさえ余裕がないのに、ますます品質を上げるための時間が取れなくなるのです。

幸いなことに、私は多くの依頼者側の方々と本音でコミュニケーションをさせていただけましたので、ほとんどの仕事で、「ドキュメントよりもプログラムの質を！」という感じの仕事をしてくることができました。もちろん、最初からそのような信頼関係は築けません。本当に品質が高いことや、開発速度、高性能で安定性の高いプログラムを作ることができるということを実感していただいてからになります。

この問題は、依頼者側の意識の問題ということだけではないのです。開発側のレベルの低さゆえに、せめてドキュメント要求を厳しくして、やることをやった記録を残させようという考えも背景にあるものなのです。双方の信頼関係が崩れてしまっているからこそ、「証拠を残せ！」ということになってしまっているわけです。

受ける側からみた依頼者の理想は、「多少の問題はなんとか収拾するから、その代わりしっかりレベルの高い開発をしてくれ」という感じでしょうし、依頼する側からみた開発側の理想は、「要求以上のレベルのものを、予定より前倒しで仕上げるから、安心して任せてくれ」という感じでしょう。そういう信頼関係をベースとした開発は、多くの場合、まず問題など起きずに、スイスイと進んで、さらに発展的な話しで盛り上がるようなプロジェクトになるものです。人がやっていることですから、ミスはあるものです。仕様漏れもあるでしょうし、プログラムのミスもあるでしょう。いちいち揚げ足を取って、にらみ合っているよりも、どう進めるのがベストなのかを相談しながら解決していけるような仕事をしたいものです。

私自身は・・・こんな内容を書くことができるくらい、すばらしい依頼者の方々とお付き合いできていますし、それに応えてきたという自信があり、このやりがいのある仕事が楽しくて仕方ないのです。