WavebreakmediaMicro - Fotolia
Will codeless test automation work for you?
Simple and repeatable -- that's the appeal of codeless test automation. But just how useful is it? Find out in which circumstances the method can be most effective.
Software tests don't simply pop out of thin air. In their simplest form, tests require code that sits atop the software but under the test. However, that code is both expensive to script and easily breakable, which requires plenty of rewrites as the software code underneath changes. There is an option that aims to handle these issues.
Codeless test automation, or codeless automated testing, uses lower standards to create software tests, and, in turn, makes it easier for engineers to create and maintain tests. However, the use cases and limits of codeless tools are very particular.
Let's dive deeper into codeless test automation to see if the process can keep these lofty promises, and if it will work for you.
How codeless test automation works
While outsiders view testing as simple and straightforward, it's anything but true. Until as recently as the 1980s, the dominant idea in testing was to do the same thing repeatedly and write down the results. For example, you could type 2+3 onto a calculator and see 5 as a result. With this straightforward, linear test, there are no variables, looping or condition statements. The test is so simple and repeatable, you don't even need a computer to run this test.
This approach is born from thinking akin to codeless test automation: Repeat the same equation and get the same result each time for every build. The two primary methods to perform such testing are the record and playback method, and the command-line test method.
Record and playback tools run in the background and record everything; testers can then play back the recording later. Such tooling can also create certification points, to check the expectation that the answer field will become 5. Record and playbook tools generally require no programming knowledge at all -- they just repeat exactly what the author did.
It's also possible to express tests visually. Command-driven tests work with three elements: the command, any input values and the expected results. Consider this set of tests:
| Command | Input | Expected result |
| click | TextInput1 | |
| type | 2 | |
| click | TextInput2 | |
| type | 3 | |
| click | = | |
| expect | labelResult | 5 |
You could store these in a spreadsheet or any data formatting program. To script these tests, all that's required is knowledge of the list commands and the UI names -- that TextInput1 or labelResult. Firefox, Chrome and other browsers provide tools to learn element names. This kind of training takes minutes, not the months and years needed to learn to program.
Modern tools usually combine approaches. For example, you might record the test and then the tool represents it in a grid in command-line form. Some tools inspect the UI and give a drop-down to select the element or search of a drop-down to select the command.
Codeless test automation limitations and opportunities
With record and playback tests, small things will invariably need a bit of custom code. For example, a banking program might need to calculate when the next business day will be. Most codeless tools provide a back door to write some code, but the language might be something the tester has no experience in -- and something the programmers have no interest in. Some tools simply do not provide a way to write custom code.
Also, like their computer code-driven cousins, record and playback tools start to break when the UI changes. Change the location or name of a button, add a new required field or add a new step in a multi-step workflow, and the tests begin to report false failures.
These false failures either require a new record, or, sometimes require engineers to rethink the way the tests are structured. Record and playback tests are valuable only when something changes, but, when something does change, they might not work. With record and playback tools -- at least in theory -- the re-record is cheap. Sadly, if the test is large, a great deal of work will be needed to identify something as small as a changed UI element.
Another common need is the ability to take code snippets and reuse them as functions. This approach at least reduces maintenance, so that when something changes, it only needs to be "fixed" in a single place -- such as adding a new holiday to a next-business-day check or an extra step in authentication.
Consider, for example, a test that creates a new order, takes note of the orderID, then searches for that orderID to get details. A human can do that with a slip of paper, or a computer program could do it by looking at the text on the screen and matching patterns for the nine-digit code that appears between two known terms. Some codeless tools provide a way to get this kind of information; others do not.
Codeless test tools mimic some of the operation of a human tester, but they cannot learn, observe or change strategy in real time.
Who will benefit from codeless test automation?
Technical staff members who want to write code will likely refuse to even consider codeless tools, but testers who investigate without code -- such as customers -- may find the idea appealing. Technical teams should give the tools to the people who use them to experiment.
Give them a non-trivial test task and let them get stuck and figure their way out. Give them time to not only have the initial reaction, but also time to see if that reaction potentially changes over the long term. Try recording a test for the current state before a development team changes a feature, then figure out the workflow for what to do when a test fails because the underlying software does something different. See how well things will work between developers and testers.
