So far, test automation has been synonymous with programming. Why? Because all available test automation frameworks and tools are dictating it.
Most test automation tools are developed with a programming mindset. In much the same way that operating systems required programming before Windows 95 changed the game with their visual interface.
One example is the world’s most popular browser automation framework, Selenium. It is incredibly flexible, and it works with any type of web application, across all browsers on all operating systems. To work with it, though, requires programming.
The problem is, testers are not programmers. Adopting the attitude that testers must learn how to code is problematic. With that mindset, we ignore the fact that coding takes many years of practice to master - just like any other craft. What's more, coding takes time away from testers’ primary function. As mentioned earlier, testers' invaluable skill set lies elsewhere. Nonetheless, “Get on board or get fired” is a prevailing sentiment.
The paradox is obvious: Test automation, which was supposed to free up resources for human testers, brings with it an array of new costly tasks. Yet, test directors and managers are often quick to assume that testers should “just” learn how to cobble some code together. Preferably by copying and pasting existing samples from online repositories. This approach is usually based on the sentiment that "our testers don’t have to become great programmers, they just have to know enough to make automation work.”
So, this faulty attitude to test automation is assuming that automation is a relatively simple task, and it is also blind to reality. Programming includes familiarizing yourself with an enormous amount of technical details and methodologies.
The current paradigm in test automation is inadequate
The first lesson that enterprises often learn as they implement test automation is as following. Although writing good test automation code is hard, it is quite possible to train a group of tech-savvy users, or non-developers, to do it. Even with some success. With various training and a lot of trial and error, a group of skilled testers can begin creating test automation scripts that work in real life. This is usually achievable within 6 months. So far, so good!
However, the initial success comes with some costly realizations.
- When writing automation logic, the tester must reach professional-level experience with a programming language.
- When making a test interact with different systems, the tester must know about things like RegEx, CSS Classes, etc.
- Finally, on top of this, the tester must also be able to manage change. This includes following best coding practices of “modularity”, “re-usability”, and more.
There is no way that a tester can learn all this in a short period of time without compromising their primary task; actual testing. As they make the attempt, the output is often inadequate. The resulting test automation cases are fragile, hard to troubleshoot and reuse, and impossible to update when the software changes.
Figure 1: Examples of factors that testers need to consider when working with programming-based automation.
It’s a common scenario that hundreds, or even thousands, of automation cases are created, and in the beginning, they work great. The cases run smoothly and successfully; green lights everywhere. But then, after a few months, as the software under test changes shape, the cases start failing. After 12 months, half of the green lights have turned red. Not because the automated test cases pick up a lot of bugs that need fixing, but because the cases simply no longer match the software under test.
Because the test cases were built by non-developers, they don't follow the best practices that would make updating the cases easier. No one in the organization knows how to make these improvised test cases work again. The consequence is that they are all scrapped, and a new batch are written from scratch to replace the old.
Figure 2: Code-based test cases fail over time because they can't be maintained.
And so, the first lesson is learned. It is hard to learn how to code test automation from scratch. But it is nearly impossible to manage changes in software without years of professional programming experience.
Introducing codeless test automation
If programming is off the table, then how can enterprises drive value from test automation?
To answer that, let’s take a step back to talk about what a test (automation) case is, as seen from the perspective of the tester.
A test case consists of:
- A name or other unique identifier
- A process that must be followed step-by-step
- A set of input (test data)
- A set of expected results
- A set of pre-requisites before executing the test
All these elements are worth going into details about, but there’s one that is at the core of how we should approach test automation. It has to do with how to describe a step-by-step process?
A test case is really a description of a business process. For example: “Log in to an application and check that the username is properly displayed”. Or “Put items in a shopping basket and check that the total including discount is correctly calculated”.
If you lead people to a whiteboard and ask them to illustrate one of their daily on-screen tasks, chances are that they will do it in one of two ways:
- They list each step of the task as bullet points from top to bottom. Then they realize that this approach is too restrictive because some steps interlink, and this is difficult to show in a bulleted list.
- They draw a flowchart with boxes representing each step or action being performed in the application’s user interface. Actions include clicking on a button, typing in a password, reading the text value from a field, etc.
Figure 3: A simple flowchart illustrating the steps in a common workflow or business process.
Drawing a step-by-step flowchart of user interface actions is an intuitive and flexible way to describe processes. Flowcharts are useful because they allow for branching logic, adding inputs from data sources, and much more.
For this reason, some test automation tools are developed entirely around the concept of visual GUI/UI flowcharts. For example, the LEAPWORK Automation Platform. In fact, there’s an entire industry standard for documenting business processes this way. It's called BPMN (Business Process Model and Notation).
Here’s an example: Testing a login form in a web application. It is simple to sketch out as a flowchart, where each “building block” consists of an action and an element in the application’s interface.
Figure 4: A standard login form.
The following flowchart illustrates what an automated test case would look like. It's a regular login process consisting of the following steps:
- Clicking in an email address field,
- typing an email address,
- repeating the same steps for a password (not illustrated),
- then clicking on the “LOG IN” button,
- and finally, searching for the user’s name to appear on the screen.
Figure 5: A flowchart with each 'building block' representing a step in a test case.
Note that the flowchart is not just a representation of an automated test case, it is a tool for actually activating and executing the test case.
Suddenly, the road to success with test automation seems within reach. An automation tool built on this visual approach empowers non-developers. It enables them to create, maintain, and execute test automation themselves without having to learn how to code.
Learn more about codeless test automation in our guide to reducing risk, lowering costs, and driving value with test automation.