There has been a flurry of activity in the blogosphere and twitterverse about the practice of automated acceptance testing. It all started when James Shore said that “acceptance testing isn’t worth the cost. I no longer use it or recommend it.”
Now, when one of the thought leaders in the Agile community says something that goes against the established wisdom, it is sure to provoke reactions:
- Gojko Adzic wonders whether the cost is due to the tools and whether we could do without those tools.
- George Dinwiddie thinks Shore is throwing out the baby with the bathwater and that the problems are fixable.
- Ron Jeffries doesn’t want to give up on the notion of having automated acceptance tests be part of the definition of done, but acknowledges that Fit is a pain to work with.
- Lisa Crispin thinks that there is no one right way and that everybody should experiment to find out what works for them.
James Shore responded to all of them in an excellent post where he explains that he found other ways to get the benefits that automated acceptance tests bring, without incurring the costs. Some of the comments on this post are excellent as well.
All of these bright minds bring good points to the table. They show that the Agile community is not the dogmatic clique that it is sometimes made out to be.
My two cents
I personally sympathize with Ron Jeffries. Seems like a real shame to not have automated acceptance tests be part of the definition of done. So what can we do?
Well, bottom line is that everybody seems to agree that customers providing examples is a good idea. The disagreement is only over whether those examples should be automated or not, and if so, how.
It’s true that customers don’t want to write tests. Why would they have to? Because they don’t trust tests written by others, James Shore says. Well, what about some collaboration? Why can’t the customer give examples that are turned into tests on the spot by developers or testers? Would the customer still not trust these? Where does the distrust come from, exactly?
As for the high costs, isn’t there something that we can do to lower the costs to the point where they are justified? What exactly is it that makes the costs so high? Is it the tooling, as Gojko Adzic implies? If so, why don’t we improve our tools?