6 Compelling Reasons Why You Need Behavior Driven Development (BDD)

 Behavior-driven development (BDD) is one of the fastest-growing software development processes. More and more organizations are shifting to BDD, as it allows them to move towards “Shift-Left Testing”—and it is quite easy to adopt. It provides tremendous benefits over traditional development and testing processes. 

In this article, we will be looking at:

• The traditional development process 
• Problems with the traditional development process 
• How BDD addresses the shortcomings of the traditional development process 
• How you can use NoCodeBDD and accelerate your BDD rollout by 10× 

What is the Traditional Development Process? 

In a traditional development process, the team starts implementing the solution without any form of collaboration, which is then followed by testing, as shown in the diagram below. User stories are written in plain language, passed on to the developer and the developer implements a solution based on her/his understanding, then the tester takes the implemented solution and tests based on her/his understanding and finally, when the implemented solution is shown to the product owner, her/his understanding would be completely different to what they documented in the user story. As a result, the team had to redevelop the story and fix issues, which affects delivery and increases bugs.

But the traditional development process doesn’t manifest in this way only. It can take several shapes and forms. And in fact, you could be using BDD but still following the traditional development process. You can identify the traditional development process through some of the following aspects: 

• No collaboration. Team members work in silos. 
• Some collaboration but little or no participation from team members. It is mainly a one-person show. 
• Quality is QA’s responsibility. 
• Documents are given importance over working software or working test scripts. 
• Non-technical members can’t understand the test script format. 
• Not all members can easily access the test scenarios and understand them. 
• Developers hand over testing responsibilities to QA. 
• BDD is used as an automation tool. 

Having any of these aspects can have a tremendous negative impact on the software quality, time to market, employee motivation, and increased attrition. Let’s look at all the issues caused by traditional software processes in the next section. 

Problems with Traditional Development Process 

When you follow the traditional development process, you’ll likely notice or experience some of these issues listed below—or perhaps even all of them. 

1. Quality is QA’s responsibility 

One of the primary reasons for the failure of the traditional development process is that it makes the “quality” QAs’ responsibility. Teams with this mindset end up delivering poor quality software, and often it gets blamed on the testing team. Quality should be a team’s responsibility. Period.  

2. Cost of translation 

In a traditional development process, agile or waterfall, the worst possible approach would be to write a requirement and give it to the team hoping they understand it, interpret it in a way that you intended, and successfully deliver it. Most software deliveries fail for this reason. 

According to Forbes, one of the biggest reasons for software project failures is due to poor communication. It is very well documented and a known issue that people understand written documents — however, well one is written — differently. This is called the “cost of translation”. 

If you’re still not convinced, try writing something as simple as “instructions on how to brush your teeth” in plain English and get someone to follow the exact requirements. They may end up doing something like this: 

3. Non-inclusion 

Being left out during the requirement discussion process is the worst of all. Many projects and managers believe the dev process is the most important aspect of project delivery. As a result, QA personnel are either ignored or are not as inclusive as devs during the requirement discussion process. As a result, the QAs are left in the dark or have a poor understanding of the requirements, resulting in a poor testing outcome. 

4. Time for testing gets squeezed 

This is a very common scenario in software development when traditional development is followed. Because the testing starts after development, if and when the development gets delayed, the time for testing gets squeezed, as the top management wouldn’t want to compromise on the launch date. As a result, either the test team ends up compromising on quality or gets overstretched to complete the testing. 

5. High-value business outcomes might get ignored 

In a traditional development process, the QAs are expected to come up with test scenarios, often without collaborating with the team. As a result, the QAs are likely to come up with scenarios that they find to be highly valuable but might not be as important for the business. Even in the best case, the QAs might end up testing scenarios that might have no business outcome at all. This has several side effects, the main being that the developers might end up implementing these scenarios, which don’t provide any business benefits. 

6. Documentation gets expensive 

In a traditional development process, the teams are expected to create lengthy documents such as test plans, test cases, checklist documents, and bug reports with all the required evidence like screenshots, reasons for failure, etc. Producing all these documents is time-consuming and expensive to maintain. Worse still, most of these documents are just red tape with no input from any other team members and merely exist as a checklist without adding much value. 

The above-mentioned aspects are quite common in many projects that follow the traditional development process, and as a result, it is not uncommon to see QAs try to pivot to a different role in their career. The industry has started identifying these issues and has rightfully started making the quality the whole team’s responsibility and started focusing on testing. As a result, “test-first” or “shift left testing” is getting more prominent these days. 

Behavior-driven development (BDD) and test-driven development (TDD) are the two prominent “shift-left testing” development principles. For a team to deliver quality software and reduce time to market, both BDD and TDD must be followed. TDD is mainly for developers, and BDD is for the entire team—including team members who are not technical. I explain the differences between BDD and TDD in detail in another article: BDD vs TDD. 

In the following section, we’ll look at how BDD addresses the issues mentioned above due. 

How does BDD address those problems? 

One of the main benefits of using BDD is that the team collaborates and derives high-outcome business scenarios based on real-world examples. The derived scenarios are documented in simple, plain language, which becomes the contract for the entire team. 

The developers use these scenarios to implement a solution, and QAs write automation scripts for each scenario to make sure the implemented solution works as expected. Since the scenarios can be executed, BDD is also called “executable specification”. This approach is what makes the BDD stands out; you could define scenarios—in other words, your requirements—in plain language and execute them to make sure the requirements work as expected. 

