Any good experience with record&playback codeless automation tools?

Hi everyone,

I’m exploring the huge quantity of automation tools based on record&playback/ codeless automation tools.
They are very interesting they are supposed to give the opportunity to build an automation framework in very few hours.

I have tried many tools and almost all of them can record correctly basic tests. However, when you try to record more complex web pages actions they don’t record very well.

For instance I’m trying to automate actions like filling this form that I created for this purpose : https://freeonlinesurveys.com/s/OuQOi01Q#/0

Well, even if you try to automate a test in this page directly in Selenium with Java it would be still not very easy…

Do you have any good feedbacks where codeless tools are working well in your company since a couple of years ?

3 Likes

I’m not a big fan of such tools myself, but I do admit that they can have their usefulness, if your SUT is not very large or too complex. When I was just learning Selenium I used the Selenium IDE browser plugin to record tests, then I’d export the test and check the code, after that I was trying to improve the test code by seeing how I can refactor it.

If you have access to the source code, work with the devs - or at least use the language of the devs :).

For SaaS there is a range of low code tools, that have recording features to get you started. But yes, as the solution growns proper coding features are indeed needed. :wink: like the 24 Key Capabilities To Drive Improvement In Software Delivery.

Perhaps Microsoft Power Automate could be a good fit for you?

1 Like

No they are all awful. They always have been and always will be. Don’t get sucked in by the marketing hype. I looked at the market again myself recently and the AI and self healing is still just hype.

For web stick with selenium, cypress or pupetter family of tools and hire good engineers, if you don’t have the skills in house.

The commercial tools are targeting enterprise companies which big wallets and low skills. You don’t want to be one of those guys. There is no independent reports of those approaches leading to any kind of successful outcomes. All the evidence is in favour Devs we writing automated tests possibly optionally with support from sdet.

I am encouraged, by folk like @enrico_gua signing up and asking such brilliant questions. I’m also keen to try make only one single point in every conversation, this post is my opinion, my experience, not fact. The world is full of “solutions”, and really not “solution” is 100% correct. My good experiences have been short, very helpful, but just short.

“No code” testing tools have their place, but depending on them in a mission critical product is not one of those places. Saying they are bad is probably a strong statement which would undermine a lot of the conversation around testing being about exploration and discovering actual true unbiased facts.

Some codeless tools recording workings can often teach you more about your app that you did not know.
They are a brilliant stepping stone. But “trying to use one as as bridge”, is sometimes like delivering chickens in the back of a Ferrari instead of in a truck.

1 Like

Thank you for your post that allowed me to discover your interesting blog.
Well, about Microsoft Power Automate it will depend on the software that I’m supposed to test/automate, maybe it could be enough. And as you said, “as the solution grows proper coding features are indeed needed” :smiley:
Anyway, thank you, I had never heard before.

2 Likes

I think it’s true for most of the codeless tools, but maybe some of them could be enough for many companies where the product’s UI is very simple and QA teams have low coding skills.

I have done many POCs with codeless tools and many were awful : sometimes you need to do loops and you can’t, some tools has this loop feature but it’s even harder than doing directly in Java, things are not recorded properly… my conclusion was that the idea of creating automated tests quickly and be able to scale is great, but if the tool is not extremely good you should give up asap. Unfortunately, very few of them are good enough.

1 Like

I’ve been using a codeless tool for about 3 years now, I’ve got pretty used to using it over that time. I don’t generally use the record and playback functions of it, however, I had a go on the site you linked to. I had two issues:

  1. I didn’t notice that I could type my score on number 3, so the slider didn’t work, there is an option to drag the mouse, but typing is easier.
  2. The combobox is weird and non-standard, I have to open it and pick the item from the list. This is instead of using the inbuilt control.

We use our tool to automate regression on large corporate systems such as Oracle Fusion and Banner - a student records system - I had something run earlier in the year to support a new curriculum build, it ran for over a hundred hours. With these systems if your strategy to define the elements and tags is sound you can create very reliable automation that’s never needed self healing and AI.

3 Likes

I’m building one of these no-code testing tools and have experimented with a ‘recorder’ and it’s extremely nuanced and difficult to record actions accurately and successful implementation really depends on your app having well structured markup with unique elements and well labelled attributes for targeting.

Many people uses themes and kits which don’t have this, so it’s hit or miss whether the recorder will work.

Because of this, I’ve settled on a UI builder instead and will probably eventually have a hybird model where you can use the recorder to get the initial steps down and then fine tune them later, but I’m finding users prefer to just build the tests manually using a flow-chart style UI.

1 Like

I think this is true, in my instance I don’t trust what the recorder captures, so I always check and change it. The other thing about the recorder is it’s just duplicating elements. An input field is an input field, there’s something unique about it and something that’s least likely to change , so you need to parameterise that uniqueness and use the ID or class or name or type.

Joe Colantonio (very popular in our field) just released an interview with a QA using one of those codeless automation tools (in this case Testim) :

1 Like