Behavior Driven Development – What it is and how it works

In software development, this is a common problem and is one of the biggest sources of bugs and rework.  This costs time and therefore money.  The cause is almost always a lack of team understanding around requirements.

 Behavior driven development (BDD) is a software development technique for agile teams that helps to reduce this type of rework and regain time for new development work.  Thus saving time and money.

When applied correctly, BDD bridges the gap between the development team and product owners by building a shared understanding of the user story between the product owner, developers and testers.

This leads to a significant reduction in the amount of time spent on rework caused by misunderstood requirements, enabling teams to deliver the right thing, first time, on time.

Research backs this up.  Teams with poor communication and collaboration techniques are more likely to produce features that fail to match the business vision or that contain bugs.  The lack of shared understanding of the user requirements between product owners, developers and testers account for 54% of defects in delivered software  (Ref Preventing Requirement Defects, S Lauesen & O Vinter).

Consider BDD as a process of three stages:

1 – Discovery with Behavior driven development

The Discovery phase typically starts with an informal meeting, commonly known as ‘three amigos’ that brings together team members from testing, development, design and the business.  The key purpose of this meeting is to have a conversation about your domain defined from the user’s perspective, to ensure you are building the right thing.

Examples of how the software is expected to behave in different situations, is discussed from the different perspective of each stakeholders.   This clarifies bad assumptions and often reveals new information that collectively forms shared understanding. Collaboration is key to this discovery phase and is the single most important part of BDD.

2 - Capture with behavior driven development

During the collaborative discovery sessions key examples that illustrate the behaviours to be delivered are taken down as notes by teams members from the discussion. In BDD, this information is formally captured using Gherkin syntax which consists of ‘Given When Then’ statements. These captured examples help teams to agree behaviour before development work begins.

3 - Automation with behavior driven development

Once the key examples have been formally captured and the team has agreed they are ready, developers can then begin to use them as automated acceptance tests to guide the development, using a process known as ‘outside-in development’.

This encompasses ATDD (Acceptance Test Driven Development which uses automated examples to guide us towards building the right thing) and TDD (Test Driven Development which using unit tests to guide us towards building it right). Once all the acceptance tests are passing, the developer has the confidence the team are delivering exactly what the business wanted.  This process significantly reduces the probability of rework and leaving more time for new development work.

Many people mistakenly associate BDD purely with test automation, but it is more than that.