Behaviour Driven Development (or BDD) is a powerful collaborative methodology that helps teams focus on delivering high value features sooner and more reliably. BDD builds on and extends standard agile practices such as sprint planning and backlog grooming, user stories and acceptance criteria, and makes them much more effective.
This summary is provided courtesy of John Ferguson Smart who describes BBD as: “BDD forces you to BE AGILE, not just to ‘do’ agile.”
Teams practicing Behaviour Driven Development routinely see:
- Fewer defects
- Better throughput
- Higher quality, more innovative solutions
- Higher quality, easier to maintain automated test suites
- Documentation that is always up to date
How does Behaviour Driven Development work?
A typical BDD process looks something like this:
The BDD process
Teams practicing BDD work together to discover and understand the real business needs behind a user story or feature. They explore (or “illustrate”) the requirement by discussing examples and counter-examples of user and system behaviour with the business. This happens during a workshop often known as the “Three-Amigos” (though there can be more than three people present). The purpose of the Three Amigos workshop is not only to build up a deep shared understanding within the team, but also to uncover areas of uncertainty or incorrect assumptions that would typically only surface much later on. Teams often use techniques such as Example Mapping and Feature Mapping to facilitate the requirements discovery process.
Before development starts, team members formalise (or “formulate”) these examples into a notation that can be readily turned into automated acceptance tests. We call these tests “executable specifications”, as they are written to not only test the feature, but document the system behaviour and business rules. Many teams use a structured language called Gherkin to express these requirements in business terms. An example of a requirement expressed in Gherkin is shown below.
Before or during the actual development, team members automate these executable specifications, wiring them to the production code and turning them into working automated tests. When requirements are expressed in Gherkin, they can be automated using tools like Cucumber or SpecFlow. But BDD is more about the general collaborative approach than about using any particular tool.
These tests are typically run as part of an automated build pipeline – when all of the automated acceptance criteria pass (validate), then the feature is ready to demonstrate, and potentially deploy.
What are the benefits of Behaviour Driven Development?
Teams that practice BDD experience a better synergy between BAs, developers and testers, leading to reduced waste and improved productivity. The deeper understanding shared across the team, and the participation of testers much earlier on in the process, leads to fewer defects and, as a result, higher throughput.
The focus on collaboration helps to avoid knowledge silos, reduces bureaucracy and making the automation of executable specifications a natural part of the development cycle. Test automation is no longer only the responsibly QA, but done both by developers and testers, often together. This in turn helps to build discipline and quality.
The automated acceptance tests provide both fast feedback about progress, and build up a set of regression tests for the whole application. Finally, these tests also act as “living documentation”, that both illustrates how the application works and describes the corresponding business rules.
For more information, please head over to the website of John Ferguson Smart where you will find lots more valuable information, tools and trainings on BDD.
This page is part of the ÆGILITY Agile Lexicon
Please advise any updates or corrections by emailing the information to lexicon@aegility.ch
Whilst every effort is made to ensure correctness of the information, ÆGILITY and Lyaeus GmbH take no responsibility for the accuracy of the information or its use