As shown in the diagram below, deriving the scenarios should be the first step in your development process. Deriving these scenarios upfront allows both the development and testing teams to work simultaneously. 

Let’s look at how following BDD properly addresses the issues caused by traditional development: 

1. Quality is QAs responsibility: When BDD is practiced properly—as part of the collaboration the entire team—mainly the three amigos discuss and derive these scenarios. In other words, the team would agree exactly about what scenarios will be implemented and tested. As a result, everyone takes responsibility. If a particular scenario is not addressed, then it is everyone’s responsibility—including the product owner/business analysts, developers, or QA to participate in the collaboration. 

2. Cost of Translation: The team collaborates and derives the scenarios in simple, plain language. The developer and QA take those scenarios and implement solutions for them and test them. There is no room for interpretation, so the QA doesn’t produce another “Test Case” document. Everyone works from the same agreed-upon scenarios, and as a result, everyone stays on the same page—minimizing “Cost of Translation” or “Misunderstanding the requirements”. 

3. Non-inclusion: The team collaborates and derives the scenarios. As part of the collaboration, the entire team (again, mainly the three amigos) discusses and derives these scenarios. As a result, the QAs are always part of the requirements and the different scenarios they need to test. 

4. Time for Testing squeezed: As the scenarios are derived even before the development starts, the testers get as much time as a developer to automate the scenarios, which should be more than enough. As part of the delivery of the software, it is the developer’s responsibility to make sure all the scenarios pass. This—all scenarios getting passed—is part of the definition of done. 

5. High-value business outcomes might get ignored: During the collaboration process, since the product owner or the BA also gets involved, they and the team can discuss, derive, and prioritize the scenarios that give the most valuable business outcome and can ignore or de-prioritize scenarios. 

6. Documentation gets expensive: The only document the QA or the team has to produce is the scenarios and this is the only document that matters. Every other document is just a red tape and adds little or no value to improve software quality. 

Many organizations have identified these issues and how BDD can solve them. As a result, BDD is becoming adopted more rapidly than ever before. However, organizations are not seeing a higher return on investment (ROI) in rolling out BDD, as automating BDD scenarios is as expensive as any traditional test automation approach. The following sections explain the issues with BDD rollout and how NoCodeBDD addresses them. 

Issues with BDD Roll Out 

One of the biggest benefits of using BDD is achieving test automation. When using scripted tools like  Cucumber  to automate BDD scenarios, it takes a considerable amount of time to automate. When using BDD, the teams must write scripts for each unique step, as shown below: 

Using Scripts to automate BDD 

There are several disadvantages when it comes to scripted tools to automate BDD:  

• Expensive: To achieve in-sprint automation requires quite a few resources and resources with development and testing skills are expensive
• Time Consuming: Time to market is quite high. 
• Resources are hard to find: Finding resources with both testing and development skills is hard to find and expensive. According to Glassdoor, automation testers are paid more than software developers, showing the demand for automation testers in the market. 
• Resource hiring: Hiring resources becomes hard and expensive based on Tech Stacks. When you have varied tech stacks, which is quite common in an enterprise application, the team needs to hire resources with various tech skills. This varies widely—from knowing how to code and handle REST APIs, Selenium to automate UI scenarios, Appium to automate Mobile scenarios, Relational Database, No-SQL, IBM MQ, Rabbit MQ, Kafka, IBM Mainframe integration, etc., and the list keeps growing. 
• Maintenance nightmare: Maintaining scripted code is hard to maintain and becomes a nightmare as your scenarios grow. Typically, in an enterprise application, the scenarios quickly grow into thousands. As a result, the automation code grows tremendously, which quickly becomes a maintenance nightmare. 

The above-mentioned issues are a quite common and recurring theme in any BDD automation. The founders of NoCodeBDD see these recurring issues across many projects and built the tool to address them. In the next section, let’s look at how NoCodeBDD addresses this. 

How does NoCodeBDD address these issues? 

As the name suggests, NoCodeBDD is a codeless BDD automation tool. Using NocodeBDD, one can automate BDD scenarios through a few clicks, as shown in the video below:

 

For privacy reasons YouTube needs your permission to be loaded. For more details, please see our Footer.

I Accept

The following sample video shows how UI can be automated using NoCodeBDD through a few clicks and without any Selenium code: 

For privacy reasons YouTube needs your permission to be loaded. For more details, please see our Footer.

I Accept

 At the time of writing this blog, NoCodeBDD supports the following tech stacks, and you can automate all of them without having to write any code.  

• UI without writing Selenium code 
• Mobile apps without writing Appium code 
• REST API 
• Relational Databases 
• No-SQL 
• Kafka 
• IBM MQ 
• Custom scripts

NoCodeBDD is built to handle complex scenarios. Even if there are edge cases that can’t be supported via the modules, there is an option to write your custom code, which can be matched with any of the existing modules. 

Using NoCodeBDD, organizations are seeing a 10× improvement in their BDD Automation and a 600% ROI. The following testimonial is from one of NoCodeBDD’s clients, Codemantra: 

“I wanted my team to use BDD to collaborate effectively with cross-functional teams and achieve close to 100% automation in-sprint. After evaluating several tools, we chose NoCodeBDD, as it handles complex business scenarios and different tech stacks like UI, API, and relational DB. Using NoCodeBDD, we were able to significantly accelerate BDD automation, achieving in-sprint automation with 600% ROI. I recommend NoCodeBDD to any organization looking to roll out ’Shift-left Testing Automation” 

– Murali, VP of Engineering, CodeMantra