Why Startups should use Behavior Driven Development (BDD) ?

https://medium.com/everestengineering/software-engineering-is-hard-and-easy-f8246ab4e6f9#:~:text=When%20people%2C%20process%2C%20and%20software,business%2C%20software%20engineering%20becomes%20hard.&text=We%20cannot%20know%20everything%20by,why%20something%20is%20not%20there.

BCG estimates that 70% of digital transformation efforts fall short of meeting targets. A 2020 CISQ report found that the total cost of unsuccessful development projects among US firms is an estimated $260 billion, whereas the total cost of operational failures caused by poor quality software is estimated at $1.56 trillion. The Standish Group’s 2020 CHAOS report estimates that around 66% of software projects fail. 

Reference link: https://nocodebdd.live/software-failure 

That is one colossal loss. To put that in context: if software bugs were a country, it would rank 10th in the world in terms of GDP—and that doesn’t even include the cost of bugs worldwide. 

Building a software product is challenging. Big corporates with deep pockets and top talent struggle to deliver products with high quality. For startups, delivering software products of the highest quality is even harder, as they generally don’t have deep pockets and the reputation needed to attract top talent.  

Can you relate to these issues? 

If you are working for a startup developing a world-class software product and encountering the following issues, then you’re not alone: 

• Requirements are not articulated clearly, or the team doesn’t understand the requirements 
• Building scenarios that customers don’t require 
• Prioritizing the right features 
• Manual testing that takes a great deal of time to test and is inconsistent 
• If you end up achieving automation tests, the system doesn’t work or doesn’t test the relevant scenarios related to the business 
• Either your manual tests or automation tests delay your release cycles 

If you don’t have any of these issues, congratulations—you may be one of the very few startups achieving things that very few, or even no one else, can. If you are one of those startups, please share your experience in the comments so other software startups can benefit. 

Unfortunately, many startups share issues similar to those documented above. In my experience, there is no silver bullet, but behavior-driven development (BDD) is the closest you can get. BDD addresses pretty much all the considerations listed above—if it is rolled out correctly. 

Before we look at how BDD addresses the above considerations, let’s look at why the traditional software development lifecycle (SDLC) doesn’t work.

Why don’t traditional solutions work? 

Let’s look at the process of traditional software development. The usual cycle, even in a well-defined software team, is something like this: 

• Requirements are either discussed and agreed upon among the team or written in some type of format 
• The developer takes the requirements and implements a solution based on their understanding of the requirements 
• The tester manually tests the implemented solution based on their understanding or writes test automation scripts 
• The team gives a demo to the product owner after development showing different features they built not necessarily not all the real-world scenarios

The issue with this approach is in the requirement. When there is an issue at the very start of the development process i.e. your requirements, then how the software will be delivered is anyone’s guess.

Let’s look at the issues with how the requirements are provided; When requirements are written, they are generally at a high level. Even if they’re provided at a detailed level, the following problems could apply: 

• Interpretations among the engineering team might vary 
• The engineering team might not come up with all the scenarios that you can think of as a product owner because they are not as close to your users or your market 
• They may not ask all the right questions because they can’t ask about things they don’t know 
• They are likely to assume scenarios that may not be a high priority to your business—or, even worse, the assumptions might be incorrect 
• As a result of these other problems, the test scripts, automated or manual, might test these incorrect/invalid assumptions 

Let’s look at some of the logical steps one could take to ensure the above issues are addressed. 

Avoiding Invalid Scenarios 

If the product owner collaborates with the team and as a team come up with real-world scenarios they have to implement, then the team can’t assume or miss any scenarios. Likewise, the product owner can prioritize important scenarios and would know which scenarios would be implemented.  

Execute Scenarios 

When a product owner or team member can execute valid scenarios that are written in plain language, then everyone can be confident that the implemented solution works as agreed. 

Build Automation Suite Directly Mapping to Scenarios 

Deriving and agreeing on these scenarios before implementing any solution also helps document all the scenarios your software product can address. Moreover, you can execute all the scenarios at any time to make sure code changes don’t impact any of the derived scenarios.  

BDD basically addresses the above-mentioned logical solution. By using BDD, you not only address the aforementioned issues, you also roll out an industry-standard solution that documents all your scenarios in a way that allows you to easily execute them, thus making sure the implemented solution works as expected.  

Let’s look at how BDD helps facilitate efficient product rollout. 

How BDD can help? 

Many teams use BDD purely for automation; this defeats the purpose of BDD because the issues mentioned in the previous section persist. Rolling out BDD correctly is not difficult and doesn’t require a huge cultural change. The following step explains how BDD can be rolled out correctly. 

Collaborate, Collaborate and Collaborate 

The first step in your BDD rollout should be collaborating with your team members, mainly the three amigos, to derive real-world scenarios. These scenarios should represent your real-world scenarios. If you have different users, then define personas and use those personas for these scenarios.  

Collaboration technique 

It’s important to have a solid structure for your collaboration; otherwise, it becomes another form of red tape and won’t yield the benefits that you intend. You could uses a collaboration technique like OOPSI, which works really well in bringing all the team members together on the same page. 

