Automation is for Other Roles Too

Automation of business tasks is no longer for the software developers only. Similarly test automation is no longer for testers and test engineers only. Both these trends help to create smarter testing performed by non-testers.

As discussed in “No Code, No Test?” and in posts before that, automation tools like IFTT, Airtable and other tools are emerging to enable not only private end-users but also enterprise end-users to do business automation. As an example it’s being actively discussed among the local administrative hospital staff how to apply RPA for data entry and data updates.

I know RPA/low-code implementation is often a symptom of an underlying problem with system integration on one side, and poor process for system optimization on the other. That’s just the way it is, not all systems in the world are based on state-of-the art microservices or processes. It’s a mess of things and your mileage will vary.

XKCD 2347: Dependency

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

Similarly for Test Automation.

Low-code automation are not primarily for the testers and test engineers. If your team has access to the source code – you can follow the modern testing principles and build in Observability in (https://charity.wtf/) and a lot of the things in the code (from: When to use RPA in testing). That’s so much talk of the town, that it should be considered a best-practise (in the Wardley sense ;).

To me the best case for low-code testing tools (Mabl, TestProject, Testim, Leapwork et.al) is to apply it in all the other situations. Co-create smarter testing performed by non-testers and non-developers. Give it to the business people involved in testing SAP or ServiceNow, give it to the supporters using ITSM or similar ticket tracking solutions – give it to all the subject matter experts (SME) involved in the testing. But! Don’t let them sink on it, train them, support them. Let them build confidence on the tool slowly – after all they are not testers.

Where do everyone fit in? The testers jobs will be to explore and to train/enable the experts. I see more testers and test coaches being in the Enabling team – while the SME’s are the key persons in the Stream-aligned team – especially if the tools available to the SME’s are low-code. Have tool smiths (Test engineers) at the ready with building blocks of reusable components, automation best practices and coding snippets (Complicated Subsystem team).

Smarter Coding for the Business