Is Codeless the future of Test Automation?

Enrique A Decoss

Senior Manager | Quality Strategist | Test Manager | Head of Quality

Published Mar 8, 2020

Fundamentally, the challenge of test automation can be described as; how to articulate a test script (the output of the test analysis process to exercise test cases) in a way that can be interpreted by a machine for execution purposes. Essentially, creating machine-readable test scripts.

Commonly, skilled automation engineers or SDETs are hired who take test scripts and rearticulate them in coded form. Rightly or wrongly automation for most organizations is a translation exercise from human readable form to machine readable form, essentially re-articulating the output from the test analysis process in another form. There are clear efficiencies to be made in this process.

Understanding Codeless Test Automation

Codeless Test Automation can be defined as tests without writing a single piece of code, solving the fundamental knowledge capture problem, empowering test analysts, not conversant with code and software development to deliver test scripts in a machine-readable form, skipping the secondary translation step (Process described above).

The appeal of codeless test automation comes down to cost. The traditional script-to-code process requires duplication of effort, articulating the same information in two forms, one readable by humans, the second translated into a machine-readable form, code. This requires additional resources, if both steps could be combined it lowers the cost considerably. So what options are there?

Heuristic approach: "training everyone to code"

Give the individuals responsible for deriving the test scripts in the first place the ability to directly articulate them in machine readable form, code. The barriers to this approach are obvious. We are adding a third skillset to those of domain expertise and test expertise. Many will have no desire to take that journey or indeed the mindset to do so, it is often said that the skills of a tester and a developer are very different, the combination of the two is still a rare commodity.

We must say that learning to code is only half of the battle, with great power comes great responsibilities, use of Integrated Development Environments (IDEs), build orchestration tools, frameworks, and third-party libraries. Setting up a simple Java Selenium test could require knowledge of numerous components; Eclipse, Maven, TestNG, and Selenium on top of the Java language itself. Extending that to improved reporting with Extent, DB calls with JDBC and data abstraction with Excel with Apache POIs, quickly the learning curve becomes logarithmic!

Numerous solutions to approach this problem have been seen over the years (Since 2005), and yet we still see automation rates as low as 15-20% across many organizations.

Record and Play the solution?

A process whereby a coded test script is created by recording user actions whilst they perform steps manually on an application, directly skipping the translation step.

In reality, there are numerous pitfalls in using record and play; Reliability of recorded scripts, often fragile or incorrect code is produced in this fashion. The code doesn’t incorporate accepted best practices of modularity for maintenance and parameterization for varying test data, also requiring an amendment to incorporate validation actions. Maintenance and code refactoring overheads mean this approach alone rarely scales and projects will resort to direct coding or other more structured approaches.

The resurgence of Codeless Automation Tools

Codeless Automation tools are not new in fact been around for many many years, with Open source libraries the same fundamental script to code translation exercise applies, even more acutely so, as they do not come with any form of so Let’s explore some typical codeless approaches.

Visual Design Trees
Table based Abstraction
Flow Diagrams
Model-Based Test
Visual Programming
Capture-Replay

Multiple approaches to codeless automation. The two most prominent ones involving recording manual tests and playing it back, and creating structured test flow diagrams that are used to run tests.

Conclusion

Codeless testing would be a tool for automation testers to fast track their jobs rather than replace their jobs. In the near future, the tools will become smart enough that they will completely eliminate the need for test script coding, allowing testing instructions to be directly passed on to the system in a complete codeless package. Right now though, automation functional testing is the most important requirement of any agile software development process.

Scripting Testing is still required and we have a lot of test scripts to maintain, but we need to keep looking to the future, Intelligent Testing Era is coming soon and we need to be prepared as Automation Engineers.

Happy Bug hunting!