Behaviour Driven Development – Use Cases Re-Invented

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>]

For example,

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?

Dan North and Chris Matts co-created BDD in 2004 as an answer to these problems. BDD scenarios written in plain English are very easily converted into automated tests:

  • 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

MAIN FLOW:

  1. [WHEN] the user requests to log in
  2. [THEN] the system asks the user for their login details
  3. [WHEN] the user enters their username and password (correctly)
  4. [THEN] the system logs the user in
  5. [AND] the system displays the welcome page

ALTERNATIVE FLOWS

3a. Incorrect Password

  1. [WHEN] the user enters their username and password incorrectly
  2. [THEN] the system displays an error message
  3. [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.

4 thoughts on “Behaviour Driven Development – Use Cases Re-Invented

  1. chris matts

    Hi Tony

    Good to hear that you like the GWT format. As a BA and the co-creator of the format with of GWT (in 2004) with Dan, I can tell you that I was well aware of Use Cases. I had even met Alistair Cockburn several times. Funnily enough, it was on a walk to Alistair’s house that much of the conversation around BDD started.

    The goal of BDD was to help non-technical people describe the criteria in a way that did not require the developer to do any translation of the requirements. GWT is a direct mapping to the TDD style with Mocks.

    A couple of years after creating the format, Dan and I reflected that it was already covered by the Use Case although the Use Case. I still use Use Cases to investigate some interactions, especially when state is important. I do not necessarily use them to communicate with the development team.

    After we came up with the GWT format, Dan focused on the tooling. I focused on how we could use established BA tools ( Domain Models, Use Cases, State Models, etc. ) to generate the examples that we describe with GWT and other approaches. The approach I came up with was called Feature Injection. I gave a workshop on FI at the first European BA conf.

    Let me know if you want to know more about how to use Use Cases and other traditional BA tools with Agile and GWT.

    Regards

    Chris

    Reply
    1. Tony Heap Post author

      Hi Chris,

      Thanks for your feedback – it’s good to hear it from the horse’s mouth. First of all, credit where credit’s due – I’ve updated the article to reference you as a co-creator of BDD.

      It’s interesting to learn that BDD was to some extent inspired by (Cockburn-style) use cases – I guess that goes some way to explaining why they are so similar. Like I mentioned above though, it’s a shame the linkage hasn’t memed its way into the collective consciousness – newcomers to BA may be unaware of the wealth of existing resources, and old hats may be unaware that their use case writing skills are easily transferred to BDD.

      It did at least provide for some humour at BA2014 – in the Q&A following a BDD-related session, I decided to put my head above the parapet and point out that GWT scenarios seemed very similar to use cases, fully expecting to be flamed, but the opposite happened – I received several comments (and even tweets) along the lines of “I was thinking the same thing!”. That’s really what inspired me to write the article.

      Reply
      1. chris matts

        Hi Tony

        I find Use Cases are useful in some circumstances. However, there is a big cognitive bias that they introduce that you need to be mindful of, namely they encourage you to work from the start to the finish. Working forwards, we unconsciously destroy options and makes it hard to ensure coverage. Working backwards from value (outcome) -> output/end -> process -> inputs/start means that it is easier to identify options at each stage.

        I’d be interested to hear of your experiences with GWT.

        Regards

        Chris

        Reply
        1. Tony Heap Post author

          Hi Chris,

          When I talk about using use cases, I’m really thinking about the particular skill of describing system behaviour as a sequence of steps – user does X, system responds with Y – in plain English, and describing the intent, not the mechanics, and identifying the alternative flows. Not necessarily the top-down aspect of use cases.

          Here’s how we’re working on my current project (for more details see Business Analyst Designer Method).

          Phase 1 (Request): First, a business stakeholder requests a feature (i.e. asks for what they *think* they want). We add the “request” to the product backlog.

          Phase 2 (Define): We do 5 whys on the requested feature to get to understand what their underlying objective is (they asked for tea bag, really they are thirsty). Then we generate as many options as possible that meet, or partially meet, the objective (we call it “options engineering”). We do size estimates on the promising options and then select the preferred option (collaboratively with the stakeholder). If the feature is too big, we split it into phases (like splitting an epic into stories) and put each phase as a separate item on the backlog, prioritized separately (this ensures that any “gold plating” is delayed/avoided. We always include a “do nothing” option – because sometimes it turns out that the user didn’t want the thing they thought they wanted, or it was going to cost more than they thought it was worth.

          Phase 3 (Design): Assuming phase 1 is still a high priority, we then write the acceptance tests in use case/GWT format. The tests are written with the user objective in mind, as captured in step 2, so hopefully we end up with a set of tests that, together, fulfil the user objective.

          Having read what you’ve written on Real Options and Feature Injection, it sounds quite similar – the key point being that we focus on the objective and identify options to fulfil the objective, rather than just building what the customer thought they wanted.

          Reply

Leave a Reply

Your email address will not be published. Required fields are marked *