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:
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.
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?
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.