I’m hearing of more and more agile teams using Behaviour Driven Development (BDD) as a way to specify the acceptance criteria for user stories. I hadn’t realised how widespread it was getting until I attended two separate talks on it at BA2014 this week (in particular, at the BBC and Aviva).
With each new technique comes a learning curve, both for individuals and for the industry as a whole. The technique matures as people work out how best to apply it.
But there’s good news for anyone learning to use BDD. The technique is already mature, and there’s a body of knowledge out there on how to write BDD scenarios. It’s just that people weren’t calling them BDD scenarios. They were calling them Use Cases.
What is Behaviour Driven Development?
BDD is a technique for specifying the behaviour of an IT system under development, in a way that can be understood by business users, developers and testers alike.
BDD involves writing a number of scenarios that describe how the system behaves under various conditions. The scenarios are normally written using “gherkin” notation as follows:
GIVEN <a set of preconditions>
WHEN <user action>
THEN <system response>
[AND WHEN <user’s next action>
THEN <system response>]
GIVEN the user has an active account
WHEN the user requests to log in
THEN the system asks the user for their login details
WHEN the user enters their username and password (correctly)
THEN the system logs the user in
AND the system displays the welcome page
Agile enthusiasts have got really excited about BDD and with good reason. It has a number of very clear benefits:
- It provides a very clear an unambiguous description of the expected system behaviour in a language that everyone can understand – plain English
- It is easy to convert into an executable, automated test, and hence ties in very nicely with Test Driven Development (TDD)
- The form of words used helps the delivery team to discover edge cases. For example, in the above scenario, the obvious question is: what happens if the user enters the wrong username and/or password? Such questions usually result in further scenarios being identified before development starts, not during, and results in better story size estimates.
The History of BDD
To understand where BDD came from, you need to look back at the history of Agile.
Back in 1999 I remember listening to Kent Beck at OT99 explaining a new technique he had developed called Extreme Programming (XP). He and Ward Cunningham had created XP in response to various problems and frustrations they were experiencing when delivering software. One of their frustrations was with documentation, which they saw as time-consuming and, more importantly, acted as a barrier to richer forms of communication, such as face-to-face conversation, especially when “thrown over the wall”.
So they largely did away with documentation, preferring instead for developers to have a face-to-face conversation with the relevant business stakeholder to understand what should be delivered for a given user story. Documentation was reduced to a stack of hand-written index cards.
And by doing away with the reams of documentation, they also implicitly did away with the people that wrote those documents – the people we now call Business Analysts. At the time I wasn’t a BA, I was a tecchie, so that wasn’t too much of a problem for me :).
XPers quickly recognised that developers needed some way of determining when a story was “done”, so the user story approach was adapted to include acceptance criteria – once the acceptance criteria were met, the story was done. The acceptance criteria for a given story were a non-structured list of things that had to be true for the story to be successful – capabilities, behaviours, business rules, anything relevant to the story.
So, for example:
- User is able to log in
- Incorrect password or user name displays error message
- System displays welcome screen after login
- Passwords must be at least 8 characters
Another key feature of XP is automated testing and, in particular, test driven development (TDD). The first thing a developer does when developing a user story is to write a suite of automated acceptance tests, based on the acceptance criteria for the story. An automated acceptance test is a small program that simulates a user using the system, and checks the system’s responses. If the system responds as expected, the test passes. If not, it fails. Only then do they write the code. Once the code is written, they run the automated tests. If they pass, job done. If not, fix the code and repeat until the tests pass.
Automated acceptance tests are, as mentioned, small programs that test the system behaviour, and they have three types of “commands”:
- Pre-condition commands – preparatory commands that get the system to a state where it is ready to run the test (e.g. navigating the system to the login page)
- User action commands – that enter data into input fields, clicking submit buttons
- Assertion commands – that test that the system has responded as expected (e.g. displaying the welcome page after a successful login)
The problem was that developers struggled to work out what their tests should look like for a given story. What to test and what not to test? How much to test in one go? Where to start in the process?
- GIVEN -> pre-condition commands
- WHEN -> user action commands
- THEN -> assertion commends
And so BDD was introduced into the Agile delivery team’s toolkit.
After a while, agile teams started to notice that writing BDD scenarios, and writing them well, takes time and is somewhat of an acquired skill. And at the same time, Business Analysts were trying to work out whether they had a role to play on agile teams.
Business Analysts Are Back in Business
Based on what I heard at BA2014 this week, it sounds like we are now at a point where BAs are back in favour on (some) agile teams, crafting BDD scenarios for developers to convert into automated acceptance tests and build against.
In my view, this is great news. I think BAs do have something to bring to the agile party – not all developers are good at stakeholder communication and not all developers are good at functional design. Many developers I have met are particularly bad at writing specifications in plain English that business users can understand.
The Wheel Re-Invented
The good news for Agile BAs is that writing BDD scenarios is nothing new. Back in 1986, Ivor Jacobson developed a technique for specifying system behaviour which he eventually called Use Cases. The technique was further refined by Alistair Cockburn in his rather splendid book Writing Effective Use Cases.
Use Cases are pretty much identical to BDD scenarios in their purpose and general structure. They are plain English descriptions of the interactions between a system and its users. The syntax and terminology are slightly different from BDD but otherwise they are the same. Here’s an example (annotated to make the point):
PRECONDITIONS: [GIVEN] the user has an active account
- [WHEN] the user requests to log in
- [THEN] the system asks the user for their login details
- [WHEN] the user enters their username and password (correctly)
- [THEN] the system logs the user in
- [AND] the system displays the welcome page
3a. Incorrect Password
- [WHEN] the user enters their username and password incorrectly
- [THEN] the system displays an error message
- [AND] the system asks the user for their login details again (return to main flow step 2)
I’ve been using a notation that’s a mixture of both formats myself for a few years now in my agile functional specifications.
The particularly good news is that Cockburn’s book tells you pretty much everything you need to know to write good use cases. You could almost take the book and re-name it “Writing Effective BDD Scenarios”. In fact, that would probably be a pretty good money-spinner!
One of the things that Cockburn emphasises is the importance of discovering the edge cases (alternative flows), and how the use case format helps with this. For me, this is the single most useful feature of both use cases and BDD. Cockburn cites it as one of the main reasons why he still uses use cases when everybody else is (or was) writing user stories.
It’s a real shame that Dan Brown didn’t look a bit more into Use Cases when he was developing BDD (there’s an article on his blog from 2007 where he mentions being vaguely aware of use cases – a missed opportunity). BDD has been a great step forward for agile software delivery, but in my view it would have been even bigger if the term “Use Case” had been baked into the Agile lexicon in the way that BDD has.
It’s ironic that XP threw out use cases (and the use case authors – the BAs) and then had to re-invent them (as BDD) and find people to write them again – but this time in a more just-in-time sprinty sort of way. Maybe sometimes it takes an extreme swing in one direction in order to effect change.
Anyway, we are where we are. Things are heading in (what I consider to be) the right direction, even if we’ve had a slightly unhelpful terminology change mid-flight.