Have you ever stood in a sprint demonstration where the product owner said:
“That’s not what I wanted” ?
This is a common problem in software projects – one of the biggest sources of bugs and rework – and usually highlights a lack of team understanding around requirements. Behaviour 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.
When applied correctly, BDD helps to solve the “That’s not what I wanted” problem 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.
Teams with poor communication and collaboration techniques are more likely to produce features that don’t match the business vision or that contain bugs. One of the most common causes of bugs and delays in software projects is a lack of shared understanding of the user requirements between product owners, developers and testers - accounting for 54% of defects in delivered software.
Consider BDD as a process of three stages:
BDD involves talking about your domain from the user’s perspective, to ensure you are building the right thing. An informal meeting commonly known as ‘three amigos’ brings together team members from testing, development, design and the business, to have a conversation.
They collaboratively discuss examples of how they expect the software to behave in different situations, with everyone asking questions to dispel any incorrect assumptions and reveal new information. Once everyone is clear about what is required, then shared understanding has been reached. This collaborative phase is the single most important part of BDD.
Team members may jot down notes during their collaborative sessions and then, either during or after, they can capture the key examples from the discussion that illustrate the behaviours to be delivered. In BDD, this is written using Gherkin syntax which consists of ‘Given When Then’ statements. The captured examples help teams to agree behaviour before development work begins.
Once the key examples have been 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 (using automated examples to guide us towards building the right thing) and TDD (using unit tests to guide us towards building it right). Once all the acceptance tests are passing, this gives the developer confidence that what the business wanted has been delivered, thus reducing 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.