…the preamble is that some folks never automate testing, and some only write developer tests. So the point is we need TDD, then test-last tests, THEN storytests, all to provide that “layering”.

It sings to me.

Rosamund Zander (Ben’s wife) explains the idea of stating “how fascinating” when making a mistake.

Garr Reynolds posts:
http://www.presentationzen.com/presentationzen/2008/12/benjamin-zander-at-poptech-2008-how-fascinating.html

http://www.poptech.com/popcasts/benjamin_zander__poptech_2008

very well put. Still, one totally different question is nagging me. Although I myself totally *believe* in acceptance tests as not only a good quality agent in the development process but also as an acelerator towards a good lead time as well as a good and solid release cycle, I have the following problem:

As I already said, I belive in that, I think that we have relatively few facts about ROI of acceptance tests. Given the situation that for any medium sized organization upwards this is a tremendous change, it might be that we need to collect for fact based ammunition to convince our environments?

Just think of my environment where we have a huge code base with only few automated acceptance tests and imagine being the first team including that in your definition of done, process or whatever. Not an easy and not a nice job, and one easy to convince your peers, upper management and team members of.

And it is even hard to argue that these are *small* issues ;-)

Cheers

Markus

—Michael B.

“Typically, responsibility for the tests gets handed off to testers, which defeats the whole point” – I would question why this defeats the whole point. In more traditional development processes an analyst would be present who would be skilled in converting the requirements in the language of the business into the appropriate models and requirements to drive the development of the system. If a tester possesses the necessary analytical skills then why not rely on them to create the appropriate tests based on the requirements communicated from the cusomer. To put it another way – if your analyst could create a specification that tested itself you would be very happy, so why not furnish the tester with analytical skills to allow them to achieve the same?

In terms of the maintenance costs, I have been running with an in-house developed automated test harness for 3 years now. There is an overhead on maintenance but with careful consideration towards maintaining the tests separately from the executable code we have managed to overcome some significant rework of application functionality without having to rework large numbers of tests. Again this does require the necessary skills within the test team to treat the regression harnesses as applications in their own right, and design them with maintenance in mind.

I would reiterate Lisa’s point that it’s an evolution, and there are obstacles to overcome, many of which we are stil tackling. I do not see, however, any of the problems as sufficient reason to give up on automated acceptance testing, which are the one of the cornerstones of our current development process.

———————————————————
http://www.linkedin.com/in/adampknight
http://a-sisyphean-task.blogspot.com
http://www.twitter.com/adampknight

-Patrick

As someone who is trying to get a team to strive towards automating their acceptance tests, seems lik increasing the conversation around concrete examples is the way to go.