Trends – The Return of Codeless Automation

In my first ever test automation role, I was introduced to a tool called QTP which my team had used to bodge a very crude framework written in Visual Basic. Alongside their coded tests, they had a suite of tests that were used by QTP’s record and playback tool. Even at this infant stage of my testing career, I could see these were bad news, both from a reliability point of view and a maintenance one.

The way these tests were created was by literally pressing a record button on the screen and the tool would then create a script from your interactions with whatever was on screen, be that mouse clicks or inputting text. When you run that test, it would mimic your actions exactly and providing it was able to do so, give a pass or fail result at the end.

Problems quickly arose when there was even the smallest change to the UI or if the inputs or outputs expected were different. When that happens, the test was effectively useless and you’d have to record a new test to replace it. This way of automating tests was just unmanageable and the ROI (return on investment) was so low that everyone just gave up on them, and so it was, that codeless automation just went away for a few years for the most part, kept alive in part by the masochists that loved to be punished by its unforgiving nature.

Fast forward to 2019, and codeless automation is back and in a big way. However, it’s not the codeless automation we rightfully gave up on all those years ago, this new wave of tools provides extremely robust tests that can be put together in the fraction of the time that a coded automation test suit would be.

Buzzwords such as Machine Learning and Artificial Intelligence are all part of the blurbs for these latest tools.

So how do these tools differ to the record and playback tools of old? Well, at their very basic level, a lot of them, for the most part, use the same way of thinking. In that, the tool picks up the elements you are interacting with and creates a test step out of it based on the type of interaction and the outcome. The difference is all the clever stuff that happens behind the scenes now.

The record and playback that is happening now is not record and playback in any conventional sense. Now, recorded tests are turned in to a model, think of it like a flowchart, which will contain all associated logic for automating through that flowchart.

Let’s take TestCraft for example, their tool will create actions and steps, which will represent a node in our flowchart model, which allow the actions or elements to be reusable. In future tests, you can now drag and drop an action to a previously used element to create a new path through our flowchart model for a new test. If the flow through the UI changes, instead of being stuck and having to create a new test, TestCrafts tool will work out where the broken link is and allow a one-click fix to get the test back up and running. This is often referred to as Smart Locators, and they will often use multiple locators for an element, which allow a test to fall back on alternative locators if the primary one changes or can no longer be found.

It, along with many other tools, can use AI to find elements on a page that it expects to interact with, and automatically determine the object type, creating a list of possible interactions based on its type. On top of this, and probably one of the more impressive aspects of modern codeless tools, is the ability to map its way through your UI journey. This means the speed at which tests can be produced is extremely rapid.

Don’t get me wrong, there are still some very bad tools out there that use the very primitive record and playback approach to create tests, but there are also a large number of very impressive and very appealing tools to use.

So, as someone looking to learn to code and get in to test automation, should you be worried? Is your career going to be over before it even began? Absolutely not. Automation testers that can code will be in demand for a long while yet, at the point in time where this isn’t the case, developers themselves will also be redundant.

Think of these tools as just another tool in your arsenal to build effective and reliable test automation solutions. Depending on your test approach in your project, these tools might allow for an initial test suite to be built to provide some coverage while you code your Selenium tests, on the flipside, these tests maybe used to create a quick to run regression pack that can be run at the click of a button. Or, these tests may simply compliment your existing suite to improve coverage and plug gaps spotted by yourselves working alongside the developers.

And while these tools are called codeless, in the sense that they allow codeless tests to be created, there is a lot more to be had from using these tools if you are able to code or understand the concepts of coding and scripting. Because of that, learning to code, even if your company used a codeless tool exclusively, will only benefit you when using it, and improve the tests you are able to create from using it.

If you are interested in finding out more about some of the tools available, here are a few that I have experienced and can recommend:
– Perfecto Codeless Automation
– TestCraft
– CloudQA