When not to Use NoCodeBDD or Test Automation Tools in General 

NoCodeBDD is the BDD Tool. Using NoCodeBDD, teams can automate UI without Selenium code, Mobile without Appium code, REST APIs, Relational Databases, NoSQL, and Kafka. For any edge cases that the product can’t support, you can write custom code and combine an already existing module. 

The following example shows how a custom code is used, along with the UI module to automate a scenario to populate random password characters on a website: 

https://nocodebdd.live/custom-code-sample

However, NoCodeBDD may not be suitable for all scenarios. This article identifies where NoCodeBDD may not be suitable and explains why this might be the case. 

Traditional Testing (Not using BDD)

NoCodeBDD supports only BDD style testing. If the team follows traditional testing without writing their scenarios in Gherkin format (i.e., using Given, When, Then keywords), then NoCodeBDD is not the right tool. 

Unsupported Tech Stack 

NoCodeBDD currently supports testing of UIs, Mobile, REST APIs, Relational Databases, NoSQL, JMS MQ, Kafka. The platform is designed so that any new tech stacks can be easily extended, and we will continue to add new tech stacks. If the test automation requires support for any tech stacks that are currently not supported, it would be better to go with either code-based automation or some other tools that supports this. 

Unconventional applications 

Applications that are quite unconventional would be difficult to test via NoCodeBDD, and the Test Teams are better off seeking a code-based solution. 

Use Case 

A potentially problematic use case is an unconventional application that is more of a tool for operators, with scenarios that check the IBM MQ messages in various Qs, needs to check values on headers and the number of messages in the Qs, and an algorithm to check whether the application works as expected. Though NoCodeBDD could support this use case with some tweaking of reading messages from the Qs and writing custom code, it would be easier to write code and manage test scenarios for applications. 

UIs that don’t have static element IDs and frequently change 

Any browser-based application that doesn’t have element ID or the dynamically generated elements would be hard to maintain using NoCodeBDD. Since the element references change quite often, the test would become very flaky and require lot of maintenance. We strongly recommend using Element ID and not xPath or CSS selectors, as these may vary based on the system you test and would keep changing for each release. 

When you are only running usability/ acceptance tests 

These test cases require human attention and interaction; they cannot be automated using no-code automation tools. 

Version Control Without GIT 

At the time of writing this blog, NoCodeBDD supports only Git. Your team has an option to use Git even if you use a different version control tool for development, but NoCodeBDD is not the right tool if the team absolutely doesn’t want to use Git. 

Conclusion 

In our view, organisations shouldn’t be thinking of codeless tools and traditional automation as an either/or scenario. Applying horses for courses makes a big difference. Customers have accelerated BDD roll out on projects by 10× using NoCodeBDD and have automated complex scenarios—while continuing to use traditional automation where the tool is not suitable. By taking this approach, they use their resources efficiently on projects that require good coding skills. Using a codeless tool and traditional automation should be leveraged as a way to maximize the speed and quality at which software can be delivered to end users.