The simplest definition of RPA is that RPA is software that simulates human-computer interactions to automate repetitive business processes.
Robotic process automation (RPA) is a productivity tool that allows a user to configure one or more scripts (which some vendors refer to as “bots”) to activate specific keystrokes in an automated fashion. The result is that the bots can be used to mimic or emulate selected tasks (transaction steps) within an overall business or IT process. These may include manipulating data, passing data to and from different applications, triggering responses, or executing transactions. RPA uses a combination of user interface interaction and descriptor technologies. The scripts can overlay on one or more software applications.
Robotic process automation (or RPA) is a form of business process automation technology based on metaphorical software robots (bots) or artificial intelligence (AI) workers.
In traditional workflow automation tools, a software developer produces a list of actions to automate a task and interface to the back-end system using internal application programming interfaces (APIs) or dedicated scripting language. In contrast, RPA systems develop the action list by watching the user perform that task in the application's graphical user interface (GUI), and then perform the automation by repeating those tasks directly in the GUI. This can lower the barrier to use of automation in products that might not otherwise feature APIs for this purpose.
RPA tools have strong technical similarities to graphical user interface testing tools. These tools also automate interactions with the GUI, and often do so by repeating a set of demonstration actions performed by a user. RPA tools differ from such systems that allow data to be handled in and between multiple applications, for instance, receiving email containing an invoice, extracting the data, and then typing that into a bookkeeping system.
Software that can be easily programmed to do basic tasks across applications just as human workers do. The software robot can be taught a workflow with multiple steps and applications, such as taking received forms, sending a receipt message, checking the form for completeness, filing the form in a folder and updating a spreadsheet with the name of the form, the date filed, and so on. RPA software is designed to reduce the burden of repetitive, simple tasks on employees.
The term “robotic process automation” is a bit of misleading. There are no cool-looking robots involved (the “bots” are simply sets of automation instructions). It’s best suited to automating short repetitive tasks rather than long-running end-to-end processes. Ultimately, it’s “just” automation.
There are two main types of RPA bots: attended and unattended.
There are 3 main reasons to use RPA:
RPA offers a broad spectrum of benefits—most commonly related to accuracy, productivity, compliance, and simplicity.
RPA can perform everyday tasks such as:
You can use RPA to automate virtually any rules-based process. See RPA Use Cases and Examples for a detailed list of RPA use cases across telecom/media, financial/insurance, industrial/manufacturing, utilities, hospitality, public sector, health/life sciences, and retail— as well as several videos showing RPA in action.
Undeniably, the disciplines of RPA and software test automation are converging However, the tool sets, most likely, are not.
Enabling fast creation and updating of resilient UI automation and API automation is essential for both RPA and test automation. Nevertheless, there are some important differences. RPA requires enterprise-grade orchestration, high-availability, and production focus. Test automation requires capabilities such as test case design, service virtualization, test data management, etc.
In many respects, test automation is more difficult than RPA. With RPA, you need to determine how to use automation to advance known business tasks. With test automation, you need to determine what combination of factors could break an end-to-end process—and you also need to obtain, configure, and manage the test data and test environments needed to ensure your tests are accurate and realistic.
RPA tools aren’t designed for enterprise software testing, just like software testing tools aren’t designed for enterprise RPA. Nevertheless, core automation assets and skillsets certainly can (and should) be leveraged across test automation and RPA if you want to take the fast track to RPA success.
Want (yet) another perspective? Read what testing expert Matt Heusser had to say about software testing and RPA.
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 low-code 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 RPA 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.
As RPA programs scale, every organization will undeniably need to add more automation experts and make them more productive. The organization’s software testers are not only well-versed in your specific culture and processes; they most likely have the precise skillet that’s required for RPA success.
The ability to design, construct, and maintain resilient automation is critical to success for both RPA and test automation. RPA, like test automation, requires a system thinking mindset. Of course, you need the domain expertise required to truly understand how a process works. But this must be paired with the more difficult-to-find expertise on how to get (and keep) the process automated, including nuances like validations, exception/error handling, and rollback sequences. The functional testers that lead the organization’s QA efforts have already figured this out—often, for the very processes you want to automate with RPA.
In fact, recent Forrester research confirmed that software test automation success is linked to effective bot maintenance and cost control. Firms that are effective at software test automation are also 1.4 times more likely to be effective at controlling RPA costs. They are 1.3 times more likely to be effective at maintaining RPA bots (e.g., cost and response time for keeping bots running).
Tricentis RPA and Tricentis Tosca share the same core model-based automation, but each are separate products whose UIs and capabilities are focused on the task at hand (RPA/test automation). Existing Tricentis Tosca users will find that Tricentis RPA is very familiar.
Existing Tricentis Tosca automation artifacts and skillsets can be reused in Tricentis RPA. Everything you have created in the past can be used in Tricentis RPA—including your custom controls and models.
This reuse dramatically reduces the time and effort required to get started with RPA. If test automation has already been built around a core process, you gain a tremendous “head start” on the RPA automation effort. Additionally, if you use Tricentis for both test automation and RPA, you can identify and accommodate RPA changes faster