Fundamentally, the challenge of test automation is articulating a test script (the output of the test analysis process to exercise test cases) in a way that a machine can interpret for execution purposes, essentially creating machine-readable test scripts.
Commonly, skilled automation engineers or SDETs are hired to rearticulate test scripts in coded form. 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 apparent efficiencies to implement in this process.
Understanding Codeless Test Automation
Codeless / Low-code Test Automation is just what it sounds like: tests without writing a single piece of code. Codeless tests solve the fundamental knowledge capture problem, empower test analysts, are not conversant with code and software development to deliver test scripts in a machine-readable form, and skip the secondary translation step entirely.
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 or code. The codeless methods require additional resources, but if the traditional approach and codeless approach combine, it considerably lowers the cost.
Heuristic Approach: “Training Everyone to Code”
Give the individuals responsible for deriving the test scripts the ability to articulate them in machine-readable form, code. The barriers to this approach are apparent. With codeless testing, we are adding a third skillset to domain expertise and test expertise. Many will have no desire to take that journey or 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 a rare commodity.
We must say that learning to code is only half of the battle. With great power comes significant responsibilities: use of Integrated Development Environments (IDEs), build orchestration tools, frameworks, and third-party libraries. Setting up a simple Java Selenium test requires 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 proposed over the years (Since 2005), and yet we still see automation rates as low as 15-20% across many organizations.
Record and Replay the Solution?
Record and Replay is a process whereby a coded test script is created by recording user actions while they perform steps manually on an application, directly skipping the translation step.
In reality, there are numerous pitfalls in using record and play. The reliability of recorded scripts is poor. Fragile or incorrect code is often produced in this fashion. The code doesn’t incorporate accepted best practices of modularity for maintenance and parameterization for varying test data. Maintenance and code refactoring overheads mean this approach alone rarely scales, and projects will resort to direct coding or other more structured methods.
The Resurgence of Codeless Test Automation Tools
Codeless testing tools are not new. In fact, they’ve been around for many years. Open-source libraries, the same fundamental script-to-code translation exercise, apply even more acutely, as they do not come in any form, so let’s explore some typical Codeless / Low-Code 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 include manual record and replay and creating structured test flow diagrams used to run tests.
Final Thoughts
Codeless testing is not a replacement for automation testers but a tool to help them become better at their jobs. The tools will soon become smart enough to eliminate the need for test script coding, allowing testing instructions to be directly passed on to the system in an entirely codeless package. However, functional automation testing is the most crucial 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, the Era of Intelligent Testing is coming soon, and we need to be prepared as automation Engineers.
Happy Bug Hunting.
