Robotic process automation (RPA) is the application of technology that allows employees in a company to configure computer software or a “robot” to capture and interpret existing applications for processing a transaction, manipulating data, triggering responses and communicating with other digital systems.
Institute for Robotic Process Automation and Artifical Intelligence
In the robotic era, investing in regression test automation for your core, regularly changing applications is no longer optional because your strongest competitors are already doing it. Robotics offers the opportunity to increase productivity, reduce the burden of mundane tasks and to improve speed and accuracy in quality assurance.
However, like any investment you’d best know what you are buying into. What is your organisation’s test automation strategy? How are you ensuring that you aren’t paying multiple times for the same automation code? What reporting information are you expecting and what is the target state? Are you aiming for unattended automated build, deployment, test execution and notification and if so, are you building in those kinds of capabilities from the outset? Put simply, what kind of robot do you want and in what environment will it be required to operate?
Large scale, inherently stateful applications such as ETRMs pose problems for automation testers. Typical systems necessitate the analysis and verification of large datasets. The types of transactions and processes, involving both real-time and batch operations, often spanning multiple logical business days don’t lend themselves to off-the-peg, website-driver or GUI replay types of automation framework. The robot you need requires specialist skills and ideally some domain specific knowledge built into its circuits.
Because this is a complex undertaking, companies will often entrust test automation tasks to their technologists which usually ends up meaning a developer with some bandwidth between tasks. My experience of the results of this approach, observed in multiple organisations, is a hotchpotch of half-baked automation solutions, one per project, with duplicated code and no overarching strategy. Often the robots created thus are overly specialised, meaning it’s not possible to communicate with them in business language or to increase their scope of operations without a large reprogramming exercise. There is usually neither commonality of reporting nor a unified vision for the role of automation across and between projects.
Is your organisation developing test automation capability in silos? There’s a strong possibility you are using multiple frameworks and approaches. Your teams are likely writing similar code to solve the same problems many times over. If that’s the case, are you realising the true value of robotic processes or just spawning a ramshackle array of dumb machines?