Behavior-Driven Development is a collaboration practice that uses conversations around concrete examples and requirements, expressed in an executable form, to deliver higher-value software more effectively. In this article, we walk through a typical BDD process. While every BDD team is different and mature teams adapt and refine their process to suit their specific needs and context, the steps outlined here give an idea of the general approach followed by many of these teams.
A typical mature BDD process is made up of a cycle five key activities:
This is not a linear process, but a cycle that repeats itself throughout the project. In mature teams, you will see all of these activities at various points within each Sprint.
Behavior-Driven Development is at its heart about requirements discovery and definition, and BDD activities should ideally start very early in the requirements discovery process. Business analysts talk to the business in terms of concrete examples, simply because this is an effective way to explore business needs, identify invalid assumptions, and ensure that all angles have been covered. This in turn helps avoid defects and rework throughout the rest of the process. User experience experts may also get involved at the requirements discovery stage to help better understand the users of the future system.
These activities typically happen before the start of a Sprint. They can occur in Sprint planning or even earlier. The main activities include:
Defining features (or epics) in terms of business value and outcomes.
Understanding the outputs that will realize this business value.
Exploring and mapping business flows that deliver these outcomes and outputs.
Defining Features That Focus on Business Value and Outcomes
BDD teams express requirements in terms of high level features, which they might refer to, using the Scrum terminology, as epics. However, they place a special importance on understanding (and making sure the team understands) the business value and motivation behind each feature. They describe epics and stories in a way that emphasize the business value delivered, like the following:
Some teams also use a hypothesis-driven format, in particular for high-level features or epics, where the business goals are defined in clearly measurable terms:
Features and Epics in this format are usually written by the BA in collaboration with the business stakeholders, and, in a Scrum team, would go into the product backlog.
Working Backward and Understanding the Outputs
Chris Matts, the inventor of the Given-When-Then notation, likes to point out that the value of any software system is in the outputs (i.e., what it can produce) rather than in the inputs (i.e., what the screens look like). Dan North describes BDD as an "outside-in" methodology. This is because BDD encourages teams to focus first and foremost on the outputs that need to be produced by each feature, rather than with the inputs.
For example, in the ordering a credit card online example, the outputs might include:
A credit card is posted to the customer.
A Terms and Conditions document is sent to the customer via email.
A new credit card account associated with the card is accessible via online banking.
Focusing on the outputs can lead to conversations about the relative value of each output, which can in turn help reduce the development effort needed to deliver this feature. For example, sending out the credit card is clearly an important output, but do the Terms and Conditions really need to be sent as a PDF? Maybe they could simply be a link to a page on the bank website.
Exploring and Mapping the Business Processes and Flows
Once the outputs are understood, the team will think of the processes involved in achieving these outputs. The team will often use story mapping, high-level process mapping, or other similar techniques to understand the flow through the system; this helps identify the fastest way to delivering a usable feature and also makes sure that no steps are forgotten.
A simple flow for the ordering a credit card online feature might look like this:
Each activity in the flow invites discussion around variations, alternate flows, and edge cases. For example, if we ask about the "check financials" activity, we might learn that the check is related to the client’s salary, that there are special rules for couples, and that different rules apply if the client has an overdraft facility.
In larger organizations where teams may not have the luxury of having permanent access to a business stakeholder and where the business domain is complex, much of the work in this phase will be done by business analysts, who talk to the business stakeholders and do their own research. Story mapping workshops happen later, before Sprint planning, and involve a broader audience. The understanding that comes from these workshops feeds into Sprint planning and helps the team figure out what the business can expect at the end of the upcoming sprint.
The flow diagrams and story mapping workshop also help UX or UI designers to envisage the overall structure and screen flow of the application and start to sketch out some rough wireframes.
Later during the Sprint, the team members who will be working on a particular feature or story get together to discuss the detailed requirements. This typically involves in the least a business representative (BA), a developer, and a tester. The goal of these three-amigo sessions is for the team members to get a deep shared understanding of the business rules and acceptance criteria for the story and to actively uncover any previously missed complexity or risk that might trip up subsequent development efforts.
Teams often express acceptance criteria using the well-known "Given-When-Then" format, like in the following example:
Scenario: Applying for a joint credit card with insufficient combined income Combined income must be over £10,000 Given Susan has an income of £3000 And Jim has an income of £2500 When Susan and Jim apply for a joint credit card online Then the application should be refused
While this format is clear and unambiguous, many more experienced teams prefer a more lightweight notation at this stage. Techniques like Matt Wynne’s example mapping help cover as many business rules, examples, and edge cases as possible without getting bogged down in formal syntax or wording.
Using this approach, some examples will be simple enough to record in a single line (such as "A couple applying for a joint credit card must have a combined income of over x"), whereas others might need a little more detail to nail down all of the variations. In the table shown below, for example, we explore the relationship between annual income and the maximum credit limit that the bank is willing to offer.
The outcome of these sessions will be a set of unambiguous acceptance criteria for the story, ready to be expressed in a form that can be automated (an "executable specification"). These sessions can and should be short and sweet (an example mapping workshop for a single story can typically be completed in under 30 minutes).
The business rules, examples, and understanding that emerge from these sessions also helps the UI designers to create more detailed wireframes or screen designs.
Next, the team takes the examples and rules that were discovered during the previous phase and turns them into a form that can executed as automated acceptance criteria. Many teams use BDD tools like Cucumber to automate the acceptance criteria defined in the previous phase. To do this, these acceptance criteria need to be written using the more formal given-when-then (or Gherkin) syntax, like the one shown here:
Feature: Credit card financial checks
Feature: Credit card financial checks In order to ensure that credit cards are not given to customers who will be unable to repay them As a financial institution I want to ensure that only clients with sufficient annual income are provided with a credit card Scenario Outline: The maximum credit card limit depends on the customer's salary A customer needs a salary of at least £10,000. There are two types of card, one with a limit of £2500, and another with a limit of £5000 Given an individual customer with an annual salary of <Salary> When the customer applies for a credit card Then the credit card application should be <Approved/Refused> And if approved, the maximum credit limit should be <Max Limit> Examples: | Salary | Approved/Refused | Max Limit | Notes | | £5000 | Refused | 0 | Salary under £10,000 | | £15,000 | Approved | £2500 | Up to £15,000 | | £25,000 | Approved | £5000 | Over £15,000 | | £100,000 | Approved | £5000 | £5000 is the max limit|
Since writing these scenarios can be time-consuming, many teams find it more efficient for the tester to write these scenarios using the examples and rules defined in the previous phase before checking them with the business analyst. Once they are in a form that can be run as part of the automated acceptance test suite, they become executable specifications.
The executable specifications are now ready to be automated. This automation can be done by engineers in testing, developers, or as a collaboration between the two. In all cases, automation work tends to start as early as possible in the development phase and is typically done in parallel or slightly after the development work.
Automation and Development
Developers in a BDD team often use an outside-in approach to development. The automated acceptance tests give them clear goalposts about what outcomes they are trying to achieve for each feature or story. An outside-in approach also tends to make it easier for teams to adopt good software development practices such as Test-Driven Development.
Automation and Testing
In a team using BDD, testing happens throughout the Sprint rather than at the end or in the following Sprint. Testers do both automated testing and exploratory testing throughout the Sprint, but teams generally find that the need for manual "scripted" testing disappears fairly quickly.
In mature BDD teams, team members naturally tend to become more cross-functional. I have seen many teams where it is the developers who automate the acceptance criteria for their own stories, as this gives them a faster feedback cycle and helps them find (and fix) defects sooner. It also tends to lead to faster and more efficient automated acceptance tests. In these teams, testers often move to a role of "QA coach," defining high quality acceptance criteria and helping ensure that the developers test their code effectively.
The goal of Behavior-Driven Development practices is to deliver more valuable features to the business sooner and more often. By combining BDD and automated acceptance criteria, teams can demonstrate a clear traceability between what was delivered (and demonstrated to work) and the requirements that were discussed and formalized initially.
It is also important to have clear visibility on what features are being delivered and what is ready to deliver at any point. It’s no good deploying a feature quickly if no one knows it was included in the latest release. In a BDD project, teams use not only test reports but also living documentation and release readiness reports to provide this feedback in real time.
Definition of Done
In a team practicing BDD, the automated acceptance criteria are part of the definition of done. In other words, a story is not considered finished until its acceptance criteria pass. This, along with the emphasis on internal quality discussed earlier, significantly reduces the number of defects that need to be fixed after the sprint has finished. As a result, developers do very little bug fixing and can focus their efforts on implementing new features. The end result of this is higher effective throughput and more working features sooner.
Regression Tests and Living Documentation
After the Sprint ends, the acceptance tests for that sprint join the growing regression test suite. In mature BDD teams, the regression test suite, organized in terms of features and capabilities, can then act as a form of functional documentation, describing not only what the system does but also what business goals it is trying to achieve.
Mature BDD teams focus on outcomes more than processes, but they do share a number of common practices and approaches. So, when considering your own BDD practices or BDD adoption, always remember the five key activities: discover, define, formalize, automate, and deliver.