For RPA to succeed …

TLDR: For RPA tools to succeed for automation you need to add engineering practices.

BTW: All automation projects require good software engineering practices.

Yes, you can use RPA tools to do test automation. And yes, you can have business persons designing the flows. BUT in order to succeed you need to apply some software engineering practices.

Robot Process Automation (RPA) tools like tools like LeapWork , Blue Prism  and UiPath  can be used to build business automation – it’s their core job. It’s the enterprise version of the Apple iOS shortcuts, “If This, Then That” or home automation. And they can be used for test automation – in some contexts.

The RPA tools are interesting because they seem to have a low barrier of entry. Some let you design the flows and robots visually, others using flowcharts. Either way it’s a low-code way of developing solutions. It seems compelling to let business end users prepare the flows and bots, it’s all plug & play.

Until it’s not.

Until the RPA robots design is only kept in the head of one person or until the flows/bots is a mess of interdependencies and cross links, that somehow the business still relies heavily on. And you have yet again created a spaghetti solution to add to the pile…

via DevHumor

The 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 and designing solutions loosely coupled and highly cohesive.

Sometimes you can teach the people the details, sometimes you can have a guide (tool smith) to enable them – sometimes it’s best to let the engineers tackle the automation. That depends on your gameplay and map of the world. What end users are good at is intrinsic domain knowledge the novel and the uncharted – not coding nor town planning.

Loosely coupled and highly cohesive.

The terms loosely coupled and highly cohesive is from the world of Computer Science, and most examples are around coding in object oriented languages like Java. In java, and in the flowcharts and visual scripts of RPA tools, you can group things into reusable “building bricks” or functions or sub flows. The Computer Science word for this is encapsulation.

It turns out it’s important how you group the bricks, and what the inputs and outputs are. Vladimir Khorikov summarizes with the following (my emphasis):

• Cohesion represents the degree to which a part of a code base forms a logically single, atomic unit.
• Coupling represents the degree to which a single unit is independent from others.
• It’s impossible to achieve full decoupling without damaging cohesion, and vise versa.
• Try to adhere to the “high cohesion and low coupling” guideline on all levels of your code base.
• Don’t fall into the trap of destructive decoupling.

Without good engineering practices any automation initiative is, at best, just a smartass expensive one trick pony.

No Code, No Test?

If the testing activity can be integrated into the coding activity, who tests if there is no code involved? Does there have to be code in order for there to be a test activity – and when does the scale tip for testing to happen?

There is a new type of business applications emerging – the “Low Code / No Code” products. The WordPress platform like this one I’m writing from now could be one example. AirTable could be another example of a higher order solution, that enables some user to quickly and without code organize and automate information. What we see in the testing tools space with Cypress and Mabl, is similarly a trend, where the test cases and scripts are directly linked to the end-2-end business purpose, not the underlying technologies. Low Code tools has emerged as yet another type of “customization” and “configuration” business solution.

Evolution line and groups of products (Wardley Maps X-axis)

The trend is clear and has been on the horizon for a while.

Low-Code/No-Code will disrupt this entire pattern, as enterprises realize they can be even more successful with their digital transformations if they do away with hand-coding altogether, adopting Low-Code/No-Code across their organizations instead. “No-Code is here, and it doesn’t care about making your IT organization more efficient,” explains E. Scott Menter, Chief Strategy Officer at BP Logix. “Its only purpose is to turn your business into a digitally integrated, audit-defying, silo-resistant object of their customers’ desire.”

The Low-Code/No-Code Movement: More Disruptive Than You Realize

If a consultant can automate their unique process into a tool in hours, they can solve customer’s problem faster and show the value of their efforts. If a small business owner can build an app for their needs, they can increase business efficiency with automation and save valuable time to expand their business.

No-code Revolution. Why Now?

Wardley Mapping y-axis: User proximity / Code needed

To me there is a direct correlation between amounts of code required and business needs and end user visibility. The less “scripting” a business end user needs to do and “scripting languages” to understand the better. Airtable, as mentioned above, wins over spreadsheets in the end.

Similarly the faster cycles and feedback of Low Code tools is more attractive to the business than having “code high” teams develop applications. The “slow and high” code projects are never realized.

Wardley map: Low code evolves and outmaneuvers “high code”

One way to see this trends, is that while “Robot Framework” and other web-based open source “RPA like” frameworks exist, the emerging approach for testing standard software solutions trends towards Low Code:

• Automating Complex End-to-End Tests (SalesForce / Testim)
• What to look for in a SAP test automation tool (SAP / LeapWork)

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.

Similarly, the need for explicit testing of the business functionality emerges at some point in the evolution of the “low code” solutions. Every solution moves from Experiment to emerging practice and end as a standard/best-practice. The explicit testing need emerges along the way but becomes less visible on the left-side products/commodities.

Yet to me – testing happens everywhere. Testing is key to the experiments of the pioneer, testing is key for the settler bundling solutions and testing is key for the town planner to secure stable operations.

Simple illustration of the Pioneers, Settlers & Town Planners Model.

Be aware that while testing is happening, it is not necessary by the tester. Don’t hawk the testing activity, let the experts play their part , have testers for the remaining exploration and have tools for the rest. The trend of less testers and more testing is still active and testing is shifting to the future even faster these days. A test happens every time a person doing something thinks and ask questions like: let me try this, could you test this, what happens if?

There doesn’t have to be code for testing to happen.