Robotic Process Automation (RPA) Clarified - Part 1

This article is one of the “IT Terminology Clarified” series.

Robotic Process Automation (RPA), according to Wikipedia, is “a form of business process automation technology based on metaphorical software robots (bots)”. This definition is a bit vague, isn’t it? I read on and had a better understanding of it from the following three sentences.

“perform that task in the application’s graphical user interface (GUI), and then perform the automation by repeating those tasks directly in the GUI.”

“RPA tools have strong technical similarities to graphical user interface testing tools.”

“RPA tools differ from such systems in that they 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.”

In this article, I will translate RPA into plain English.

1. RPA drives the application via GUI

If a system is a web app, you can use Selenium scripts to drive the app in the browser by “using” a keyboard and mouse; With the same token, you can use Appium + WinAppDriver to automate windows desktop apps; Appium + ExpressoDriver to automate mobile apps on iOS and Android platforms respectively.

Quite often, failed test automation attempts are started with GUI automation using Cypress or Playwright. After the attempts failed, those fake test automation engineers (and the tech leads supported them) tried to avoid embarrassment by saying “Cypress/Playwright was the best for end-to-end testing via API. Therefore, we do end-to-end API Testing (which could be made less visible)” like this real story, which was actually a lie to cover up their incompetence. Automated End-to-End Testing, if the system has GUI, means driving the app via GUI, period.

In RPA, those fakers could not fool around with that GUI-to-API testing trick.

2. The audience of RPA is business users

The main purpose of RPA is to automate repetitive business tasks. This article listed some RPA examples.

• “An insurance adjuster adjudicates claims 75% faster with RPA”
• “A global telco provider digitized invoice processing and increased productivity by 400%”

A common mistake with Test Automation is those senior developers who get involved in making decisions on test automation. In reality, very few senior developers know real test automation. To give you an idea of how rare it is to find real test automation engineers: most IT professionals would not be lucky to meet one in their careers. For example, LinkedIn (in Silicon Valley) needed to lure one (for more, check out Wired’s article: The Software Revolution Behind LinkedIn's Gushing Profits)

“95% of the time, 95% of test engineers will write bad GUI automation just because it’s a very difficult thing to do correctly”. - the interview with Microsoft Test Guru Alan Page (2015), the author of "How we Test Software at Microsoft" book.

Over my 12 years of work in test automation on many projects, I have met many tech leads with fancy titles, such as Test Automation Lead, Principal Software Engineer, DevOps Lead, Solution Architect, Chief Software Engineer, and CIO. Surprisingly, they all made various wrong decisions on test automation. Yes, ALL of them! In doubt? I will list some of the bad decisions that you might find related to your experience.

• Use a record-and-playback tool, such as UFT and RFT. This has been long proven wrong. Recorded test scripts are hard to maintain. Check out the “Agile Testing” book on this topic.
• Use Java or C# as the scripting language. Java and C# are compiled languages. It is very wrong to use them for scripting, instead, shall be a scripting language. Check out my article, Automated Test Scripts Shall be in the Syntax of a Scripting Language, Naturally!
• Use a Gherkins syntax framework, e.g. Cucumber or SpecFlow. This is wrong, and Cucumber’s creator even agreed upon it. Check out my article, Why Gherkin (Cucumber, SpecFlow,…) Always Failed with UI Test Automation?
• Create “own framework”. Microsoft’s Coded UI Test failed, Protractor failed, IBM’s RFT failed, …., etc. What are the odds for a software team to create an automation framework?! The logical way is to use W3C’s standard: WebDriver. Check out my article, Please, Not Another Web Test Automation Framework, Just Use Raw Selenium WebDriver.
• ..., There are a lot more, I may write a separate article on this. Check out this article, Evil Mudslingings against Selenium WebDriver.

In summary, the developers’ influence on RPA shall be less than that of Test Automation.

---

In Part 2, I will explain the relation between RPA and Test Automation.

The original article was published on my Medium Blog, 2022-10-25