Implement and Automate Scenarios 

Once the scenarios are derived, the developer takes each scenario and implements a solution. At the same time, the tester automates each scenario to ensure that the implemented solution works as expected. 

Definition of Done 

In rolling out BDD, it is imperative in achieving successful running of all scenarios—not just the scenarios that are newly added—to ensure that the team is following the right process. This provides assurance that the code change hasn’t inadvertently impacted any of other business behaviors, AKA scenarios. Making sure all scenarios pass successfully should be part of your definition of “done”—and only when all scenarios pass can the team confirm that they have successfully completed the functionality. 

Advantages in Rolling out BDD

• Removes any ambiguities in the requirements and get all your team members on the same page 
• Enables writing real-world scenarios with user personas, so that, as a product owner, you obtain a clear understanding of how users will use your product 
• Gives you as a product owner, along with the rest of your team members, the ability to decide on the priority of the scenarios 
• Allows building a test Automation suite directly mapping to your requirements and execution of your requirements to make sure the software is behaving as expected 
• Empowers the team: this point is the most underrated and overlooked but is in my view the most significant benefit. Collaborating and deriving scenarios with all your team members and getting those scenarios to execute successfully removes the blame game (e.g., the tester has missed testing a scenario, or the developer should have thought about those scenarios, etc.) as the entire team is now in charge and in control of quality software delivery 

Issues with rolling out BDD 

Though BDD offers some brilliant benefits, many businesses, particularly startups, are reluctant to roll it out. This reluctance is related to the biggest benefit of using BDD, achieving the functional automation: automating BDD using tools like Cucumber that use scripts is difficult and expensive.  

As you can see from the image below, when you use a script-based solution, you need to write a script for each unique step. In a typical project, the scenarios reach numbers in the hundreds, if not thousands, and thus the amount of scripts you might have to write grows tremendously. 

Let’s look at issues in Automating BDD using scripts. 

Resourcing 

Hiring resources who have both testing and coding skills is expensive. According to Glassdoor, testers with coding skills are paid more than developers. This is one of the major issues for any organization—though particularly so for startups, who generally operate on a tight budget and don’t have the reputation to hire the right resources with the right skill sets. 

Automation is hard 

Even if the startups hire the right resources with both testing and development skillsets, implementing the right automation framework/design is difficult. It takes a good automation architect with considerable relevant experience and a robust skill set to get it right. Simply writing automation scripts, for BDD or in general, without a proper design is bound to fail and won’t scale. 

Expensive 

To achieve in-sprint automation, ideally, you might require every developer to be paired with an automation tester. Even in the best case, you need a 5-3 ratio: 5 developers to 3 testers. Anything lower than that, and you’ll end up with partial automation. Over time, your testers will be spending more time on manual testing, and the partial automation slowly gives way to zero automation. 

Time to Market 

Since automation using scripts gets expensive, if the number of resources is reduced, then in-sprint automation can’t be achieved. As a result, your release cycle gets increasingly longer. 

Losing Automation Engineers 

My experience in working with many organizations and projects indicates that manual testers or junior engineers are generally trained to become automation testers. This creates a separate issue: these resources, once they learn to code, prefer to become full-time developers. As a result, organizations continue losing automation engineers and eventually pivot to manual testing. 

In our experience, we have seen these problems time and again in pretty much every project that uses scripted solutions to automate BDD. This was the main reason for creating NoCodeBDD. In the next section, we’ll demonstrate how you can roll out BDD and achieve automation with limited resources—and with your manual testers—using NoCodeBDD. 

How NoCodeBDD can help accelerate rolling out BDD by 10X?

Using NoCodeBDD, you write all your scenarios just how you would write them in a scripted solution and automate without code by using our different modules—UI, Mobile, API, Relational DB, NoSQL, IBM MQ. We are in the process of adding support for Kafka and various other modules. Using these modules, all you have to provide is some information that should be agreed upon with the team during scenario discovery sessions—NoCodeBDD takes care of the automation. 

The following video shows how you can use NoCodeBDD to automate UI scenarios without code and in just minutes: 

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

I Accept

If you are an API shop, you can use our REST API module to automate your BDD scenarios without having to write code, 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

NoCodeBDD is built to handle complex scenarios. Based on our experience, most of your scenarios fall under the standard process. For example, to test a website, the standard practice is to interact with the web elements and check the output.

For situations that don’t fall under these standard scenarios, you could use custom code modules, write simple scripts, and combine them with other modules to achieve your automation goal. Custom modules offer the possibility of automating any kind of scenario combined with modules, thus reducing the necessity of writing code drastically. 

Testimonial

The following is a testimonial from CodeMantra, who used NoCodeBDD and rolled out BDD not just for automation but as a development principle—and saw great results. 

“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 Rangarajan, VP of Engineering, CodeMantra

You can download a free version of NoCodeBDD from https://www.nocodebdd.com/download

Other related blogs:

BDD vs TDD: https://blog.nocodebdd.com/bdd-vs-tdd/

6 Compelling Reasons to use BDD: https://blog.nocodebdd.com/6-compelling-reasons-why-you-need-behavior-driven-development-bdd/