テスト再整理(テストについて5)

テストをする、という事は対象の品質を計測するという事な訳なのですが。。。

その際に一番信頼を置けるのは、やはりUnitTestをする為のテストコードなんだと思っています。

テストコードは24時間ぶっ通しで実行させても疲れないし、壊れない。繰り返し繰り返しテストをやらせても疲れないので勘違いも物忘れもしない。コンピュータが実行するので、動きが遅くて不確かな人間より手早く確実。

でも、テストコードを作るのは人間。

ここに微妙なジレンマがあります。

また、テストコードを書いてUnitTestをがんばっても、それが正しくUIや業務ロジックの挙動に結び付くものなのかどうか、という点は不安定で不確かな人間が確認しないといけません。

レビューという手段もありますが、現場によっては政治的にきちんと指摘出来ないケースもあったり、あとにならないと気付かないものがあったり、JUnitの#assertEqualsのような結果に対して一刀両断の判断を下してくれるようなモノが無いところで、ソフトウェア／アプリケーションの品質のほとんどが決まってしまうんですよね。

そういう意味では、プロジェクト・チームから属人性を撤廃しようとしても結局難しいのかも知れません。

テストが得意な人もいれば、テストが苦手な人もいます。

という訳で、プロジェクト・チーム内にどれだけ多くの「視点」「切り口」を持てて、それを活かしてどれだけ検査の目を細かくするか、そして検査対象となるドキュメント(設計書とか仕様書)にどれだけ「挙動」を適切に表現できるか、という点が問題なのじゃないかな、と。

で、書かれた「挙動」から何かしらの定型パターンを使ってモジュールに落し込んでいく、と。

あとは、定型パターンの周知を徹底すれば、あるいはプロジェクト・チームのメンバーに「考えなくても良い事」というものをプレゼントできるかも知れません。