By taking a look at how Robotics Process Automation (RPA) is defined, we find obvious similarities with the concept of visual GUI / UI test automation.
Comparing RPA and test automation
In their market guide for RPA, Gartner uses this definition:
|
Robotic process automation (RPA) tools perform "if, then, else" statements on structured data, typically using a combination of user interface (UI) interactions, or by connecting to APIs to drive client servers, mainframes, or HTML code. An RPA tool operates by mapping a process in the RPA tool language for the software "robot" to follow, with run-time allocated to execute the script by a control dashboard. |
This definition reveals that the two domains are identical on a technical level with only a few minor differences.
Both disciplines are about automating processes that:
- are boring and repetitive;
- cost too much to scale up, and;
- have a high risk of human error.
Similarities between RPA and test automation
Both test automation and RPA are done by finding and clicking on buttons and other user interface elements on-screen and/or by calling APIs and integrating data sources.
|
Test Automation |
Robotic Process Automation (RPA) |
|
Repetitive, boring tasks |
Repetitive, boring tasks |
|
High risk of human error |
High risk of human error |
|
Bandwidth is limited |
Bandwidth is limited |
|
Structured, rule-based flows |
Structured, rule-based flows |
|
Driven by test data |
Driven by production data |
|
Atomic scope; flows are independent and self-contained (in theory!)* |
Holistic scope; Flows move across applications and functions and order matters* |
Comparing the characteristics of test automation and RPA.
*The apparent difference between this last characteristic is more theoretical and actual. In theory, test cases should be atomic in scope, i.e. each single case can run on its own without being dependent on other cases, and the order in which cases are run should not matter.
In the real world however, testers usually take a more pragmatic approach to the atomic ideal. In practice, it's makes sense to run some tests before others; making each case completely self-contained would usually require writing a lot of logic. It is also common for automated tests to go across applications and to be more complex than the atomic approach dictates.
So, in this regard too, test automation and RPA are similar in the way they are executed in practice: Flows move across applications and functions, and it matters in which order the individual cases are run.
Differences between RPA and test automation
A significant difference between test automation and RPA is that test automation lives in the context of test environments and use test data (often masked or “washed” production data), while RPA obviously works on live business data in production environments.
For this reason, there is a natural focus in RPA tools to keep track of all changes made by users and track everything the RPA “robots” have done. Complete audit trails of absolutely everything is crucial.
Most test automation tools are not suitable for RPA because they lack enterprise features for governance, change tracking, and audit trails. On the other hand, RPA projects are often kick-started with a test automation tools because they offer a pragmatic way to realize business-related automation potential.
For long-term strategic reasons, when choosing an automation platform, it makes sense to pick one that isn’t “just” made for test automation. Instead think of process automation more broadly, and research tools that can be used across the enterprise.
Read the LEAPWORK guide to reducing risk, lowering costs, and driving value with test automation.
