テスト自動化ツールと工数

テストの自動化について、JUnitのようなツールというか、フレームワークがあるわけだが、
実際の運用についてはあまり論議されることが少ないように思える。
たとえば、確かに単体テストを自動化することで仕様変更や仕様の追加などにおける
影響の度合いを調べたりできるようになったのだが、
実際問題なのは「本当に正しいテストケースなのか？」「テストケースに不備や不足がないか？」
といったところで、このあたりの一部はJCoverageなどのカバレッジチェックツールと
併用することで埋められるものもあるが、そうでもない場合も存在する。
そうなると結局テストケースの確認は第３者に目で確認してもらうことになるのだが、
そのために結果書類を丁寧に作成するのでは何のための自動化かわからない部分もある。
このあたりの「テスト項目書」や「テスト結果」について、
「紙ベース」での成果物として納品することがまだまだ多いため、
（JavaDocのテスト項目書では成果物として不可な場合や、文書をExcelなどで求められる場合）
こういう文書も作成を楽にする仕組みや運用を考えないといけない。
要は、
・テストの項目やテスト結果が正しいか。
・テストを行った場合に与えたパラメータやＤＢ値がテストに対して適切な値か。
がソースを読まずに判断できればいいわけだが、
そういうものの標準化はあまり進んでないように思える。
JavaDocでもDocletを使った方法ならPDFやWord、Excelを作成することも可能だが、
その現場でのDocletをいちいち作成したのでは割にあわない。
根本的な考え方の変更か、仕組みを作成することが必要なのではないかと思う。
もっとも、今年（だったと思うが…）から文書の保存についても電子文書での保存が
正式に認められるようで、こういう「印刷」作業がだんだんと少なくなるのか、
それとも変わらないのかは興味深いところである。

今日買った漫画：20世紀少年(18)、彼氏彼女の事情(20)、医龍(8)、ベルセルク(28)、EDEN(12)
なんかいっぱいでてた。