If only software development was like listening to internet radio...

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

I've talked about the evolution of internet radio before...

'Internet radio' has come a long way since it first began. Long gone are the days where you have to seek out a station that plays the music you like, or several stations for those with more eclectic taste. Instead, services like Pandora.com and Last.fm create a personalised radio station that matches the user's own personal taste.

These personalised internet-radio stations are far more sophisticated than just specifying what genres and styles you like. In fact, you don't do that at all. With last.fm you provide one or more examples of songs that you like by uploading your music library data to their site. Software analyses the songs in your library finding common aspects of the music's 'DNA' - including genre, tempo and countless other sound characteristics in their database. From this they create a user-specific internet radio station that matches the users taste. As you listen, you give them feedback saying which songs you love and which ones you hate. Your future play-lists are refined with each piece of feedback you provide. This feedback is in itself more examples of songs that do and don't match your taste.

You start out with a reasonable understanding of the kind of internet radio playlist you'd like... genres, artists, tempo and so on... But this comprehension of music is far more basic than the way that last.fm's scrobbler code comprehends music.

You are the domain expert - you know what you like when you hear it. By providing examples of the songs you like, you are bringing last.fm's understanding of your taste closer to your understanding of your taste. Of course, you could just tell last.fm what genres you like and it could generate a playlist including only those genres but that is not building a playlist to your taste... that is building a playlist that has songs in the genres that you know you like. This is far more limited than the true depth of your taste in music. As a result, last.fm gives you get a much richer playlist tailored to your true taste not just a limited set of genres. This has the effect of widening your own understanding of the music you like.

Sometimes your playlist will play songs you don't like other times it plays you songs you love! With last.fm, you provide feedback by saying "Don't play that again" or "Love that Track". It then modifies the playlist so that similar songs are either not played or played according to your feedback.

"Wouldn't it be nice if we could build software that way?" I hear you say. Wouldn't it be great if instead of examples of songs a customer could digitally represent "software behaviour" and provide those as examples to the development team (made up of programmers, testers, architects, designers etc.)? Wouldn't it be great if those examples brought the customer's understanding of what they want from the software and the development team's understanding of what the customer wants closer? Wouldn't it be great if that development team could analyse those examples of behaviour to a depth of detail that resulted in a product that was even better than if the customer just told them what buttons and input boxes they wanted? Wouldn't it be great if you could experience the software soon after your first few examples and say what behaviours you like and don't like? Wouldn't it be great if soon after that you saw that feeedback reflected in a new, working version of the software?

That is exactly what proficient XP teams are doing when they write customer tests (a.k.a. apply ATDD). You could almost take my description of last.fm and replace "you" and "we" with "the customer"... replace last.fm with "the development team (made up of programmers, testers, designers etc)... replace "examples of songs" with "examples of software behaviour"... replace "genres" (and the like) with "buttons, input boxes and other such GUI elements"... most importantly - replace "playlist" with "working software".

In XP examples of software behaviour are represented digitally. These digital representations of software behaviour are written such that the customer can understand, relate to and even write themselves. The team and the customer exchange these digital representations of 'software behaviour' to bring their respective understanding of what the customer needs much closer, much earlier. The team implements software that lives up to the example behaviours. Because the examples are represented digitally, they can be evaluated against the system confirming that the software indeed fulfils those examples... the customer sees that these examples are fulfilled and goes on to further experience using the real, working software so they can say 'love that behaviour' or 'don't like that behaviour' or even give a richer example to refine an existing behaviour that the software currently exhibits. These examples are then digitally represented and used to drive the next iteration of the software. The process is both incremental and iterative. New examples can result in adding to the end-to-end capabilities of the system (incremental) or refine the existing rules and behaviours of the system (iterative). Thanks to the fact that the examples are digitally represented, it is possible to automatically verify when a capability fulfils the latest known examples... also thanks to this ability - it is also possible to know when we change something that damages the software's ability to fulfil earlier examples of behaviour.

Now... look at the previous paragraph... I want you to replace the phrase 'digital representation' with the word 'automated'... Now replace 'examples of software behaviour' with the phrase 'acceptance test'... and you have XP and the XP practice of ATDD. Knowing that these are tests... can you now see what the 'driven development' aspect of ATDD really means? Some call this "specification by example"... some might simply call it reductionism... Whatever you call it it is a paradigm shift for most teams... not least because in each iteration we are delivering end-to-end fully working features - evolving the architecture as we go (as opposed to what many teams end up doing by incrementing the architectural components - only enabling the end-to-end features near the end of the release when it leaves little or no time to incorporate any customer feedback).

What's this really got to do with testing other than the fact that we represent the examples in the form of an automated test? Because testing skills can help us identify the 'detail that matters' or the significant meta-information of the examples... refinement of the examples into the smallest possible, yet meaningful, number of examples (such as with equivalence partitioning, all-pairs and other applicable techniques). Such skills can also help predict combinations or scenarios that the customer didn't anticipate but would be inadvertently enabled by implementing code derived from their examples (e.g. by using oracles other than the customer; by using experience-fuelled creativity; using decision tables, combinatorial mathematics or other techniques to predict behaviours that will be inadvertently enabled by implementing the customers own examples). Each of these examples can be 'shown' in the form of a customer-readable automated test so that the customer can confirm our understanding or explain what should really happen in those cases. We apply these skills in collaboration with the customer while they provide the initial examples during planning, during the iteration as we represent the examples as customer-readable tests and during the iteration as we apply exploratory testing - interacting with the software to discover new examples that we and the rest of the team hadn't previously considered.