Robotic Process Automation (RPA) Clarified
RPA is really a subset of proper End-to-End Test Automation
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.”
Table of Contents:
· Robotic Process Automation Simplified
∘ 1. RPA drives the application via GUI
∘ 2. The audience of RPA is business users
∘ 3. RPA often involves Multiple Applications
∘ 4. RPA is really a subset of Test Automation, focuses little on Quality Assurance
∘ 5. Real Test Automation is much more challenging than RPA
· People called me RPA Expert before I knew the meaning of RPA
· Suggestions on learning RPA
∘ ResourcesRobotic Process Automation Simplified
Let me 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 you can 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 from 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 it was even agreed upon by Cucumber’s creator. 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, maybe I will 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.
3. RPA often involves Multiple Applications
Quite often, automating business tasks involves multiple applications and multiple forms, such as:
Drive the main web in a browser
Find a certain piece of data from the Database (running SQL query)
Invoke batch or shell scripts
Invoke external service API
Verify notifications on smartphones.
As you can see, a proper RPA solution shall be based on using the same powerful scripting language, such as Ruby (and preferably developed and running in the same tool, such as TestWise IDE). I call this Test Automation Synergy (may write a separate article on this topic in the future).
4. RPA is really a subset of proper End-To-End Test Automation, which focuses little on Quality Assurance
Test Automation = Automation + Quality Assurance
If an engineer can do real test automation (again, very rare), he/she would find RPA very easy as it is just the subset of Test Automation. I have already covered the content of using automated end-2-end test scripts for automating business tasks in my following articles.
5. Real Test Automation is much more challenging than RPA
Let me illustrate the mindset differences between Test Automation and RPA (i.e. just Automation). Let’s take a typical insurance claim lodgement as an example.
RPA
My automation scripts don’t have to be 100% reliable and correct. If it failed on step 95 out of 100, I could just complete the rest 5 manually. This is not a good RPA implementation, but it is acceptable.Test Automation
In real Agile/DevOps, test automation means running the whole suite of automated end-to-end tests multiple times a day. During the execution, there must be no human interventions.
To give you a taste of how difficult Real Test Automation is, you can have a look at a recently automated end-to-end test report (as regression testing) on the BuildWise CT Server.
In the above run, there were almost 25,000 test steps. A green run means each of those 25000 test steps is PASSED. I ran this regression testing multiple times a day where code changes were made. That’s why >90% of test automation attempts are at either Level 0 or 1 of AgileWay Continuous Testing Grading.
People called me RPA Expert before I knew the meaning of RPA
I heard of RPA for the first time in 2020 while consulting at a local insurance company. A senior manager on the same floor came to ask for my help in implementing RPA for her team.
I asked: “What is RPA?”
The manager answered: “Robotic Process Automation. That is what you did at one demo: driving our insurance app in your current project”.
I said: “What I did is Test Automation”.
The manager smiled, “Our agile coach called it RPA. To me, what you did is exactly what we wanted”.
So I helped the team, and it was a simple task. For most automation steps I have already created (in Maintainable Automated Test Design) for my own project, I only made some modifications and sent the manager the package. I went over and showed their team members how to run the scripts. The team was surprised that it only took me a few hours to implement their requests and get the testing steps running (in TestWise and from the command line) easily. And it didn’t cost any extra for their project!
Suggestions on learning RPA
Don’t fall into the sales pitches of so-called fancy RPA tools. The free and best ones are there already:
WebDriver-based automation frameworks, such as Selenium WebDriver and Appium
Ruby Scripting Language
If you only want a quick answer, check out AgileWay Test Automation Formula.