Among the currently shiny new test automation things are visual “script-less” test automation tools. But the visual test flows are still code – and thus require discipline to structure and maintain. Otherwise you are just adding yet another layer of spaghetti code.
Among the current shiny new test automation tools are visual “script-less” automation tools like LeapWork , Blue Prism  and UiPath . These tools are a part of a new class of business process automation tools called “Robot Process Automation” (RPA) . There are two sub types of – “RPA” which focuses on processing data and Robot Desktop Automation (RDA).
RDA is interesting in the context of test automation , as they can automate GUI interactions – also on top of enterprise package applications (SaaS, COTS, OOTB etc. ). The test automation challenge for most of these enterprise applications (SAP, MS Dynamics  etc.) is that they come with no access to the code-base, even if these are pure-play web based – the GUI is all there is.
All you can to these type of business solutions is usually to add customization and configurations by entering or editing data directly in through the GUI. Some of these systems allow configurations and customization in the form of config-file – they really should be under change control , as they are part of the pipeline.
visual tests are code
part of the ship
part of the crew
Bootstrap Bill Turner
Using RDA tools for test automation  is a novel  uncharted approach . The editing of the “tests”/flows is usually done in a stand-alone application studio (Graphical IDE) with interactions to the solution under test (across the GUI and over Citrix and RDP) and to any test management and issue tracking system.
Interestingly the other more “data processing” RPA tools like Automation Anywhere  uses a VB-Script like syntax. Writing and maintaining “scripts” like that is quite like the common approaches to GUI automation using frameworks like Siluki, tagUI, Applitools .
Applitools etc. are coding frameworks you can apply if you have the application code base or want to write test automation directly as code. There could be benefits in coding UI testing in all web-only projects directly using Selenium and Applitools. Most enterprise business solutions are often stand-alone applications, or their web code is horrible to hook into, as often the selectors seems randomly generated (been-there-done-that).
Hence the primary driver for RDA adoption in for test automation is to take the RDA & RPA  tools and apply their strengths in process automation of enterprise business solutions  to drive the test execution. And of a business flow could be “automating” activities during onboarding  or an SAP purchase order as below images:
Another key driver for adoption of RPA for test automation is their visual approach in presenting interactions/tests as flows. Some do it gracefully and user-friendly (LeapWork) – others have a more old-school workflow/swim lane approach (Blue Prism, UiPath). In both cases the visual flows illustrate an interaction across multiple GUI applications to perform business actions (yes, this still happens).
These drivers probably to make the barrier to entry seem more manageable. The visual ones very easily turn into visual spaghetti code if you don’t keep an eye on it and use sub flows, low coupling and high cohesion . … as with any other non-trivial code (of a certain McCabe complexity ). One interesting way to go about a “coding” practice for visual test cases could be inspired by how BDD can be implemented in LeapWork  with annotation and self-referencing unit tests.
At the end of the day even a visual test automation project is a coding project, that should be part of the project code base like everything else . And probably best maintained by software engineers within the project team (where possible) – unless you want a team of test engineers spending all day playing catch-up to maintain the automation code.
- Since 2017’ish.
- COTS/OOTB = Commercial of the shelf, out of the box
14 thoughts on “Visual Tests are Still Code”
[…] Visual Tests are Still Code – Jesper Ottosen – https://jlottosen.wordpress.com/2019/07/12/visual-tests-are-still-code/ […]
[…] Visual Tests are Still Code Written by: Jesper Ottosen […]
[…] Robot Desktop test automation […]
[…] it is – No matter how it looks at first, it’s always a people problem and even if we have a successful test automation effort – we can still fail to appreciate the experts knowledge and by that fail to solve the […]
[…] Perhaps RPA tools and similar Low-Code tools can be compared to the macros of If This Then That, where you can automate tedious repetitive tasks – also among your business tools. But even with low-code tools the complexity of the scripts can make it a mess, and the visual scripts needing coding practices. […]
[…] bigger the visual flowcharts in your RPA designer the more the project is a coding project. And you need to apply software development practices like version control, BDD style documentation […]
[…] interfaces – or systems without direct ways of building testability and observability. Still visual code is still code – and computer science disciplines […]
[…] The low-code business tools emerge and gain tracking – and enable what Gartner calls the Democratization of Expertise and Mabl calls customer-centric testing. In either case it allows for some digital transformation of business activities, that are not directly reliant on software development activities. Yet the more complicated and complex even the low-code solutions become, the more important it is to maintain and test. .. and that’s where the automation best practises come in. Visual Tests are Still Code […]
[…] matter experts intricate knowledge. We can also see that codified and explicit knowledge ties with codified solutions and industrialized on the right. JitGo has an excellent deep-dive into using appropriate […]
[…] developer trend has provided the end user organisations with the tools to automate on their own (to a certain degree). Not only in test automation but in general – for instance with the automation tools of […]
[…] as low code solutions become more specialized so does the visual code become like classic code – thus needing computer science disciplines like version control, trunk-based development, […]
[…] Visual tests are still code […]
[…] computer science techniques to maintain the RPA and low-code shoe strings. At the end of the day, visual code is still code. And low-code test automation is just part of a bigger […]
TestSigma Community Newsletter #33, june 1, 2023