RPA vs Test Automation – Are They Really So Similar?

There is a lot of discussion around the similarities between robotic process automation tools (RPA) and test automation tools. Questions are regularly posed on forums around whether you can use test automation tools to achieve the goals of RPA. Others boil everything down to a simple proposition: RPA vs test automation, which is best?

There are many different elements to the answer to this and other RPA questions. To start, let’s quickly summarise the key purposes of RPA and test automation.

What is RPA?

Simply put, RPA software automates repetitive, rules-based processes by interacting with applications just as a human would.

RPA software robots (‘bots’) can fill in forms, open email attachments, enter and re-key data, and perform similar tasks that mimic human interaction. RPA software therefore typically interacts with an application’s user interface but there are increasing implementations that interact at lower API/service levels to achieve greater stability and speed. This latter approach is a divergence from what some people call ‘pure’ RPA, which is to simply replicate a human’s interactions.

Learn more about Ten10’s RPA consultancy here

What is test automation?

Test automation is the process of automating tests (typically test scripts that consist of several steps) that would otherwise be completed manually by a human user as part of the process of software testing.

Depending on the technology and architecture of the system being tested along with the phase in the development process, the test automation software may interact with an application’s user interface as a human would, but it may also execute tests at lower levels such as APIs and service-based interfaces.

Learn more about Ten10’s Test Automation consultancy here

RPA vs test automation: similarities

Based on the above summaries, there are some clear similarities. These focus around the application “automation” – the interaction with an application’s interface to execute operations, be these tests in a functional test script or the replication of a human’s interactions with an application to execute a business process.

There are also some clear similarities in the way in which the two tool types use methods to break the automation process down and modularise into separate units, functions and components to promote efficiencies, maintenance and re-use (ie standard “coding” best practice) and to combine these to execute test or business process steps. This extends to how they use data as part of the automation process.

How both tool types achieve this automation is largely the same and they overcome the same challenges. Both tool types interact with web-based user interfaces, from traditional HTML pages to complex JavaScript-based frameworks where object identification and synchronisation complexities can occur. Both tool types also interact with a range of native Windows client applications, technology/platform-specific interfaces, and legacy application interfaces.

Whilst the technology implementation may differ, there is often a very significant commonality in underlying libraries and methods between tools and the tool types. After all, the underlying goal of both of them is the same – to automate interfaces. This is a reason why an increasing number of commercial test automation tool vendors, in effect, ‘repurpose’ this core application automation ‘engine’ of their tools and build it into an RPA wrapper to promote as an additional service line. How successful they are depends on how much they focus on developing core RPA tool ‘wrapper’ functionality.

Both tool types also interact with lower-level service/API interfaces (although, as mentioned earlier, some people don’t consider lower-level service and APR interfaces ‘pure’ uses of RPA). Finally, both tool types also can interact directly with file systems and databases to achieve their goals.

RPA vs test automation: differences

If we look at typical and common RPA tools versus test automation tools, clear differences emerge. RPA tools are typically ‘one-stop shops’ in terms of the technology/platform support that they can automate (albeit often via an extension and plugin ecosystem), whereas test automation tools (particularly open-source ones such as Selenium) are often technology/platform-specific.

This leads to a key point around market maturity across the two tool types. The current RPA tool market is in many ways reflective of the test automation tool market roughly 15 years ago. Back then, the market was dominated by a small number of commercial vendors who aimed to offer a broad range of technology/platform support to make their tool an all-encompassing choice. As the automation tool market grew and matured, more open-source tools emerged (and continue to emerge), typically specific to certain platforms and technologies.

It remains to be seen if this trend will be reflected in the RPA tool market because there are differences in both the drivers and barriers. For example, you could argue that open-source test automation tools are, in part, the result of a convergence of development and testing in agile delivery methodologies, with the development-led creation of automated test tools to support specific requirements and challenges. The security and support barrier to their adoption has been largely overcome by large user communities and confidence in the tool development. RPA tools, on the other hand, are more akin to a business application rather than an element of a development and delivery process and therefore may not be subject to the same drivers for open-source development. Add to this the fact that they are embedded in an organisation’s live operational environment, which leads to potentially greater concerns around tool support, maintenance and security.

This leads us to the final area where clear differences between RPA and test automation emerge: the overarching purpose and goal of the tool types. RPA tools are focused more on combining automated steps into workflows and business processes. Test automation tools are focused on combining test steps and related assertions (the ‘testable’ logic) into a wider test script as the basis of a functional test. RPA tools will therefore typically have differing functionality around errors, exception queues and decision points along with auditing and logging. Test automation tools are typically focused more on assertion points, reporting test outcomes and capturing failure information to assist with further analysis.

This then extends to key differences around how RPA processes and automated tests are executed, orchestrated, monitored and analysed. Attended RPA (automation that assists and accelerates human application interaction) also represents a key area where the purpose of the application automation is clearly different.

Conclusions

So, can you use test automation tools to achieve the goals of RPA? Is there a case for repurposing test automation assets for live operational process automation? Based on where the market is now and the fact that it is dominated by dedicated RPA tool vendors, the answer will generally be ‘no’ in the case of robust, enterprise RPA tool implementations. However, smaller organisations who are looking for live operational quick wins and efficiencies will undoubtedly continue to see some opportunities here.

Will the evolution of commercial test tools into the RPA market change this to allow a seamless sharing of assets across test automation and RPA? Things look doubtful, as the large and dedicated RPA tool vendors are far ahead.

Will there be an increasing ecosystem of open-source RPA tools and components that are adopted by enterprises? Watch this space.