In traditional software development frameworks, there are a number of structures that have been developed to help you test your code and ensure that it is behaving the way it should. Unit testing and testing environments along with integration testing make for robust workflows that can ensure that the product works. Because RPA is one of the new kids on the block and because of its inherent limitations, testing suites just aren’t as accessible as we’d like. But we must push onward, as good little developers, to do the best we can.
Why is it hard to test in RPA?
Part of what makes RPA difficult to test is the fact that the currently available software solutions tend to be proprietary, and for the most part they’re not built with testing at their core. This may be due to the fact that RPA hasn’t been as widely adopted as other programming solutions or for other reasons, but either way it means defining the testing structure ourselves. On top of this, RPA by its very nature limits what we can and cannot test. Because RPA is all about automating other software products, mocking results or testing against a test database is often not an option.
So how do you test in RPA?
Luckily, since we are well-trained engineers, we don’t throw our hands up in a huff and give up. There is still a bit of runway we can use including modularizing code, using environment variables, and setting up separate development, testing, and production environments.
Break your code up into small pieces that can be run independently from the full process. Ensure that each module accepts arguments in order to supply test data, and ensure that the modules return values that can be verified. Following these rules, you will be able to write unit test modules more easily to verify that each module behaves the way it should.
Often in RPA projects you will be saving files to a directory, updating a spreadsheet, sending emails to users, or any other number of actions which have business value results. You don’t want to be sending emails to the CEO of your client company every time you run the process in development, but disabling the email snippet until you are ready for production doesn’t allow for proper testing. Changing the email address just before launch isn’t a good process either. The solution is to use environment variables. You can skip sending emails in development and configure different emails for staging and production. You can have different copies of that spreadsheet for each environment. Every RPA process is different and what needs to be protected and controlled in your different environments must be carefully considered. Many RPA solutions come with some kind of control room where you can configure variables (Automation Anywhere calls it the Control Room, UiPath calls it Orchestrator); if this is not an option you can setup a configuration file that lives on each of your machines in a standardized location that the process will access to load variables based on the environment you are in. Environment variables allow you to configure your process without needing to modify the code base itself, and are crucial to any robust engineering project.
We touched on this briefly with our discussion on environment variables; your RPA process should flow consecutively through 3 different environments: development, staging, and production. Each environment should be isolated from the others and be on its own machine (or virtual machine). Furthermore, each machine should be as similar to the production machine as possible. “But why can’t I just build the thing on the production computer and then hand it off when it’s ready for production?!” No! Bad engineer! While this might seem appealing for the first release, any software project will invariably require updates, and now look at the mess you are in! You can’t work on the production machine anymore because it is being used to run version 1.0 of your process. Now you have to go setup a development environment and create a workflow for deployment against a production server that is already in use. Don’t go down that road. Setup your separate environments first!
“But why can’t I just have a development environment and push to production after I do my testing there?” Well, that’s not as bad as the last suggestion, but there are still some issues here. The main problem is that unlike other programming projects that allow you to run tests in the background while you work on other things, RPA takes over your whole computer and leaves you twiddling your thumbs for the next hour or two while you wait for your tests to complete. Solution: setup a staging server. Not only will this free up your development machine for you to continue to work while tests run, but it will also help you test your deployment flow to another machine. Are the environment variables setup correctly? Did everything go as expected? Deploying to a staging server before deploying to a production server is always a good idea and will make your process much smoother.
All in all, there is a great deal of testing we can (and should!) be doing in RPA. Don’t let the lack of support get you down, be creative! Share your ideas! Don’t let the bots test your patience, be patience and test your bots!
Robotic Process Automation (RPA) Testing
The Future of Testing in Robotic Process Automation
How To Overcome Challenges Encountered While Doing Automation Testing
Executing a Proof of Concept Test for Robotic Process Automation
5 Lessons Learned From Implementing and Operating RPA
Robotic Process Automation: Dynamic Roadmap for Successful Implementation
Deployments Best Practices
Design Principles for Assisted Automation for RPA