Place yourself in Jeopardy! mode for a moment. Here’s the answer…
Automatically driving an application via the UI or API to make manual work faster, less burdensome, and more accurate.
Time to give Alex Trebec your answer. If you say “What is test automation?”, you’re correct. But if you say “What is Robotic Process Automation?” you’re also correct. Undeniably, test automation and RPA have a lot in common—for better, or for worse.
What is RPA?
While software testing all-too-often remains the overlooked “second-class citizen” of the application development world, RPA has truly captured the attention (and dollars) of IT leaders—to the point where it has become the fastest-growing market in enterprise software.
At its core, RPA is ultimately the same as software test automation. As the Jeopardy! leadoff suggested, both RPA and software test automation automatically drive an application via the UI or API to make manual work faster, less burdensome, and more accurate.
RELATED CONTENT: Is smarter RPA on the horizon?
Of course, there are some key differences:
- RPA focuses on automating sequences of tasks in production environments to successfully execute a clearly-defined path through a process so you can complete work faster
- Test automation focuses on automating realistic business processes in test environments to see where an application fails so you can make informed decisions about whether an application is too risky to release
In other words: with RPA, you use automation to make a process work. For software testing, you focus on using automation to determine how a process can possibly break.
There are two critical automation capabilities required for both RPA and software test automation: UI automation and API automation. At the same time, there are some core differences that must be addressed to enable either software test automation or RPA to succeed at scale in the enterprise. In terms of software test automation, this includes secure and stateful test data management, test-driven service virtualization, change-impact analysis, and risk-based test case design. For RPA, this involves production-grade execution, enterprise-grade security and access control, and comprehensive event triggers.
RPA: Not robotic. Not process. “Just” automation
Despite its catchy moniker, RPA is really “just” automation.
It’s easy to be enticed by vendor-induced visions of sophisticated cyborg-like robots taking over previously-human-led processes—faster, better, and cheaper. However, that’s quite far from RPA reality. From a technical perspective, RPA bots are really just sets of automation instructions. These instructions are either expressed 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 (which define automation from the perspective of business user and store automation details in reusable/rearrangeable automation building blocks). If you’ve ever worked with test automation, these approaches should sound quite familiar.
Moreover, RPA’s strength has proven to be automating short repetitive tasks rather than long-running end-to-end processes. According to Gartner, “the term ‘process’ in the RPA acronym is more accurately discrete ‘task’ automation. Most automations supported by RPA tools last, at most, a couple of seconds. Furthermore, at best, the process support aspect of these products is limited to simplistic workflow.”
Solving age-old automation challenges
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 been reporting, the problem with RPA is that bots break—a lot. RPA users are realizing what 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.
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 most successful testers already possess.
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.
According to a recent Gartner keynote, many organizations are finding that 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.