あなたはクールな新しいアジャイルの世界に乗り出したところだ。最初のアジャイル本（もちろん古典）を読んで熱くなり、ずっと続いている人気ブログ、ちょっとしたノウハウやここInfoQにあるようなアドバイスまで読みあさる。それらはこうアドバイスする。テストを自動化しなければならない。とりわけ、ビジネスに対応する「受け入れテスト」は、要件が理解され実際に満たされているのを確実にするためにあるのだと。さて、ちょっと聞いてほしい。過去にそう言っていたエキスパートの何人かが、今や反対のことを提案しているんだ。やっぱり、そういうテストを自動化してはいけないのだと。
この正反対のアドバイスを支援し、最近の議論を引っぱっているのが、James (Jim) Shore氏だ。彼は尊敬されているアジャイルの思想的リーダーのひとりで、皮肉にも（そうじゃない？）、一時期、Fit（すべての始まりとなったWard Cunningham氏の自動受け入れテストフレームワーク）のプロジェクトコーディネータだったこともある。
Gojko Adzic氏との会話にうながされ、Shore氏は「（自動）受け入れテスティングによる問題」に関する意見をブログに投稿した。彼の意見は次の2つのポイントに要約できる。
- Fitのような自動受け入れツールで実際に期待していた利点は、ビジネスの人たち（「顧客」）が自分で実行可能なサンプルを書くことだった。しかし、そんなことはほとんど起こらないことを歴史は物語っている。少数ながらテスターがこうしたテストを書く場合はあるが、ほとんどの場合は開発者が書いている。
- こうしたテストは実際のところメンテナンス上の障害になることが多い。これらは遅く、不安定で、リファクタリングが困難なことが多いためだ。この点において、エンドツーエンドの「インテグレーションテスト」はその価値以上にコストとなる。JB Rainsberger氏は、その合理的な理由を説明した一連のすばらしい記事を書いている。
一言で言うと、Shore氏（そして、間接的にRainsberger氏）が主張しているのは、意図した価値（顧客がテストを書くこと）が得られないため、高い（メンテナンス）コストを正当化することはできない、ということだ。
それじゃあ、自動受け入れテストを書くなっていうこと？ これまでとは正反対で、過激な意見のように聞こえるんだけど。でも、これは驚くことじゃない。Brian Marick氏も前から同じようなことを言っている。これもまた皮肉なことに（そうじゃない？）、Marick氏が1998年に書いた「ビジネスに対応するテスト」を自動化することで期待できる利点についての論文は、自動受け入れテスティング運動の最前線における草分け的業績だった。それから10年後のちょうど2年前、Marick氏は次のように語った。
プログラマによるTDD、ホワイトボードスタイルのサンプル重視のビジネスに対応した設計、その目に見える成果物の探索的テスティング、一部の自動化されたシステム全体のサニティテストといった手段により構築されたアプリケーションは、GUIによる最小限の探索的テスティングとサンプル重視設計から生じるフルセットのビジネスに対応するTDDテストといった手段により構築されたアプリケーションと比べて、開発しやすくて、品質上も悪くはありません。
Shore氏のメッセージの元々の受け手であるAdzic氏は、第一のポイントについては同意したが、「自動受け入れテストをやってはいけない」というメッセージ全体については完全に納得したわけではない。
私は実際のところ、顧客が自分で書いてくれることを期待していないのですが、顧客を仕様決めのワークショップに参加させるよう仕向け、後で受け入れテストに変換できるようなサンプルを導くのには、比較的うまくいっていました... 明確なサンプルが得られて、コミュニケーションが改善することがこのプロセスの最大の利点ですが、ツールを使うことでさらなる利点が得られます。ツールのおかげで、進捗の公平な評価が得られるのです。Ian Cooper氏は私の新しい本のインタビューで「ツールは開発者を正直にさせる」と言っています。私も同感です。ツールによって公平に評価されるテストを使うことで、「完了」は真に「全員が合意するもの」になります。「ほぼ完了、少しだけ明日やることが残っているけど」となることはありません。私は（Shore氏が記事で提案しているように）オンサイトのレビューでこれを完全にカバーできるのか、わかりません。
George Dinwiddie氏も、ビジネスの人たちがこうしたテストを書くというのは、ほとんどうまくいっておらず、大部分のテスターも同様だ、ということに同意している。しかし、リグレッションによる欠陥を避けるために、自動化にはまだ価値があるのだと主張する。
Elisabeth Hendrickson氏が言うように、「もし、顧客が期待することがあり、顧客がその期待を表現し、あなたがその期待をすでに満たしていると顧客が信じるに足る理由があるなら、あなたがすでにやったと言っていることを本当にやったのか、手作業で再確認しなければならないことを顧客は望んではいないでしょう。」
これは無理なお願いでしょうか？
...
もし、再テストが必要であると納得でき、イテレーションを短期間にすればするほど頻繁に再テストが必要であると納得できたとしても、私は自動テストに見切りをつけたくはありません。
...
もし、顧客の言葉で、顧客といっしょにサンプルの開発に取り組んでいたら、私たちは最も困難な部分も実現できたことでしょう。欠陥が起こってから見つけるよりも、サンプルを利用して（自動化することで）欠陥を防げるのなら、それだけの労力をかける価値はあります。
Shore氏はすぐに、自動受け入れテストなしに「欠陥を取り除く」ために、彼のチームがやったことの調査結果を挙げて、説明を続けた。ここでShore氏は、自動受け入れテストを単にお払い箱にするよう提案しているわけでなく、何かで置き換えなければならないことを明らかにした。そして、その「何か」について、彼の見解を説明しはじめた。Shore氏が提示したアプローチは、基本的に、最新のXPプラクティスをきちんと厳密に適用することに等しい。（とはいえ、この「記事」は熟読してブックマークしておく価値がある）。
Shore氏の2つの記事に対して、Ron Jeffries氏は彼自身の見解とともに登場した。とりわけ、Jeffries氏はAdzic氏とDinwiddie氏と同様、自動化を慎むべきだとは確信できていないと言う。
テストが自動化されておらず、顧客が理解できなくても、それはそれでオーケーだとShore氏は言っています。確かに、顧客が理解できなくてもオーケーです。でも、私は受け入れテストがほとんどないとしても、ある方がよいと思っています。受け入れテストが自動化されていないのは、あまり気持がよいとは思えません。私が懸念しているのは、受け入れテストが自動化されていないと、リグレッションに対して無防備になるということなのです。
こうしたテストがいつ自動化されて、いつ自動化されないのか。自動化されないときに、他のテスターは通常何を導入するのか。こうしたことを知るのは興味深いことです。確かに、コードが動くことを確かめるのに、すべてのサンプルを実行する必要はありません。おそらく、実行する必要があるのはその一部でしょう。
...
私の結論は、確かにShore氏のチームがやっていることはうまくいっており、彼らはすべてのXPプラクティスをかなりうまく実践している、ということです。もし他のチームが彼らと同様にうまくプラクティスを実践できているなら、おそらく似たような結果が得られるでしょう。
そして、後から見つかるストーリー上の欠陥を防ぐには、自動ストーリーテストが最もシンプルで確かな方法だと思っています。
それでは、ビジネスの人たちを開発者といっしょにさせ、サンプルを通じて彼らに話をさせるというのは、やっぱり不可欠なことだと全員再認識できたんだね、やれやれ。でも、こうしたサンプルの自動化については、Shore氏、Rainsberger氏、Marick氏はそうではないだろう言う。その一方で、自動化に賛同する人たちもいる。
実に興味深い議論だ。あなたの意見はどうだろうか？