Others have talked about the virtues of stories as vertical slices of a problem (end-to-end capabilities) rather than horizontal slices (system layers or components). So, if we slice the problem with user stories, how do we slice the user-stories themselves?

If, as I sometimes say, acceptance tests (a.k.a. examples/scenarios/acceptance-criteria) are the knife with which we slice a story into even thinner vertical slices, then I would say my observation of 'tasks' is that they are used as the knife used to cut a story into horizontal slices. This feels wrong...

Update: The 'new' WebUser's name has been changed to ScreenPlay4j. All rererences to the new WebUser below should be taken as 'User'.

At the first Agile Alliance Functional Test Tools workshop, I briefly showed a spike I'd done that illustrated how straight forward it would be to write acceptance tests in code. It was somewhat inspired by work already done on things like JBehave and RSpec. However, while they moved further away from code and towards plain text, I went in the opposite direction.

I spotted a tweet by Mark Needham referring to a blog post by Brad Wilson coining the phrase "Design by Example".

I like the Design by Example (DbE) name. It's nice. It rolls off the tounge, more so than BDD in my opinion. But it misses out on the "development" (in the literal sense of the word) in the way that phrases ending in "-Driven Development" don't. It does better emphasise the initial purpose of TDD/BDD/DbE - i.e. design. Although design is the initial purpose, the automated tests or 'executable design specification' provide you with the safety to refactor, as Brad himself says.

In a previous post I introduced a project I'd started with my friend Andy Palmer.

We simply wanted to have a way of journalling our efforts on a new opensource project (don't try and download what's on the public repository - we're treating that as a spike and will be making the latest code available once our first story is complete). We decided that the best way to journal our efforts would be by recording a video of our development sessions.

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'...