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.
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.
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.
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.
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.
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:
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:
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.
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
I had the pleasure of hosting a webinar with two industry experts, Rebecca Stone from IBM. During the webinar, Rebecca shared her experience in successfully implementing BDD in a large government project, highlighting the benefits of BDD, why and how she used OOPSI and its role in overcoming challenges faced […]
Rolling out BDD in a project requires careful planning and a well-structured process. As a tech consultant on a large project, I had to make several changes to their BDD process and automation suite implementation. Some changes were straightforward, while others proved more challenging. If you’re considering implementing BDD in […]
10 Tips for Writing Effective BDD Scenarios When rolling out BDD having a clear and concise scenario writing is a vital aspect of successful BDD adoption. This blog post will provide you with 10 tips to enhance your BDD scenario writing, making it easy to understand, maintainable, and efficient. 1. […]
It will be difficult to automate testing if you don’t consider it when creating your web application. It will be difficult, regardless of whether you are a code wizard or a no-code ninja. Here are some crucial ideas to have in mind as you develop your app to make testing a […]