by Janet Genusa
Many people have heard the term Behavior Driven Development (BDD), or know of it compared to Test Driven Development. This methodology is centered around how people behave and interact with others. It is a way to ensure that your team does not create something that does not solve or fully solve the problem at hand.
The first thing that comes to mind for a lot of people when they talk about BDD is utilizing automation with Gherkin. Automation without collaboration is empty. If the team is not collaborating, a process can still be 100% automated, and the team can still fail on delivering the solution the customer is looking for.
Here is a high-level look at what Behavior Drive Development is, and the benefits of implementing this methodology.
What is Behavior Driven Development?
Behavior Driven Development is a disciplined technique for building software for which the product owner, programmer, and a tester collaborates on system behavior (also known as acceptance criteria) for the feature that is about to be implemented. This team is usually referred to as the “three amigos.”
A core feature of BDD is the ability for the entire team to collaborate and ask questions. Questions should be asked about everything. Teams should ask why the feature should do what it’s doing, not just whether the feature is in scope. Teams should always continue to drill down and communicate about the function up front. The inclusion and collaboration of the product owner, programmer and tester, communicating early and often in the process being in complete alignment in the beginning of the process.
Why use Behavior Driven Development?
This strategy of team collaboration allows for every member of the team to know what the overall goal of the feature is, and what problem it is actively trying to solve. It is the alignment of what we are going to build.
This up-front communication strategy gives the tester information to not just test if the feature functionally works, but allows them to test “does this feature solve the problem our client is trying to solve?” BDD ultimately focuses effort, ultimately reducing waste from misalignment on requirements.
BDD is also referred to as “outside-in development.” Where you reach out before you develop to troubleshoot and ask questions, instead of waiting to ask questions after the feature has been built.
By having a shared understanding of acceptance criteria early in the process, testing can more easily and successfully be automated. Automatable testing criteria is a beneficial bi-product of this methodology, further reducing the cost of development.
How does Behavior Driven Development work?
To illustrate how BDD would work, let’s take the example below:
“A bank needs a login capability for its website.”
In this scenario, what’s known is that it’s a website. The fact that the client is a bank means that there may be different business rules to support higher levels of security than an average website. The BDD team would sit down individually and break down every possible scenario that an end user would go through in interacting with the functionality of the login before writing the user stories. They would then come back and compare their results. They would then use that list of scenarios to build behavior driven testing requirements. They should build rules to test around items such as password strength requirements, amount of login attempts, if password caching is allowed, password recovery protocols, etc.
What Behavior Driven Development is not
BDD is not Gherkins. It is not just functional requirements and functional requirement testing. Testing does not only include items around what the feature should do but what it should not do.
BDD is also not about how testers write their tests. The format that the test is written in does not dictate if the test is in the BDD methodology. It is also not solutioning, architecture, or the way the acceptance criteria is written.
How to Implement Behavior Driven Development
So, what is the “ask” for a company to start implementing BDD? Here are a few steps below to start with:
1. Use Gherkin formatted language for functional acceptance criteria. This format makes it easier for teams to collaborate and present a clearer understanding of what the end user’s interaction with a feature is supposed to be.
2. Use the scenarios to support testing pull requests. In order to get the full benefit of this methodology, incorporate the user stories and scenarios into testing pull requests.
3. Create the ring of three in your teams. Have a cross-departmental team of a product owner, programmer and tester, allowing for greater collaboration throughout the project.
