In this instalment of the RPA Implementation Lifecycle series, switching our focus to the Testing phase, we will discuss about Functional testing approaches that can be applied in RPA implementation projects and implications to those due to the low-code nature of RPA-
RPA as Low Code Development
Low code development approaches are meant to minimise the amount of coding needed to develop a piece of software. RPA is a low code technology which is aimed towards business users or citizen developers so they can build software robots using a workflow-driven visually aided approach. The key drivers that have led to the adoption of this approach are the reduced complexity, faster time to live and lower implementation cost of such projects, allowing business users to achieve meaningful value-add in the form of efficiency gains in the short-term as themselves than waiting on IT teams to carry out full-blown implementations. But what still become significant issues with such a low code approach to automation are the resilience and scalability of such implementations.
Functional Testing of Low Code RPA Robots
While Low code approach reduces the development time and complexity to allow business users to build software robots, it does not mean the same for the functional testing efforts needed for RPA implementations. This is especially the case because RPA as a technology is heavily reliant on UI automation, and which requires high-level of maintenance effort due to frequent UI screens or object changes in the applications that the RPA robots operate upon. In fact, this means more testing effort is needed over time as Software robots undergo changes frequently.
When you look at how testing now gets conducted in most good code agile development projects, a testing pyramid based automated testing approach is employed to allow continuous integration and continuous delivery of software. In order to speed up iterative software development, the testing pyramid suggests developing different levels of automated tests, i.e. Unit, Integration, and Acceptance tests, but crucially, the testing pyramid suggests developing more automated tests at the bottom of the pyramid, an example would be for unit testing, and as little automated UI tests as possible at the top of the pyramid i.e. acceptance tests. The very reasons for doing this is to do with the robustness, development cost and the time taken to execute these different categories of automated tests.
But when it comes to low-code development, testing pyramid approach to automated testing does not necessarily apply. The simple reason being there is truly little actual units of code that gets written in a low code development approach. Most drag and drop components come as pre-built as part of the RPA platform and their source code may not be visible to the users. As such, the level of unit testing needed, to verify that the code meets the desired standards & specifications, has been is extremely limited unless there are any custom components being developed and packaged as good code by an adopting firm as part of their RPA implementation efforts. Any such components would need specific unit testing. But in case the custom components developed are again built using the low-code approach provided by the RPA platform itself. For example, recorder-based UI automation, where there isn’t a pure unit of code produced but a visual workflow or a meta-language script, it won’t lend itself to automated unit testing.
The other key reason why a testing pyramid approach to automated testing won’t apply, in the case low code RPA implementations, is to do with the very nature of RPA technology to use UI automation itself as the fundamental mechanism to develop low-code software robots. As such, given UI automation can be brittle in nature and expensive to maintain, it makes little sense to develop automated UI acceptance tests for system testing of RPA robots if the robots are themselves been developed as automated UI scripts. This won’t meet the acceptance testing needs of RPA robots, having to validate the robots against expected requirements, and will rather amplify the maintenance effort needed for UI automation if the actual robot and the tests rely upon the same technical configuration pertaining to the UI objects.
From an integration testing perspective, given the low code nature of the RPA technology, and that RPA can cut across multiple application technologies to predominantly use their UI interfaces then APIs to develop integration scripts for moving data amongst these applications, there is limited need API or service-level testing unless the software robot is building an integration using the APIs of the applications being touched.
As such, as RPA robots are being developed as low code, and the majority of the time by business users themselves, it instead requires exhaustive user acceptance testing which is not necessarily automated in nature. It is necessary to validate the different requirements, to include the business rules and exceptional scenarios, that an RPA robot is meant to cover as part of the UAT effort.
The following diagram and tabular matrix depict an expanded testing pyramid approach, as applied to good code and low code development projects, and high-level features of different testing levels-
Read the other articles in this series from here:
The Robotic Process Automation Index
Contact us at SQA Consulting, to see how we may assist you in developing the necessary skills needed for implementing RPA projects.
