テスト・・・それはシステムのリリースに辺り最後に立ちはだかる壁・・・
いや番人と言ったほうが良いかもしれませんかね。
ただ番人も様々
あくびばっかりしていてろくに番をこなせないものもいれば、怖い顔で仁王立ちという番人も。
長期のプロジェクトになればなるほど、このテストというのは楽に終了したいと思うエンジニアは多いと思いますが、プロジェクトを管理する立場の人から言えばここは最後の砦とし、そうやすやすと通すわけにはいかないよと構えて考えるものでしょう。
（責任を問われるのはその人たちなわけですから）
ただ、このテストというのはかなり面倒なものであり、敬遠する人も多い工程。
そもそもテストと一言で言ってもその幅はかなり広いものです。
システム面でいえば、プログラムの単体レベルから結合レベルに応じて。
システム面と一言で言ってもこれは何もプログラムだけという話ではなく、インフラ部分や負荷、セキュリティ、パフォーマンスなど多岐にわたります。
また、運用面でのテストも必要になります。
そのシステムを運用する上で、設計した運用業務が正しく行えるかの運用テスト。
そのシステムを利用者が操作する上で問題ないか確認する業務（ユーザー）テストなど。
ただこれほどボリュームがあるにもかかわらず、それに割り当てられる体制は少数（または実質存在しない）だったり、工数がほとんど取られてなかったり・・・。
理想としては、構築したチームとテストチームを分けて行う事なんでしょうが、それが一緒くたにされていたり・・・。
別にあくびをして暇そうにしている番人を割り当てたわけではないのに、リリースしてみるとバグの嵐なんて事が周りでも良く起きています。
これは、そのテストという関所に番人を割り当てても、あまりの通行量の多さ（ ＝ システムの規模）に万人が処理しきれない（または見過ごしてしまう）という事が原因だと思います。
もう一つ、原因を付け加えると開発とテストという工程を一緒のものだと考えている人が多い点ではないでしょうか。
開発をする、といことはそれがちゃんと出来上がったかどうか確認しているはず。
これがテストになっている。一つずつ確認して出来上がったんだから全体としてもテストが出来上がっている。
一つずつのプログラムが完璧であれば、この考え方は正しいと思います。
完璧というのは、全ての設計が完璧になっており、個々の役割が完璧に分類されており個々のエンジニアがそれを完璧に実装する。
はっきり言ってこの時点で無理な話です。
だって完璧なんてこの世の中にありえないわけですから・・・。
一般的なテストのやり方などについては下記参照