Specification by Example

Here is a quote from Gojko Adzic’s book. Feel free to distribute the IT Framework PDF. Download here.

I first want to explain why I chose Specification by Example as the overall name for the whole set of practices, as opposed to agile acceptance testing, Behavior-Driven Development, or Acceptance Test-Driven Development. During the Domain Driven Design eXchange 2010 conference in London, Eric Evans argued that agile as a term has lost all meaning because anything can be called agile now. Unfortunately, he’s right. I’ve seen too many teams who tried to implement a process that was obviously broken but slapped the name agile on it as if that would magically make it better. This is in spite of a huge body of available literature on how to properly implement XP, Scrum, and other less-popular agile processes.

To get around this meaningless ambiguity and arguing whether agile works or not (and what it is), I avoid using the term agile in this book as much as I can. I use it only when referring to teams that started implementing well-defined processes built on the principles outlined in the Agile Manifesto. So without being able to mention agile in every second sentence, agile acceptance testing as a name is out of the question.

The practices described here don’t form a fully fledged software development methodology. They supplement other methodologies —both iteration and flow based— to provide rigor in specifications and testing, enhance communication between various stakeholders and members of software development teams, reduce unnecessary rework, and facilitate change. So I don’t want to use any of the “Driven Development” names. Especially not Behavior-Driven Development (BDD). Don’t take this as a sign that I have anything against BDD.

Quite the contrary, I love BDD and consider most of what this book is about actually a central part of BDD. But BDD suffers from the naming problem as well.

What BDD actually means changes all the time.

Dan North, the central authority on what BDD is and what it is not,  said that BDD is a methodology at the Agile Specifications, BDD, and Testing Exchange 2009. (Actually he called it “a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile
methodology.”)

To avoid any confusion and ambiguity between what North calls BDD and what I consider BDD, I don’t want to use that name. This book is about a precise set of practices, which you can use within a range of methodologies, BDD included (if you accept that BDD is a methodology).

I also want to avoid using the word test too much. Many managers and business users unfortunately consider testing as a technical supplementary activity, not something that they want to get involved in. After all, they have dedicated testers to handle that. Specification by Example requires an active participation of stakeholders and delivery team members, including developers, testers, and analysts. Without putting tests in the title, story testing, agile acceptance testing, and similar names are out.

This leaves Specification by Example as the most meaningful name with the least amount of negative baggage.

Advertisements

Subjectivity aside, leave a reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s