Test automation is a well-established practice to improve the software delivery cycle. But it’s not easy. Will the advent of codeless automation tools make testing quicker or more cost-effective?

On my bedside table at the moment lies Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. The authors Nicole Forsgren, Jez Humble and Gene Kim do a great job of explaining how greater delivery speed provides greater quality. This is great. But what I want to know is this: how does testing keep pace with agile and DevOps?

For many, the answer to this question is test automation. We have seen the rise of Selenium and Appium to drive web and mobile applications under test, as well as the development of frameworks around these, such as Robot.

meeting-03-inpage

In the hands of the right person, these are powerful tools. But who is the right person? In my experience, it’s somebody with extensive knowledge of testing, who knows how to write good tests. That’s a given. This person also has the communication skills to interact with the Business Analyst and Software Developer. Open dialogue is so important for understanding and articulating the necessary requirements and how they are going to be tested. Finally, the right person will have the ability to translate test cases into high-quality code that can be used to build reliable, repeatable and maintainable test suites.

It’s hard. I’ve worked with teams for many years to educate and enable them to write test cases in this manner. The work is time-consuming. Not everyone has the aptitude to master all of these skills at the pace required in modern software development.

Help is at hand

There is a new breed of tools (and updates of the old guard as well) that promise to lower the programming knowledge required to create reliable, repeatable and maintainable automated test suites. These tools are often referred to as codeless or scriptless automation tools (although I’m not very comfortable with the term scriptless, as they are used to write test scripts).

What I really like about these tools is that the test scripts are written in a natural language rather than computer code or pseudo code. The tester is free to focus on understanding the requirement and writing good test cases. They can let the tool take care of how the application under test is manipulated to input the data, do the actions and validate the responses.

man-using-digital-diagrams-inpage

What else does it offer? There’s lower maintenance (the annoying bit everyone tries to forget about in test automation). You get auto-generation of flows and visual checks on pages too. All these benefits will lower the technical skills required to automate testing – and speed up the process of testing for a faster return. For companies using low code to accelerate software development, then codeless test automation is a natural bed fellow.

Codeless is a very active area of development. The tools I have looked at are very impressive in their capability. I still need to write some code or locators at times, but I would put this down to the application under test more than the automation tool.

Some applications or parts of them are just hard to automate no matter what tool you use. Think of those dynamic IDs embedded deep in an XPath or CSS with no reference point that you had to locate in the past. Don’t be too critical when the codeless tool has difficulty too.

Easy does it

I have found that I need to adjust how I approach test automation. Some of the ways of working I have taught for more traditional code-based tools are less relevant. For example, there’s no need to create a module for logins when it’s as simple as:

  • Enter “myname” in the username field
  • Enter “mypassword” in the password field
  • Click enter

And without the need to create or maintain locators for any of the fields in question, it’s just so much simpler to write robust suites of test.

A while ago, I was in a meeting where the head of development stated: ‘test automation is easy!’. Heads turned towards me, expecting a sharp rebuttal. I could only nod in agreement. After all, creating an automated test is easy. The tricky bit is creating a robust, reliable, maintainable test suite. That’s where most automation projects fall down.

The same challenge is open to codeless automation tools. Do they scale up from simple scripts to complex test suites? In truth, I don’t yet know. Time will tell. So far, I’ve only scaled them up to moderate-size test suites. But the signs are promising. To date, I haven’t seen any issues with more complex scenarios.

abi blog

Watch this space. As I use these tools on more complex scenarios and push their limits, I’ll let you know what I find. In the meantime, I would encourage you to look at these tools and see where they can add value to your projects.

Or why not phone a friend? At Expleo, we have an awesome test automation team who can help your enterprise will all your test automation efforts. You can visit our Test Automation page to discover how Expleo is helping a range of forward thinking, agile organisations to drive change through intelligence led test automation.

ASG is Expleo’s Advanced Solutions Group. Stay tuned for more blogs in this series as we delve further in to what Expleo’s ASG is all about.

Gordon Flower, Solutions Director of Advanced Solutions Group at Expleo, is a seasoned professional with a demonstrated history of working in the information technology and services industry. Gordon specialises in building the next generation of platforms and services for quality software delivery.