As an automation developer, I enjoy high levels of autonomy. I have a massive territory to explore – web testing, API testing, mobile application testing, performance testing, chaos testing, and of course – Robotic Process Automation (RPA).

In this article, I’ll share my experience shifting from test automation to RPA, the benefits of such a shift, and how to overcome some of the gaps.

What got me into RPA?

I’ve been working at MSD Animal Health Intelligence Technology Labs for nearly 6 years, and I designed, coded, deployed, and maintained automated test scripts and performance testing scripts for a long time.

My colleagues and I stumbled upon a quarterly routine in which our developers and QA engineers systematically collect business intelligence from our customers’ end products using our tracing tools… manually. But unfortunately, it had been an utter waste of resources, time, efforts, and money, and ultimately inefficient and prone to human error.

As we started thinking about ways to do that automatically, we found that much of the automated procedure is scattered around our test automation code – developed with Robot Framework – where we use Selenium for web app automation, requests for API automation, and Python to extend Robot Framework when needed.

I then remembered hearing a talk at the 2018 RoboCon event titled “The Open RPA Ecosystem”  by Antti Karjalainen.

This was when I realized I could simply take my existing test code, add a few more features, and run it on a cloud-native environment that already handles all the deployment and auditing problems for me.

I was electrified!

We don’t need to set up special environment(s) to run RPA code. We don’t need to learn a whole new ecosystem or a toolchain, and we don’t need to hire any experts for other tools. Instead, we can use the human capital we already have and take advantage of it for other endeavors.

This is also a relief for our DevOps team, as they don’t need to set up complex cloud solutions for RPA tasks.

I also discovered that I benefit from exploring this rapidly-growing field while simultaneously providing high value to my organization at very low costs. It’s a win-win situation!

Looking at the market as a whole, I think that it’s more than possible that automation developers can seamlessly pivot in both directions between test automation and RPA.

Knowledge transfers and knowledge gaps

Having discussed the motivation, we can now look at the knowledge that we can apply to both disciplines (i.e., knowledge transfers) and the knowledge that needs to be acquired when transitioning between disciplines (i.e., knowledge gaps).

Transfer #1 – Concurrency

For RPA and test automation, concurrency is mainly used to speed up the process. 

In Robot Framework, for example, this is easily achieved using the PabotLib (pabot) library and can be applied in both cases.

Sometimes we use concurrency as a waiting strategy. For example, the Robot Framework Browser library can be used to wait for a promise that runs on the browser’s internals. This can be used in both RPA and test automation.

One interesting exception to the rule is performance testing, in which concurrency is used to load the system under test. At the moment, I don’t see this being useful in RPA, but with so many talented minds out there, I won’t be surprised if this can happen.

Gap #1 – Error handling

False negatives are arguably test automation developers’ greatest fear. It can absolutely destroy the confidence and reliability of their test projects. Therefore, they tend to avoid error handling, and when errors do occur, they would rather fail the test run.

In RPA, however, false negatives are not an issue. Instead, RPA developers are more concerned about their actual business objective being achieved, so they are more likely to use error handling methods like try / except, which has recently been added to Robot Framework’s functionality.

So, to make the transition, one would need to have a good knowledge of error handling best practices.

Transfer #2 – Data-driven execution

Often we have a test scenario that runs on different datasets. For example, localization tests tend to run the same scenario in different languages or time zones. 

For that purpose, we typically use something like Robot Framework DataDriver (robotframework-datadriver) to carry out data-driven tests when the data of each test case is stored in an external file like a CSV or JSON.

The same occurs in RPA as we run a scenario on different sets of data. For example, digitizing a list of invoices might use the same RPA code with a list of inputs coming from a CSV file.

 Data-driven tests are awesome – but can easily be abused – so use them wisely!

Gap #2 – Reporting

Test automation reporting is extremely generalized.

With tools such as Allure or ReportsPortal that easily integrate with Robot Framework, any stakeholder can view test results and different KPIs. However, in RPA, reporting is business specific. Therefore, the outcome of the execution needs to be processed and delivered to different stakeholders in sensible ways.

In our use case, we use MongoDB dashboards to show the results, but it can vary between different robots, different business processes, and even different stakeholders. So I’d argue that developers pivoting to RPA will require a deep understanding of business processes to meet their stakeholders’ needs adequately.

Transfer #3 – Failure root cause analysis

When automations fail, developers ought to investigate the root cause of failure and fix it. This skillset is shared across test automation and RPA domains.

For the most part, the root causes are the same. For example, timing and the solutions are similar – so is adding a delay. The fact that we can investigate root causes in the same fashion adds massive value to shifting between test automation and RPA.

Gap #3 – State management

State management, such as flow controls (if, else, loops, etc.) and explicit imperative statements, are regarded as a test smell. In other orders, these should be avoided in our automated test code. In RPA, on the other hand, these are very useful and necessary. 

Learning the best practices of state management is heavily required to make a transition.

Conclusion

Transitioning between test automation and RPA will boost your skills. In addition, you’ll often find that you can apply the skills developed in one discipline to another, making you a better, more well-rounded developer. RPA provides awesome development opportunities for automation developers, allowing them to develop expertise in other areas they usually aren’t exposed to.