ここでいうテストとは、JavaでいえばJUnitなどの自動化テストの事を指します。
JUnitは多くの現場で採用されるようになりましたが、
それを「有効に」使えている現場はその1割にも満たないのではないでしょうか。
まぁこれは誰もがわかりますよね。
システムのバグを発見し修正することで、品質を保証する為にテストするのです。
ちゃんと動かないシステムは、システムとは呼べないのですから。
ほんの5～6年前（2000年頃）は、テストと言えば手動で行うのが当たり前でした。
「テスト項目表」なるExcelの表が存在し、テスターはそれを実施して
○とか×とか付けていくのです。
このテストのメリットは、簡単なことです。
おそらく、テスト項目表を見れば昨日今日現場に入った人でもテストを実施できます。
しかしこの方法には致命的な欠点があります。
それは「テストは一度やったら終わり」だということです。
プログラムを作って、テストして、バグを修正して、リリース。
これだけならば、確かにテストは一回でOKです。
しかし、実際にはそうではありません。
テストして、バグを修正して、テストして、仕様修正が入り…と
テストを一度やった後にプログラムの改修が入らない事などまずあり得ないのです。
本来なら、プログラムを修正したのならば
その部分のテストをやり直さなければなりません。
これはいわゆる「デグレード」を防ぐために必要で
プログラムの一箇所を修正したときに、それによる影響がどの程度あるかという事は
誰にも予測できないのです。
「修正による影響範囲を調べろ」とか言うナメた指示を受けることはありませんか？
あんなもの、全くの無意味なのです。
どんなに影響範囲を調査したところで、
実際にシステムを動かしてみないと影響範囲は絶対にわからない のです。
あなたに限らず人間の能力は、それを適切に検知できるほど優れてはいません。
ですから厳密に考えれば、プログラムの1箇所でも修正したら
システム全体のテストをやり直さなければならないのです。
これはあまりに無謀な挑戦であり、そんな事を実践している現場はどこにも無いでしょう。
この問題を解決するために考え出されたのが、テストの自動化です。
自動化されたテストはそれ自体がプログラムによって書かれている為
人の手を介さずにテストを実行することが出来ます。
しかし、テストの自動化を実現するにはいくつか乗り越えなければならない壁があるのです。
まず、テストコードを書く能力です。
これは一般的なテスターには務まりません。
よって、プログラマがテストコードを書く必要があるのですが
多くの現場ではそれほどプログラマの供給がありません。
「テストコード書いてる位だったら次の開発を進めてくれ」といった事態になってしまうのです。
このため、テストの自動化は形だけ存在しても
実際には行われていない現場が数多くあります。
ここが、このコラムで一番言いたかった事です。
テストを自動化するのに一番重要なこと、それは
「テストしやすいようにプログラムを作る」という事なのです。
まず、プログラムを組めること。それはプログラマにとって最低限必要な要素です。
その次に、読みやすいプログラムを書くこと。
これこそが、多くのプログラマが乗り越えられない一つの壁なのです。
読みやすいプログラムというのは、ほとんどの場合修正もしやすいのです。
テストしやすいようにプログラムを修正することも簡単でしょう。
Martin Fowler's Bliki (翻訳ページ)で、こんな単語(造語)が紹介されていました。
de-testable。
テストができないソフトウェア。
そんなソフトウェアは、ちゃんと動くはずが無いのです。
多くの現場では、テストを自動化することには興味がありますが
それを「テストに掛かる工数を減らしてくれる」程度にしか考えていません。
これは多くの場合、間違っています。
テストを自動化しても、手動でやっていた頃より工数が減るなんて事はまずありません。
これを聞いて驚きますか？でもそれは事実です。
自動化には、それだけの手間が掛かるのです。
ではなぜ、テストを自動化するのでしょう。
自動化によるメリットが工数削減でないとすれば、何なのでしょうか。
僕が考えるに、それは2つあります。
手動によるテストに比べて、テストを自動化していると
プログラムの修正に伴うバグの数を大幅に減らすことができます。
これはプロジェクト全体の工数を減らす上ではとても重要なのですが
いかんせん表に出てこない要素なので、上を説得するのは難しいかもしれません。
しかし、間違いありません。
テストによる自動化は、バグを未然に防ぐことにあるのです。
テストが自動化されていないシステムは、
新しい機能を入れることを極端に嫌います。
それによってどんな弊害が発生するか予測できないからです。
テストが自動化されたシステムは、積極的に変化を取り入れる事ができます。
これによって、改修に掛かるコストを大幅に減らすことが可能になるでしょう。
つまり、テストを自動化することによって確かに工数は削減できますが
それは明らかに目に見えるような形では現れないのです。
これが、多くの現場でテスト自動化が実施されていない原因です。
では最後に、テストを有効なものにするために欠かせない事を一つ。
それは「テストを継続する」という事です。
先程も話したように、テストの自動化には思いの他コストが掛かります。
その為、一度作ったテストコードを二度と実行しないなんて事が起きてしまうのです。
1ヶ月も経てば、そのテストコードはパスしない(=テストに失敗する)でしょう。
テストコードは常にパスするようにメインコードと同じタイミングで
修正しなければならないのです。
テストを自動化するには、
これだけの労力が必要です。
ほとんどの現場で実行されているのは「テストコードを書く」これだけです。
しかも、そのテストコードはレビューもされておらず
ほとんど意味の無いテストに成り下がっていることが多いのです。
これらの事を実行する事が出来ないと言うのなら、テストの自動化は諦めましょう。
こういった場合、あなたの現場はまだテストを自動化できるほどに成長していないのです。