How Does Behavior-Driven Development (BDD) Support Agile Development?

Behavior-Driven Development (BDD) was carefully developed to support agile development in the software industry. This is because agile cannot be fully deployed if the testing process still follows a traditional methodology.

In order to explain the real purpose of this methodology, and how it came to be, we first must understand what it’s not. BDD was built as an alternative to the traditional waterfall method in order to better support agile development.

In the waterfall model, testing starts once the development work is completed. This structured and rigid approach doesn’t allow for alterations or changes until the testing phase has finalized, which slows down the development process considerably.

When we look at the teams who are currently using BDD, most of them have gone through a similar process. Their organization decides that they need to go to market faster and, therefore, accelerate releases. After some consideration, they decide to go agile through the means of sprints, scrum, or the like.

Then, after some time, they realize that testing has become the bottleneck of their agile efforts as QA struggles to keep up with this accelerated pace. Therefore, they finally decide to seek continuous testing through test automation.

Even though this decision will most probably improve the current state of the project in some way or another, there are two key issues that will arise throughout this last agile implementation to the software development process:

1. How aligned is development and QA at this development speed?
2. How can they make sure that they are building what the customer wants?

The common denominator in the answers to these questions is collaboration; and BDD facilitates just that.

What is BDD?

BDD is a set of practices that make interactions possible between individuals in a team. Through conversations, examples and automated tests, the team is able to discover, and then implement, the desired behavior of a given software.

It is based on the same principle as the ‘three amigos’, where business, development and QA collaborate to define what to do, how to do it and how to know if it’s been done correctly.

• Business stakeholder: What problem do we want to solve?
• Developer: How do we build a solution that solves this problem?
• Test manager: What could possibly happen that prevents this?

 In BDD, this conversation is utilized to write test scenarios in English-like constructs that clearly describe the end-user’s behavior. Meaning that if there are other relevant stakeholders apart from the “three amigos”, they can – and should – be involved in the conversations.

By doing so, all relevant stakeholders in the software development process have a clear idea of what it is that they are trying to build. Thanks to this, they are able to identify any possible misunderstandings and confusion early in the process, thus enabling each participant to successfully perform their respective tasks.

All in all, BDD offers a methodology that allows teams to become fully agile in the software development process. It extends and builds on standard agile practices – such as sprint planning, user stories and acceptance criteria – and makes them much more effective.  

It helps teams build the right thing by enabling teams to locate and concentrate on the features that really matter. This, in turn, will reduce rework and time-waste as well as accelerate the flow of value.

What key characteristics of BDD complement your agile efforts?

• Collaboration through face-to-face conversations: BDD promotes communication between key stakeholders in the software development.
• Working software is the primary measure of success: BDD gives a platform to all stakeholders to identify any possible misunderstanding and confusion early in the process, helping the team building the right thing.
• Capture requirements at a high level – lightweight and visual: BDD describes the end-user’s behavior through test-scenarios written in English-like constructs.

We should not forget that conversations in development matter because software is – after all – made by people. When we look at the bigger picture, we realize that testing is not the bottleneck; ignorance and uncertainty are.

There are many ways in which you can combat those; BDD is one.