要件を記述した上で、それを受入テストとして自動化することに成功したという報告は時折なされてきた（テスト駆動要件やストーリー駆動開発、また人によっては、ビヘイビア駆動開発と呼ぶこともある）。しかし、これを実践しているのはコミュニティの中の少数派でしかない。思想的リーダによっては、これは良くない考えであり時間の無駄であると公言している。各イテレーションの最初に自動化された受入テストを書くという主張は理論的なものに過ぎず、適用事例が少ないということが非効率であることの証明になっているのだろうか。
まずはじめに、自動化された受入テストとは何かを定義しよう。これは典型的にはイテレーションの最初に書かれるテストであり、要件を実行可能な形式にしたものである。換言すれば、記述している要件が完成した場合にシステムがどう機能するべきなのかを示す詳細な具体例、つまり「終わった時にどう見えるのか」に答えるものなのである。かつてはFITとFITNesseが最適なツールだったが、今ではcucumberやrspecなどといった新しいツールがある。
この類のテスト手法は本当に流行してこなかったのだろうか。実際最近では「FITは死んだのか？」と題された対談があったし、Agile 2008ではBrian Marick氏がInfoQのインタビューに答えてこう語っている。
InfoQ 興味深いですね。テストをビジネスのレベル、つまり顧客が理解し、目にすることを期待するものとして見せることには意味があると思います。あなたは具体例について語って下さいました。もしかしたら、単純化、つまりテストという用語を避けるためだったのかもしれませんが、実際には顧客のためのテストについて語っていましたよね？これについて、もう少し説明して下さいませんか？
Marick氏 興味深いことに気がついたのですが、そのようなテストが単体テストのTDDと同程度うまく機能しているとは、とても言えないように見えるのです。それはこういうことです。テストを設計している時にはしばしば、明らかに達成と呼べるような、あらゆる種類の洞察を得ることがあります。もちろん単体テストはすべて、これまでやってきたことと同じことを行います。しかし、それを支えるコードを実際に書くとなるとですよ、これは具体例を作る上では必要なことであり、そのテストは人間が介在することなく実行できるよう自動化されるのですが、単体テストの時と同じような達成感がまったく得られないのです。つまり「なるほど、すごい。コードを書いて本当によかったよ。何かをつかんだ」ではなくて「コードを山ほど書いたけど退屈だった。何も学ぶことがなかった」となってしまいます。コードを書くことによって得られるものが何も無いので、テストができあがるということ以外に実際の利益を得ることができません。さらに今まで、受入テスト、つまり外部仕様に関する具体例は極めて深遠な構造的結論を導き出してこなかったように思えます。リファクタリングが単体テストに対してそうであったような結論を、です。私が疑問に思うのは、テストを作ることに価値が見いだされ、そのコードを書くのに実際にコストがかかるのであれば、そういったテストを実際に自動化することでコストに見合ったものを得ることができるのだろうか、ということです。それというのも、もし見合ったものが得られないのならば、ホワイトボードにテストを書き、プログラマに一つずつ実装してもらい、人間の手でチェックし、さらにはプロダクトオーナへ見せるのも人間の手で行い、終わったらホワイトボードを消して忘れてしまってはいけないのだろうか？ということになるからです。どうしてこういった受入テストを保存し、何度も何度も何度も実行するために骨を折らなければいけないのでしょうか。
受入テストを自動化することを推奨している思想的リーダは今でも多くいる。例えば、Robert C. Martin氏、Joshua Kerievsky氏、James Shore氏が挙げられる。
Chris Matts氏はこの問題に対して興味深い視点を提示している。つまり、入ってくる情報の問題ととらえているのだ。受入テストをアップフロントに書かないソフトウェア開発プロセス（アジャイルに特化したものである必要は無い）を想定すると次のようになる。QAチームはいつも通りにテストシナリオを流し、欠陥が見つかればソフトウェア開発チームにフィードバックする。これらの欠陥はランダムに見つかるので、ソフトウェアチームの生産性にランダムに影響を与えることになる。それというのも、こういった欠陥に対応するために一定程度の工数が割かれるからだ。つまり開発チームに対して、新しい情報がランダムに入ってくるのだ。
ここで、QA部門によって書かれるこういったテストが、開発が始まる前に書かれたらどうなるかを考えて頂きたい。これらのシナリオによって提供される情報は、今やイテレーションの始めにおいて予見可能な形で現れるのであり、したがって不確実さが減り、生産性はより安定したもの（ランダムな妨害が減る）になる。つまり、より予測可能になるのだ。
さて、受入テストの自動化は選ばれた人々（もしくは、幸運な人々）だけが実現できたものに過ぎなかったのだろうか。それほど適用されているとは言えないが、その現状を引き起こしている見えない欠点が内部にあるのだろうか。あるいは、単に難しいというだけで利点は証明されており、全てのソフトウェア開発チームが適用することを目指すべきプラクティスなのだろうか。