A day (or a sprint) in the life of a BDD team
Introduction
Behaviour 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:
- Speculate
- Illustrate
- Formulate
- Automate
- Validate
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.
Speculate
Behaviour 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 ensuring 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; 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 realise this business value
- Explore and map 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". But they place a special importance on understanding, and making sure the team understands, the business value and motivation behind each feature. So they describe epics and stories in a way that emphasise 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 backwards and starting with the outputs
Chris Matts, 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 (e.g. 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.
Scrum teams are generally used to thinking, and planning sprints, in terms of User Stories. A User Story should represent a piece of functionality that can be delivered within a sprint, and usually in no more than a couple of days. A feature (or epic), on the other hand, is defined in terms of how it can benefit the business, not how long it will take to deliver. Features come in different sizes, and each variation could end up being a full story or simply an individual scenario within a story, depending on the size and scope of the feature under discussion. For example, for larger, epic-sized features, variations might represent complete stories, whereas for a smaller, story-sized feature, the variations will become part of the acceptance criteria for the story, and can be used as a starting point for the Example Mapping and Feature Mapping workshops or 3-amigos sessions where the detailed acceptance criteria are elaborated in the Definition phase.
In larger organisations 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.
Illustrate
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 refusedWhile this format is clear and unambiguous, many more experienced teams prefer a more lightweight notation at this stage. Techniques like Example Mapping and Feature 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 £10,000"), 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 or feature 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.
Formulate
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
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 or Refused>
And if approved, the maximum credit limit should be <Max Limit>
Examples:
| Salary | Approved or Refused | Max Limit | Notes |
| £5000 | Refused | 0 | must be over £10,000 |
| £15,000 | Approved | £2500 | Up to £15,000 |
| £25,000 | Approved | £5000 | Over £15,000 |
| £100,000 | Approved | £5000 | Max limit £5000 |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".
Automate
The executable specifications are now ready to be automated. This automation can be done by engineers in test, 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 goal-posts 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.
Validate
The goal of Behaviour 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 formalised initially.
But 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, organised 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.
Conclusion
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: Speculate, Illustrate, Formulate, Automate and Validate.
READY TO LEARN MORE
Discover How To Build Test Automation Frameworks For Agile Projects From Scratch Fast
Learn to do test automation at scale faster and more effectively in today's agile environments using a proven approach that speeds up both you and your team, without forgetting essential scenarios OR missing deadlines.
Download the Flipped Testing handbook today!
