No-code test automation

1. What is no-code test automation?

Low-code and no-code refer to tools that allow users to build logic inside of software, or full applications, without having to write complex code.

Low/no-code development often features drag-and-drop interfaces, but not all low-code and no-code tools are used to build apps.

In the last years, we've seen more and more users building their automated tests by using no-code solutions such as Endtest.

2. Where did it come from?

This trend emerged when software teams began measuring the ROI of their work and started searching for ways to increase it.

A few years ago, building automated tests was a difficult and chaotic task, teams would attempt to build their own internal frameworks by stitching together multiple open source libraries.

In some cases, the outcome of these expensive and time-consuming endeavours was not a successful one.

These projects would often become increasingly difficult to maintain.

3. Why did most test automation projects fail?

The root cause seems to be related to bad decisions and a lack of vision.

The planning would not involve questions such as:

1. How long would it take?
2. How much would it cost us?
3. What is the ROI?
4. Are we reinventing the wheel?
5. Is there a better way to do this?

Asking those questions before starting a test automation project is imperative.

The temptation to build an internal test automation solution from scratch by stitching together open source libraries would disappear, since it would become clear that the ROI for such an approach would be terrible.

While you may be tempted by the zero cost of an open source library such as Selenium, it's worth knowing that the time you consume writing code for those tests still translates into large spendings for your company.

Most of those internal test automation solutions would end up being "Frankenstein" projects, built and maintained by only 1-2 developers, with a very low adoption rate among the team.

These projects would often be abandoned after one of those developers would leave the company.

4. Why is no-code better?

A no-code testing tool allows you to build and execute your first automated tests in just a few minutes.

This means that you're getting something in return from Day 1.

The lack of complexity translates into a frictionless adoption of that tool in your team.

Non-technical members can start contributing and add their value to your team in new ways.

The no-code approach for automated testing is the only one that has a solid ROI.

5. Is no-code only for people who can't code?

No-code is for anyone who wants to be efficient and save time.

Just because you can build it, doesn't mean you have to.

For example, you could probably build your own video conferencing solution by using WebRTC, which is free and open source.

But it would take you a few months to build it and the successful outcome isn't a sure thing.

That endeavour would have a terrible ROI.

Using a video conferencing tool like Zoom would not be free, it would cost $19 per month.

But that price is significantly lower than what it would cost you to build your own video conferencing tool.

And you would be able to use it from Day 1.

6. What about vendor lock-in?

A vendor lock-in, also known as proprietary lock-in or customer lock-in, makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs.

This seems to be one of the most common fears when it comes to adopting a no-code solution.

As long as data portability requirements are met, this risk does not exist.

Teams who hesitate to adopt proprietary solutions due to this fear may end up in a developer lock-in, with an overcomplicated solution which was built internally and which can only be maintained by 1 or 2 developers.

7. No scenario is too complex

No-code tools like Endtest include functionalities for using variables, if statements, loops and reusable components.

If something is easy to use, it doesn't mean that it automatically lacks flexibility.

If that would be true, all developers would have to write machine code instead of using programming languages.