テスト

この間、Developers Test Summitというサミットが開催された。以前発表したDevelpoers SUmmitのテスト版ってカンジの内容。私は仕事の関係上参加できなかったんだけど、最後のディスカッションのレポートがここに書いてあった。
テストって確かに難しいよねぇ。うちのプロジェクトではJUnitを使用してテストを実施してはいるものの、その結果としてどの程度品質が上がったかの評価は正直できていない。DB周りのテストは結構網羅できているので安心感はあるといえばあるがメンテナンスコストが大きいのも確か。「自動テストがあるからリファクタリングも安心だぜっ」ってことも多々ある。だけど、テスト対象のモジュールのインターフェースが完全に確定している場合はいいけど、インターフェースを修正せざる終えないような時はテストケース自体も修正が入るわけで…（あ、でもこれはインターフェースを変えちゃうのが本当の問題かも。クラスを公開している時点でそのクラスをすでに使用してる人のために互換性を確保する必要があるからね。でもそんなことしてたら一向にソースがきれいにならない気もするし…）。
プラスして今はユーザインターフェースまわりのテストの自動化はほとんどできていない。もしここも完璧に自動化ができれば、毎日でもリリースを実行できるし、勇気をもってソースを改変することもできるんだけど、実際はユーザインターフェースは変更される可能性が高く、どこまで自動化すべきかがわからない（技術的にも難しいってのが理由でもあるんだけど）。結果、最終的に手作業のテストが発生していて、それがリリースまでの流れを鈍くしているのはわかってるんだけど…ね。手で行うテストが完全になくなり、「自動テストが成功すればすべての品質を保障できてます」と言える状態になればいいんだけど、現実問題としてコストを考慮すると今のところ難しい。
ただ、作業=Taskの完了条件としてテスト自体が存在しないと、「何を持って作業が完了したのか」があいまいになってしまう。結果として時間に追われることもあいまって、品質を途中で作りこむことをせずに（正確にいうと人によって品質の考え方やこだわりにバラツキがでちゃう）作業を進め、後工程で障害が発生してしまったりする。
うーん、難しいね、テストは。理想論はいくらでも言えるんだけど、やっぱり必要なのは現実解なわけで…。テストに関して少しでも今よりも進んだ理想的な状況に近づくように、カイゼンしつづけないとね。部分最適化ではなく全体最適化。テスト(=品質）だけにとらわれることなく、全体を見ながら検討していきたい。