アジャイルでのテスト

今回のプロジェクトは、僕にとって初めての本格的なアジャイルでの開発です。ぼちぼちと、気がついたことを書いて自分の考えを整理できたらと思って書きます。

まず、テストのこと。

ユニットテストは、当然デベロッパーが各クラス毎に書いています。使っているのはJUnit4,DBUnit, Mock Unit, Mockitoとか。問題は、その一つ上の段階のテスト。インテグレーション・テストと呼んでいたのですが、人に依って定義がまちまち。また、誰がそのテストを開発し実行するのかも意見がまちまち。

作っているジステムは、一種のメッセージ・キューイングを使ったシステムでWEBのユーザーインターフェースはありません。そのため、SELENIUMのような画面ベースのテストツールが使えないかわりに、スクリプティングで自動化できそうでした。

チームのテスターは多少スクリプティングができるとはいえ、デベロッパー:テスター比率が7:1なので、一人でテストスクリプトを全て書くのは無理。デベロッパーだけが、次のイタレーションに移り、テスターが前のイタレーションのテストをしてるという状態を許すと、バグが発見される度にデベロッパーは前のイタレーションに引き戻され経験的にこれはしんどいです。アジャイルの中では、よくクロスフ・ファンクショナルという言葉が出てきますが、イタレーションをテストまで含めて終わらせるためにテストのスクリプトをデベロッパーとテスターが一緒に書くことにしました。

現在は、このテストをストーリー・テストと僕たちは呼んでいます。ストーリー・ブレークダウンを行う時に、そのストーリーのテストも一緒に考えます。ストーリーのカードには、どうやってストーリーがデモできるかも書いてます。第一のテストは、このデモ内容をスクリプティングしたものです。

まだまだ、チームとして試行錯誤的なとこもありますし、自分の中で納得できてないとこも結構あります。ストーリーテストは、ストーリーのサイズが適当であれば、うまくいくと思います。しかし例えば、『ユーザーはシステムにログインできる』というようなストーリーは、場合によってはとても複雑な処理を必要とします。レガシーシステムやセキュリティ認証のシステムをSOA等で接続して、初めてユーザーのログオンが可能になるようなシステムの場合、通常のストーリーのサイズ(4-5日)に収まりません。この場合、小さいストーリーに分割し、その小さいストーリー毎にテストしていくことになります。この場合、全体を通したテストは、いつ誰がどういう形でやるのが適当なんだろうとか答えがでてません。