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

「プログラマが知るべき97のこと」の79個目のエピソードは、テストに関する話です。きのこ本には97+10本のエピソードが収められていますが、id:t-wadaさんがTDDBC札幌でも話されていたようになんらかの形でテストに言及したエピソードはかなりの割合を占めています。それだけテストというものがプログラマにとって重要なことであると言えます。
ソフトウェア開発には、ユニットテストから品質保証（ＱＡ）レベルのテストまで様々な目的のテストがあります。このエピソードでは、ソフトウェア開発におけるテストがいかに重要であるかを、非常に説得力のある形で記述されています。ちなみに、ユニットテストの目的が品質保証であるというのは語弊がありますが、結果として品質保証も担保すると考えればユニットテストも含む全テストが対象と言えます。そして、このエピソードはきのこ本の中でも最も重要なエピソードの１つです。
このエピソードでは、ソフトウェア開発が建築に例えられる事を逆手に取ってテストの重要性を説いています。建築の世界では作った後に、その建築物をテストすることは基本的にできません。一方で、長年の経験とノウハウから、理論的に、どのように設計すれば良いかという知識が蓄積されています。また、これまでにないものものを建築するとしても、基本的には既存の建築物の延長上にある事がほとんどです。
ソフトウェア開発に関しては歴史も浅く、どのように作れば良いかというノウハウの蓄積は少ないと言えます。一部の設計ノウハウについては、デザインパターンという形で表現されていますが、抽象度が高く概念レベルを超えることは出来ていません。技術も日進月歩で進化している為、去年は有効だった設計パターンは既に陳腐化している事もあります。さらに作るソフトウェアに関しては、同じようなものはあるものの、基本的に全てオーダーメイドで要件は全く異なります。これらの事実は、少なくとも我々が生きている時代では変わらないでしょう。しかし、ソフトウェア開発では、建築物に対して「とりあえず作ってみる」というコストが圧倒的に小さくなります。建築物では作った後に問題を修正することは、困難もしくは非常に大きなコストがかかりますが、ソフトウェア開発では低いコストで可能です。これがソフトウェア開発と建築の一番の違いなのです。
建築でもソフトウェアでも、作り手は要件を満たすものを作り、そのものが要件を満たすことを保証する責任があります。しかし、この保証をする手段は建築とソフトウェア開発では全く異なります。建築では「作る前に徹底的に検証して設計し、完成したものは正しいもの」という方針で建築物が要件を満たすことを保証します。ソフトウェアでは「作られたものが正しいかどうかをテストで検証する」という方針で要件を満たすことを保証します*1。ソフトウェアは設計時点で十分な検証ができないため、とりあえずは作ってみるというアプローチが非常に有効です。品質や要件の担保はテストで行うのです。つまり、ソフトウェア開発でテストを行わないと言うことは、「構造設計をせずに橋を建てるようなもの」なのです。
この考え方はステークホルダやプロジェクトマネージャにも通用すると思います。ごく自然に「納期が近いからテストは省略しよう」とか「工数が足りないのでテストを削ろう」とかという話になりますが、これは責任を放棄している事と同じです。責任を持たないならばプロではありません。勿論、それは理想論であり、現時的には実践していくのは難しいでしょう。ですが、「テストのないソフトウェア開発はあり得ない」とプログラマが意識を変え、諦めないようにしていけば、ソフトウェア開発業界も変わっていくと思います。

ソフトウェアを開発する者にとって、テストをするということは、作るものに責任を持つということなのです。テストをしさえすればそれで十分ということはないですが、まずテストをしないことには話になりません。テストはソフトウェア開発の中で特に難しく、そして重要な部分と言っていいでしょう。

自分の中で近年の勉強のテーマは「テスト」です。最近はユニットテスト関連は随分と経験や知識を得てきました。最近はシステムテストやQAテスト、テストと設計のトレーサビリティなど色々と調べていますが、まだまだ学ぶ事は多いテーマです。難しいテーマですが、しっかりと向き合っていこうと思います。

プログラマが知るべき97のこと

*1:ごく一部のプロジェクトでは建築と同じような手法で行っている例外的なケースもある