How to Build and Test Bots When Only Productive Environments are Available

It goes without saying that testing is an important part of any software product. That includes RPA products. Ideally, you should have a test environment for any application you are automating, so that you can work on developing the robots without interfering with business operations. Generally, this holds true for SAP environments: most companies have at least an additional test instance that we can work on and test freely, so that when we rollout to production the team and stakeholders feel confident that the robot doesn't have any major bugs and can be enabled on productive data. Other applications, such as operational tools, HR tools, or non-critical business tools hardly ever have a test instance. In the article below we're outlining some strategies to get around this limitation and deliver successful automation without impacting business operations.

Test subspaces

In some systems that have a hierarchical data structure, you can create a test subspace within the productive space. For example, on SharePoint this can be a subsite or a copy of your production document library with a "Test-" prefix, while on a file server it can be a simple subfolder. In Salesforce you can create a dedicated queue and name it accordingly. However, you apply it to your particular system, the most important aspect is to inform all the operators working in that area that there is this new space that they don't need to consider as real, production data.

Partner with specific users

In one automation we built, the robot needed to handle customer equipment maintenance bookings. Again, there was no test system, and no way of creating a data flow separated from the main one. As such, we worked with two employees and coordinated with them that we will be testing using their personal customer accounts. That way, we could create "fake data" associated to their customer accounts, such as medical appointments or invoices. We used this data to develop the robot and test its functionality, without impacting other customers.

Time-boxing

Another strategy we employed successfully was for an incident management process. We agreed on diverting all the incidents received between 9 and 10 AM to the robot, so we would have some data to work on. Requests, that were not processed by 3 PM would get picked up by the human operators, and solved well within the SLA (service level agreement). That way, our developers had up to 6 hours every day that they had new test data available to load the data views that they needed to code on, and test. Acceptance testing was a breeze, because in the last week (during the testing phase), the human operators started having less and less items to process every day at 3 PM. :)

Skip the save part

This is one of the easiest things to do: implement all the process steps, except the final one – the one, that saves the changes, that the robot did. So, we let the robot enter all data in all fields, process any searches, filters, data entry activities, but we don’t let the robot press the final save/submit/purchase button. A good example for this are automations that involve purchases, which obviously we do not want to trigger during development/testing. This of course only works if the process does not involve a series of interconnected entities that have updates depending on one-another, so partial saves would be mandatory.
When following this approach, the only thing that remains is at the end to implement the part when the robot has to effectively click save/submit/purchase/etc.: we do this by synchronizing with business users and doing a 2-3 hour attended development session together with them. In this session, we work on real-world data and carefully control what gets saved and make sure that we only process each set of data one time (to not create duplicates).

Other best practices

Although it is not just relevant to production-only systems, we want to underline the importance of having a dedicated robot account in the target application (such as Robot Robbi) that is used even from the development phase. That way, any changes done in production are clearly visible as a robot change and any operator can immediately override it if needed.

Finally, reporting on the results of each execution makes it easy to know what worked and what didn't, so you can rerun the failed entities, or forward them to human operators so they know where to look (imagine a robot that has processed 1000 items, and 3 of them had errors - you would want to know exactly which 3 to look at). Therefore, all Automatify robots come with reporting features as standard, that give you the ID of the processed entities, as well as their status, time to process, and other relevant metadata.