アジャイルとテストの関係は？
プロジェクトが進むにつれて，顧客やメンバーの興味は「テスト」に移ってくる。そして，事前に「テスト」についてちゃんと考えられていなかったとき，それは後から巨大な壁として認識される。
近年のド短期なプロジェクトでは，リスク管理のもとに，また顧客の信頼を得るために，アジャイルな開発手法を採用することが多くなった。これは，XPやスクラム，広げればUnified Processなども含まれるだろう。タイムボックスを基本として，プログラマに常に見積もりをコミットさせながら，目に見える成果をGetし続ける。そして，直面する様々な問題について常に優先順位を考え，タスクを組み替えながら開発を進めていく。非常にわかりやすい。
この実装の方法では，最低限の品質を確保するために，実装者への単体テストの強制は当然だ。「テストされていないコードは，コードではない」という言葉があるが，まさにその通り。特にデータベースアクセスなどのリソースに対する処理は，単体テストを積み上げることによって，完璧に動作するようにしておかなければならない。
実際に今携わっているプロジェクトで，スクラムチックな実装手法を行っている。その結果，顧客からの信頼もある程度は得ることができているし，何よりも目に見える成果を出せているので，安心感がある。開発が進んでいるという認識は，どのメンバーも持っているはずだ。
しかし，ことテストとなると，話は別のようだ。週単位での実装からのバイナリリリースにテストチームがついてこれない。また，バックログ(未実装など)の共有が不十分なため，テストチームからあがってくる不具合報告も非常に難しく，煩雑な状態だ。
・ テストの単位は実装の期間と同じでいいのか？
・ テストの手順作成と実施する作業との人数の割合は？
・ テストの手順作成にあてる人間に求めるスキルとは？
・ 実装チームへのテスト結果のフィードバックの手法は？
・ 不具合の修正をいつ行うのか？
・ 修正された不具合を確認するのは，誰？
その答えを，僕は出さなければならない。
結局のところ，システム開発は実装に関するプロセスだけに着目して考えてもダメで，やっぱり（機能，システム，運用，負荷，性能）テストについては，実装のプロセスを踏まえた独自の手法を考えておく必要がある。テストチームに実装をリリースして，はぃ終わり，ではNG。でも，スクラムなどの開発プロセスでは，そこまでテストに関する指針はなかったりする。それっていいのか？
EoDからEoTになるために，何か導き出せそうだけど，いまいちピンとこない。アジャイルな開発において，テストはどのように考えるべきなのだろうか？
