This month, NelsonHall will publish its annual software testing services report, focusing this time on digital testing, DevOps, and agile testing services. The main areas of the study include:

• Mobile testing
• UX testing, which is quickly expanding from its regulation-led accessibility testing offering to usability testing
• DevOps/continuous testing, which reflects investment in testing service automation across the software development lifecycle (SDLC), and around CI/CD, and application release automation
• AI, which has found its way into software testing services based on the need for creating intelligence out of data found in defection management tools, ITSM software, and production logs.

Much less of a feature is robotic process automation (RPA). Out of 23 software testing services vendors we talked to, none is deploying RPA to automate its testing delivery processes. And why should they? Software testing services have not waited for RPA to emerge in order to invest in functional testing automation: there is an abundance of software products, open source software, and proprietary technical accelerators already available. However, while testing services vendors may not be deploying RPA internally, they are looking at RPA software as the next opportunity.

There are several similarities between testing service and RPA. First, testing and RPA software share several characteristics: most software tools rely on the same user interface (UI) as RPA software tools do, and are based on scripts (i.e. telling the RPA or testing software what to automate). Testing services vendors are therefore realizing that RPA and software have a different purpose (business process automation vs. testing automation) but are relatively similar tools to deploy.

Second, RPA implementations need to be tested. There are two sides to it: proceed to business process testing (making the RPA-enabled business process work), which is common testing activity. There is also the question of output testing. Let’s take an example: automating a business process such as data entry from an invoice requires testing not only that the process activity is indeed taking place, but also that the output, the data in the system, is consistent with the input found in the initial invoice. Again, this is a common challenge that testing is used to addressing, for instance for testing data as part of data transformation projects.

Third, and final, there is the question of scale. Assuming RPA truly becomes a scale phenomenon, the number of RPA scripts will inflate. If so, the topic of RPA scripts maintenance will surface. In software testing, large enterprises have created literally thousands of test cases and scripts over the years, to bring test automation to a high level of coverage. This wealth of test cases and test scripts brings challenges, such as identifying the purpose and relevance of each test case.

There is another element: each new release of an application may or may not impact test scripts. Buy-side organizations will face the same challenges around RPA scripts. This is where software testing services, with their statistical approaches (pair-wise and CBT), and their ML investments will be able to help, with some adaption of their tools.

This is only the beginning. Only 25% of the vendors we interviewed for this study talked about their RPA expansion plans. And there is an element of vendor organizational complexity, with RPA and testing services being provided by different organizations. Yet, assuming RPA is a long-lasting phenomenon, NelsonHall predicts that RPA will benefit from testing services’ best practices and experience.