My Article "From here to Acceptance Test Driven Development - 9 Landmarks to find your way" has been published in Better Software Magazine... make sure you pick up a copy.

Acceptance test-driven development (ATDD) means many things to many people—from “It’s all about testing” to “It has nothing to do with testing,” and from “TDD, ATDD—it’s all the same” to “TDD and ATDD are nothing alike.” Each of these statements describes ATTD from a single perspective, but neither encapsulates the entire meaning. This is often because different people notice different aspects of ATDD depending on where they are coming from.

In an earlier post, I mentioned Boehm's distinction between 'verification' and 'validation':

Verification - Am I building the product RIGHT?

Validation - Am I building the RIGHT product?

-Boehm, Software Engineering Economics

As I was writing an article to appear in the September 2008 issue of Better Software Magazine I arrived at a better way of getting my point across...

In Jason Gorman's post called Tests Are Instances Of Rules he says:

In test-driven development, we use tests as executable specifications of what is required of the software we create.

For this to work effectively, our tests have to convey the underlying intent. And this requires us to ponder the relationship between a test and a specification.

It's true - people who don't get TDD hear the word 'Test' and all but ignore the 'Driven Development' part of it... sometimes to the point that they assume "oh, that's that testers job then"... or the opposite happens when you hear "doesn't that mean developers spend time testing when they should be writing code?"... It can take long and hard to break through this initial cultural barrier... For a long time I've searched for a way other than dropping the word 'T' in 'TDD' to break through the inevitable barrier and I'd almost given up hope... to the point where I was about to resort to the BDD philosophy. The benefits of test-infection made me persist.

To try to get people to understand the 'Driven Development' aspect of writing customer tests first a.k.a. "Acceptance Test Driven Development" (ATDD) and the relevance of the test and testing and testers and let's not forget early and frequent customer feedback... I've been using a different approach. It doesn't solve all of the problems caused by the letter 'T' but it does solve one of them - the part where people ignore the fact that the tests are driving development (yes I said 'tests' not 'testers' - I emphasise this because someone recently asked me 'so, how exactly do the testers drive the developers?').

So... let's talk about something else for a second... I want you to stop thinking about testing... for one moment. I want you to forget about the word 'test' and all the connotations that go along with it... I want you to think about something else... something random... let's say... 'Internet Radio'...

When I hear debates about scripted vs. exploratory testing... or even debates such as "automate all tests" vs. "you can't automate all tests"... I don't think I'm hearing the real debate.

I think the debate that I'm hearing is "testing is about confirmation" vs. "testing is about discovery".

This distinction in the underlying intent of a given approach seems to not be emphasised in these discussions.

In simple terms, I think of the intent behind testing as having two facets:

• Confirmation - Does the system do what we anticipated it should do?
• Discovery - Does the system do (or not do) anything we did not anticipate it would (or should do)?

In a recent post from Jason Gorman he discusses how some people drop the word 'Test' from Test-Driven Development.

I feel their pain... I've felt that way in the past but eventually changed my mind...

Jason explains emphasis of 'Test-Driven Development':

The problem with Test-driven Development is that it's got the word "test" in the title. It's actually not as much about tetsing your code as it is about using tests to specify what code you should write in the first place.

A while back, a colleague - Tim Smith - pointed me at Thomas Nagel's collection of philosophical essays in the book "Mortal Questions".

I was captivated by Nagel's seminal essay "What is it like to be a bat?"

Nagel’s essay discusses perception and poses a strong argument that there is no such thing as objectivity. I.e. we may distil a bat’s system of vision into the concept of Sonar but we can’t possibly know how the bat experiences it because we have only our perception of visible-light, our separate perception of audible sounds and the metaphor of a submarine's sonar to compare it to.

As some of you may recall, a couple of years ago I ran a workshop on Agile Performance testing.

You can find out more about this by searching for WOPR7.

The general theme, with the exception of one experience report, focused on post-hoc performance testing. A lot of work has been done over the last decade to advance functional test-driven development. When I say 'functional' I don't mean 'application level tests' (a.k.a. acceptance tests); I mean tests at the level of unit, acceptance and every level in between where these tests are concerned with functional behaviours (of the unit or the application respectively).