RPA: Are We Making the Same Mistakes All Over Again?

RPA might be taking the enterprise software world by storm lately, but it’s certainly not new. Yes, it’s fun to envision how RPA can change the world by deploying armies of cute little robots that perform the work everyone hates. And any market move related to RPA is likely to earn the media attention once reserved for fallen darlings like Bitcoin, Big Data, and IoT.

Yet, RPA is hardly a new technology. Its roots actually lie in something at the far other end of the “cool technology” spectrum: software testing. For years, software testing has been treated as the “red-headed stepchild” of the application development world. In many cases—especially in enterprise environments with complex application architectures—it’s slow and costly, delaying innovation without providing clear value to the business.

RPA’s Roots Are Showing

Why has testing delivered such unimpressive results? Ultimately, it’s because attempts to automate the process have failed, despite over two decades of trying.

First, using script-based test automation technologies that require programming knowledge restricts the number and type of people who can create the automation. Then, organizations who pass that initial barrier run into another (more formidable) obstacle: the maintenance trap. Automation scripts based on a surface-level understanding of the application’s interface fail when they encounter slight variations, even acceptable and expected ones.

At first, teams usually attempt to update the scripts—playing “whack a mole” to address the expected variations. Then, the application evolves, and the team must also update the scripts for all the new functionality. Over time, this becomes a losing battle. The testers grow frustrated with the constant maintenance, and the decision makers no longer trust test results. Often, test automation reverts back to manual testing.

Disturbingly, this same unsustainable automation approach is what’s behind today’s hottest RPA tools. From a technical perspective, RPA bots are really just sets of automation instructions. These instructions are expressed either in the form of scripts (with hard-coded technical details on how to find various element locators on the page) or model-based automation technologies (with reusable automation building blocks that abstract a deep understanding of the underlying technology). The script-based approach is by far the most common.

Ultimately, it’s the strength of the underlying automation engine that makes or breaks both RPA and software test automation initiatives. Given that script-based automation approaches have failed to meet enterprise test automation objectives over the past 20 years, it’s unreasonable to expect the same script-based approaches to now meet enterprise RPA objectives. Not surprisingly, the script-based approaches that have yielded poor results in the software test automation world continue to fall short in the RPA sphere—and the resilient model-based approaches that enable high levels of enterprise test automation continue to rise to the top for RPA.

Brittle automation—the same core problem that has doomed so many software test automation initiatives—has already emerged as the #1 enemy to RPA success and ROI. As publications such as The Wall Street Journal and Forbes have reported, the problem with RPA is that bots break—a lot.

RPA users are learning what software testers learned years ago: if your automation can’t adapt to day-to-day changes in interfaces, data sources and format, underlying business processes, etc., then maintaining the automation is going to rapidly eat into your ROI. Moreover, with RPA, the repercussions of broken automation are much more severe. A test that’s not running is one thing; a real business process that’s not getting completed is another.

Recommendations

But the common heritage of software test automation and RPA can be a blessing, not a curse. Old problems don’t have to be new again with RPA. The key problem with RPA—the construction of sustainable automation—is a skill that many organizations have already solved by taking a “no-code” model-based approach to test automation.

According to a recent Gartner keynote, many organizations are finding that successful software test automation is a great bridge into RPA initiatives, and “it’s important to utilize test automation assets and test automation teams as you build RPA.” There’s a growing trend of organizations entering into RPA by extending their test automation efforts—and those who have successfully conquered the test automation challenge are especially well-poised for success with RPA.

As with test automation initiatives, the success of RPA initiatives ultimately rests on resiliency. It’s essential to find an automation approach that enables business users to rapidly create and update resilient automation for the organization’s core enterprise technology sets (SAP, Salesforce, ServiceNow, Excel, PDF, custom apps, etc.).

RPA bots must be resilient to change and bot maintenance must be simple and straightforward…which eliminates the popular script-based approaches. Otherwise, RPA is simply short-lived automation that creates technical debt—leaving the organization at risk when automation fails to execute the required tasks. 

[Learn more at the Tricentis RPA Resource Center]