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 and questions are regularly posed on forums around whether you can use test automation tools to achieve the goals of RPA.

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

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 I’ll call “pure” RPA which is to simply replicate a human’s interactions, but makes far more sense when looking to achieve a robust, functional and maintainable solution.

Test Automation

Test automation is the process of automating tests (typically test scripts that consist of a number of 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 may also execute tests at lower levels such as APIs and service based interfaces.

Based on these summaries, there are some clear similarities. These focus around the application “automation” – the interaction with an application’s interface in order 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. The way in which either tool type achieves this is largely the same along with the same challenges to overcome. Both tools types interact with the web based user interfaces, from traditional HTML pages to complex Javascript based frameworks where object identification and synchronisation complexities can occur. Both tool types interact with a range of native Windows client applications, technology/platform specific interfaces and legacy application interfaces. As mentioned earlier, whilst lower level service/API interaction isn’t theoretically “pure” RPA, both tools types also interact with lower level service/API interfaces. Finally, both tool types also have the ability to interact directly with file systems, databases etc in order to achieve their goals.

So, whilst the technology implementation may differ (although there is often a very significant commonality in underlying libraries and methods) between tools and the tools types, the underlying goal is the same – to automate interfaces. This is a reason why there are an increasing number of commercial test automation tool vendors who are in effect “repurposing” this core application automation “engine” of their tools and building it into an RPA wrapper to promote as an additional service line. How successful they are however relate to how much they focus on developing core RPA tool “wrapper” functionality.


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 also extends to how they use data as part of the automation process.

Continuing on this theme, 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 is not always the case however, with most of the larger commercial test automation tools still offering broad technology/platform support which is one of their key selling points.

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 ~15 or so years ago, which 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, an increasing number of 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 seen in the RPA tool market however, as there are a number of 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 test in agile delivery methodologies, with development led creation of automated test tools to support specific requirements and challenges. The security and support barrier to their adoption has largely been 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 much greater concerns around tool support, maintenance and security.

This then leads us to the final area where some similarities but clear differences emerge, relating to 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 auditing and logging, with test automation tools focused more on assertion points and 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.

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. Smaller organisations who are looking for live operational quick wins and efficiencies however 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? Doubtful I suspect, as the large and dedicated RPA tool vendors are far ahead, but this remains to be seen.

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