What is Behaviour Driven Development? The executive summary

John Ferguson Smart | Mentor | Author | Speaker - Author of 'BDD in Action'.
Helping teams deliver more valuable software soonerMay 13, 2018

bdd | Requirements Discovery | test automation |

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. 

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

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.

Feature: Delegate a review task

 Scenario: Delegating a review to another supervisor
    Given Sally has been assigned a high priority review task
    When Sally assigns the task to Doug
    Then the task should be visible in Doug's task list

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.

In summary, a team lead in one of the teams I am coaching said it best: “BDD forces you to BE AGILE, not just to ‘do’ agile.”

 

© 2019 John Ferguson Smart