Brian Marick on Acceptance Test Driven Development

I jut saw this interview of Brian Marick on infoq.com.

The comments I found most interesting begin at 16:00 Minutes in, I've tried to summarize a couple of different ways with direct quotes or paraphrases, but I just can't seem to capture the whole idea in context. Please invest the six minutes to watch the video at least 16:00 minutes in - it's worth it.

Also note Brian's follow-up statements at 20:00 in about good testers and what I would call the oblivious school - that many of the initial agile proponents had simply never been exposed to really good, value-adding, professional testers. Also that, as good testers start to come out and get involved in agile, the conventional agile wisdom of software testing is slowly changing.

As to the value of acceptance-test automation, which Brian is challenging 16:00 in, note that I'm somewhere in the middle. My team uses a balanced breakfast approach that includes:

- Story tests executed by a person combined with exploratory testing
- Exploratory testing of high-risk areas when they are changed (loose "charters")
- A regression test suite written in selenese that has roughly 10,000 test steps
- A staging server where we "eat our own dog food" for a week before placing new code in production
- "Slideshow" tests that drive the GUI while a human being watches
- Developers doing TDD and pairing to improve the quality when it moves out of development in the first place

Our test suite /does/ find a number of bugs. What I struggle with is - How much time do we spent writing new test steps? How much time do we spend exploring false error reports and maintaining the tests as the system changes? Could we be doing better things with our time?

"What to do with our time", as they say, is the whole ballgame of software testing. We'd best spend it wisely. If that's true, I hope you'll agree, as I do, that things like the comment above, by Brian Marick, are ... fascinating.