RPA Development Testing
Tips for Business Owners or RPA Project Leads
Require Test Cases as a Deliverable
Insist that whomever is helping you automate, provides a full set of test cases to you as a deliverable. A business process can change over time, or the application GUI/interfaces that you normally use can change as well. This will force rework on any automation that you have.
Test cases contain a wealth of information about your process, that will help the consultant, new or old, figure out where and how to make the changes needed to get your process up and running again.
The format of the test cases will likely be a combination of text documents, spreadsheets and actual code.
Help the Developers Discover Every Scenario that needs Tests for.
You’ll need to work together with the consultant to really uncover every single scenario that you need to automate, and test for. The sooner you do this, the better. Otherwise, you’ll receive an automation that might only do 70% of the cases that you want it to handle.
What normally happens during the “requirements gathering” or “scoping” work is that you will describe verbally the steps that the process needs to undergo. But you’re likely only thinking about the most common flow that a process goes down, and not any edge cases. Uncover these edge cases by asking the consultant to sit down with you and design test scenarios for your process before development begins.
But at the same time, remember the 80/20 rule. It’s likely that 80% of the time you spend, or the volume of work that you do, lies in just 20% of the automation scenarios. Recognizing this, and actively omitting certain scenarios from automation will likely have a better cost/value ratio or ROI for you as a business owner.
Tips for RPA Developers
Testing RPA has has many parallels to traditional software testing, but there are also a number of unique differences. The general types and order of testing that I do for RPA projects is below.
First we have, unit testing. Your RPA code is hopefully structured in a modular way that will allow you to test individual functions or actions independently. An example is if you have a function that clicks a link to move from Screen A to Screen B. You can build out a library of unit tests to test these independent small actions.
Then you have integration testing, where consecutive steps using the using multiple pieces of the small actions that you’ve built up are tested. This may be something like, Open a browser, visit a webpage, log in, click through 5 different links on the website, then logout. These integration tests can be actual consecutive steps that are specifically required in your work processes, but I think that its better to just have generic tests, that can be reused over and over again, and not tied to a specific process. Process specific tests will eventually be done when you test it against the functional requirements anyways.
The audience for the two tests above are just the “developer” team themselves, to give them confidence that the pieces that they’ve built work properly. There may be sign-off required by a senior developer or development team lead.
Next we get into functional requirements testing, to answer the question: “does the process do what is stated in the requirements”? You will likely need a subject matter expert, perhaps the business analyst who wrote out the process steps and requirements to sit down with you to design, and run through the different testing scenarios that you need. The test scenarios are normally controlled by a set of input data, meaning that you are designing a set of input data that will lead you down different paths in your process. An example of this is you may need to design 15 different customers with different ages (under 18, between 18–65, 65+), bank account types (chequing, savings), and bank balances (positive, near to zero, zero) to cover all the process scenarios for a bank account closure process.
Another important type of test are non-function requirements testing. An example of this would be performance requirements, such as the process must complete one run within 5 minutes on a machine with hardware spec X. You would need to replicate the environment that these non-functional requirements are supposed to fulfill, so you may need to delay this until after you’ve deployed the processes into a UAT or Production environment.
Then, before moving the process into Production, there should be some form of User Acceptance Testing, where the actual process owner or user from the business side will walk through your test scenarios with you and sign off on them. Once all signed off, the process can be moved into Production.
An RPA specific difference from regular software testing is whether the applications have separate environments already, such as Dev, Test and Production. In the case of Intranet based applications, chances are you won’t be able to test against the Production application, which means that your test design will likely need to be done progressively against those environments.
Just as in regular software development, the developer should try to get their hands on the Production applications or data as soon as possible, to test against that. But you have to be careful to not modify any data by testing your process. Carefully think about which steps are “reading” from the system and which will actual “write” or “submit” data to the system. Process steps and test should be separated along those lines – which will not modify any data in production systems, and which will. You can re-run tests that only perform read operations on production systems (assuming that there is no performance impact), while you should only run tests that can write or submit production data in the presence of an SME.
Finally, automate your testing! Use your RPA tool or cross use RPA tools to run tests on each other! RPA software are just tools, and its best to have a multitude of them at your disposal. I personally focus on two RPA tools (although I also do general programming), Blue Prism and UiPath, and will use them to test themselves, or cross-test each other.
