Comparing robotic process automation and test automation

2Comparing robotic process automation and test automation |

Content3 Laying the groundwork

3 Comparing and contrasting RPA and test automation

5 Conclusion: the best tool is the one built for the job

Across all industries, people are buzzing about robotic process automation (RPA) and the exciting possibilities it holds for automating rote, repetitive tasks. In the testing world, we’ve been hearing more and more clients ask about using RPA rather than more traditional testing automation tools. But while RPA is an incredibly useful tool, it also has challenges. Organizations need to thoughtfully choose their tools, depending on their needs today and in the future, or they risk wasting money, time and resources.

3Comparing robotic process automation and test automation |

What is RPA?At its simplest, RPA is a technology that allows people to automate repetitive tasks and processes using programs called bots. For example, a bot might be used to process applications for new bank accounts, or to automate filling out time sheets.

RPA is really useful to automate mundane, always-the-same tasks that humans dislike so much. It’s also useful for bridging the gap between old technology and new technology. For instance, if a company has a legacy system that is outdated and requires significant human effort, rather than investing millions of dollars and months or years migrating to a new system, RPA can help automate those processes in the legacy system to reduce manual effort and overall processing time. Its core purpose is to automate processes to save time.

What is test automation?Test automation is used to test software before it is implemented for real-world use to look for things that don’t work as expected. Similar to RPA, it is used to automate repetitive processes — usually regression testing and functional testing. Regression testing and functional testing often involve hundreds or thousands of repetitive tests to ensure that software is operating correctly, so are often targeted for automation. Test automation’s core purpose is to automate tests to save time.

Functional testingEvaluates if software is performing a specific function as intended

Regression testingEvaluates if software is performing correctly after a change is made

Laying the groundwork

Comparing and contrasting RPA and test automation

To help organizations make thoughtful decisions about when to choose RPA or test automation, we offer a side-by-side comparison.

RPA Test automation

Intended purpose Production and user processes

Testing

Cost to develop High Low

Required stability High Medium

Efficient X X

Built-in testing capabilities X

Easily extensible X

SimilaritiesOn the surface, test automation is similar to RPA. Both help free talent from completing repetitive tasks, saving time. When designed and deployed correctly, both increase efficiency and reduce the error rate of rote tasks and processes. Both have low- to no-code options. Even the underlying technology often is the same.

DifferencesThe differences between test automation and RPA are in their DNA, essentially. The intended use cases, and therefore the fundamental design, are different.

• Built-in testing functionality. While the ease of using RPA is attractive, extensive customizing is needed for RPA to meet basic testing needs that are included in off-the-shelf test automation. These features include what happens when a test is passed or failed, generating test results, capturing information about the test and transferring that information to test management tools. All of these things can be built into RPA, but require

4Comparing robotic process automation and test automation |

extensive development time, negating the ease of use that is a major benefit of RPA.

• Required stability. RPA is designed to work on repeatable, unchanging processes in a user-facing production environment. This kind of environment is stable, as change is introduced infrequently and only after thorough testing. Test automation tools are exactly the opposite. Test environments change constantly, and test automation tools are designed to work in that environment. RPA tends to break often in the testing environment since it fundamentally doesn’t have the built-in mechanisms to manage a lot of change.

• Easily extensible. RPA tools were built to be easy for anyone to use. Controlled with drag-and-drop functionality and flowcharts, users don’t need to know how to code. However, that built-in simplicity limits RPA’s ability to be changed to do different or very complicated things. Test automation frameworks can be

built to do anything a user might need them to do, including adding as many new features as may be needed. However, doing so does require some technical skills.

• Cost to develop. RPA is expensive to develop since most RPA tools have a licensing cost. Building a process or piece of automation that will work in a test environment is also very time-consuming, as its design is heavily influenced by its intended purpose — working in a production environment. The built-in structure forces you to spend a lot of time making sure it’s doing things the way you intend, keeping track of what it’s doing and fixing it when something unexpected happens. Test automation is relatively inexpensive, as it is designed for the testing environment. You can also automate processes in a fraction of the time.

RPA and test automation can complement each otherThough the use cases for RPA and test automation tools are different, when used together, they can complement each other. For instance, if you have already automated a process with RPA in a production environment, that information can help them prioritize which processes should be automated in a testing environment, or offer lessons learned about how to navigate some of the challenges or complexities of automating a specific process.

You can also use RPA to automate data creation for testing environments. For example, if users are testing a change that relies on transferring money on a banking platform, to test the change, they would need to simulate transferring money from account to account hundreds or thousands of times. If there’s already an RPA script being used to transfer money in the production environment, a user may be able to use it in the testing environment so they don’t have to do that manually.

Production environment The servers where applications are in regular use by the business

Testing environment Dedicated servers where changes are tested before going into the production environment; highly variable, as developers continually update in response to testing

5Comparing robotic process automation and test automation |

The decision between using RPA and test automation tools needs to be made thoughtfully, depending on the use case. Neither is good nor bad — rather, they are best when used to do the jobs for which they were built: RPA for automating production user processes and test automation tools for testing. It’s similar to deciding between vehicles to purchase. An SUV and a pickup truck work similarly and can get you from point to point, but the pickup truck can easily haul a load of stone and an SUV can comfortably carry six passengers. And neither can do the other’s job easily or well.

One thing is sure — even when a decision is made, organizations should always be looking for ways to be more efficient and use technology to continue to innovate. Toolsets will continue to evolve as technology evolves, and there will always be new capabilities and new issues to tackle. That means companies will need to re-evaluate their tools frequently and change or upgrade as necessary.

Conclusion: the best tool is the one built for the job

EY | Building a better working world

EY exists to build a better working world, helping to create long-term value for clients, people and society and build trust in the capital markets.

Enabled by data and technology, diverse EY teams in over 150 countries provide trust through assurance and help clients grow, transform and operate.

Working across assurance, consulting, law, strategy, tax and transactions, EY teams ask better questions to find new answers for the complex issues facing our world today.

EY refers to the global organization, and may refer to one or more, of the member firms of Ernst & Young Global Limited, each of which is a separate legal entity. Ernst & Young Global Limited, a UK company limited by guarantee, does not provide services to clients. Information about how EY collects and uses personal data and a description of the rights individuals have under data protection legislation are available via ey.com/privacy. EY member firms do not practice law where prohibited by local laws. For more information about our organization, please visit ey.com.

Ernst & Young LLP is a client-serving member firm of Ernst & Young Global Limited operating in the US.

© 2021 Ernst & Young LLP

All Rights Reserved.

US SCORE no. 13158-211US_22103-3746490ED NoneThis material has been prepared for general informational purposes only and is not intended to be relied upon as accounting, tax, legal or other professional advice. Please refer to your advisors for specific advice.

ey.com