Robotic Process Automation: Pros and Cons

What is Robotic Process Automation (RPA) and why should I care about it?

If you’ve been following the software testing market you may have heard of Robotic Process Automation (RPA). This is a technique for interacting with applications, be they for web, desktop, or mobile, while writing no or minimal code to specify those interactions. While RPA can be used to automate any business process (e.g., populating a list of data into the same form), it is often used for test automation, as it is promoted as allowing testers without automation experience to quickly start automating test cases. Popular RPA tools include LeapWork, UiPath, Automation Anywhere, Automic Automation, and Tricentis Tosca.

During my time as a test automation engineer I have written the code for implementing test scripts as opposed to using RPA tools. However, my current client, as part of their Agile/DevSecOps transformation, would like to introduce automation to help testing keep pace with development and has chosen to implement their scripts using UiPath. I haven’t used RPA tools extensively, but based on my experience with creating simple scripts using UiPath and Automation Anywhere it appears that tests are specified by dragging and dropping actions to take against the system under test into a directed graph that represents how a test should be executed.

Break it down for me — what are the trade-offs of this approach?

While there is a lot of marketing hype around RPA, it is important to take an objective (as possible) look at both its pros and cons to understand whether it is right for you:

Pros of Robotic Process Automation (RPA)

1. It is possible to automate a test case or test case setup or cleanup tasks without knowing how to write code.
2. An organization most likely won’t need to change anything about the way in which their application is built to use RPA. In contrast, when using tools like Selenium to automate interactions with web applications, it is often necessary, or at least advisable, to add unique IDs to the DOM of the application under test.
3. Some RPA tools allow tests to be scheduled, which can support running a nightly regression test that many organizations use to monitor their applications.

Cons of Robotic Process Automation (RPA)

1. While testers may not need to know how to write code to use an RPA tool, there is still a learning curve that must be considered.
2. While it is possible to specify traditional locators, the fact that image-based comparison is easy to use may encourage the creation of less stable tests.
3. Not every RPA tool may be suitable for test automation — make sure that test cases and assertions are supported by any tools that you are considering.

I want your opinion — should I use an RPA tool?

I think that RPA tools can be useful, but they may not be suitable for every environment, either for automating business processes more generally or specifically for implementing automated tests.

If you have the ability to access the layers of an application that are below the UI, I would recommend focusing your testing efforts there first. By adhering to the agile testing pyramid you will reduce the long-term cost of testing an application in terms of test authoring, execution, and maintenance. Even if these lower levels of the application aren’t currently exposed, you should explore how much work (or how many political battles) it will take to expose them. Interacting with these lower levels of the application will likely be more cost effective when RPA is being considered for automating business processes as well.

However, if you really cannot access any layers below the UI level to automate a business process, or if you need a tool for testing at the UI level, an RPA solution may be appropriate.

I hope to learn more about RPA during my current project and may publish another post where I refine my thinking. In the meantime, please let me know when you think it is appropriate to use an RPA solution in the comments.