Let's take a trip down memory lane and look back at some of the myths that were born in the early days of codeless test automation.

1. No flexibility

This was, by far, the most popular myth.

It dates back to the old test recorders from the early 2000s.

And it's the main reason why some folks used to reinvent the wheel and write their own internal test frameworks a few years ago.

Those internal test frameworks were a nightmare to maintain and the ROI was terrible.

It might be difficult to find someone who still does that in the present.

But if you would ask them why, they might tell you that their scenarios are simply far too complex and they need functionalities such as:

• If statements
• Loops
• Variables
• Reusable functions
• Concatenate different strings
• Extract values from JSON objects
• Extract values from arrays
• Extract values from CSV files
• Connect to databases and execute SQL queries
• Send API requests
• Chain together multiple API requests
• Handle iframes, Shadow DOM, multiple browser tabs
• Read and write cookies
• Access the page source and the browser logs
• Execute JavaScript code snippets

The truth is that Codeless Automation tools do support all of those functionalities.

At least Endtest does.

2. Editing is difficult

Another myth that dates back to the early 2000s.

If someone wanted to edit a recorded test, they had to record it again.

Things are different nowadays, editing is easy:

This makes codeless tests more stable and easier to manage than classic Selenium Webdriver tests

If you can still find someone who believes that they need to record the entire test case again or edit the actual code if something changes, please let them know it's not 2005 anymore.

3. Collaboration is difficult

The old test recording tools were Desktop tools.

This means that anything you created was stored on your computer.

Syncing your work with your colleagues was a nightmare.

This led some folks to the following conclusion:

"We need to write code, because we need to put it in a git."

Fortunately, modern Codeless Automation tools are cloud solutions.

This means that anything you create is stored directly in the cloud and you can easily grant access to other team members, use versioning, branches and sync your work.

Endtest even offers an Automatic Backup functionality.

4. It's too expensive

In the early 2000s, due to a lack of knowledge and in an attempt to cut spendings, some teams or companies decided to use only open source solutions.

Not because they took an interest in the community and they wanted to add their contribution, but simply because open source solutions are free.

That principle can no longer be applied, because most modern tools are in the cloud.

If someone asks if a cloud solution is open source, it means that they're not aware of the differences between a library and a cloud solution.

Using a cloud solution helps a company save money, because they no longer have to build their own internal tool by stitching together different libraries.

Let's take a look at an example.

Company A and Company B decide that they need a video conferencing tool because they want to host webinars.

After doing some research, Company A decides that they are going to use Zoom, paying $19 per month.

Company B wants to save money, so they look for open source options. They decide to use WebRTC, an open source project that allows you to build real-time communication apps.

Day 1:

Company A now has a stable video conferencing tool and they start hosting webinars.

Company B starts building their own video conferencing tool by stitching together WebRTC and other libraries.

6 months later:

Company A has already hosted an impressive number of webinars, without encountering issues.

Company B is still working on their own video conferencing tool, they assigned 3 Software Engineers to that project. It's almost ready, but it will take time until they'll have advanced features and there's no way of knowing if it will be reliable enough.

If you do the math, you'll see that Company B actually spent a lot more money compared to Company A, but they didn't get any return on their investment yet.

That's because those 3 Software Engineers have salaries, which are definitely more than $19 per month.

Company B also missed out on plenty of opportunities during those 6 months when they didn't host any webinars.

You can apply the same logic when comparing an open source library such as Selenium and a tool like Endtest.

5. Vendor lock-in

Let's take a look at the definition:

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.

Modern legislation like GDPR and HIPAA makes it mandatory for vendors to provide flexible data migration options.

Your data is your data and you have the right to take it wherever you want.

Just make sure to review the Privacy Policy.

Originally published here