Robotic Process Automation (RPA) Clarified - Part 2

Continue from Part 1.

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 (I 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.

• Use UI Automation to Assist Agile Showcases
• Creative Web Automation: Generate User Guide with Automation Script
• Creative Web Automation: Generate Ad-Free Study Notes

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 I was 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 really 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 the AgileWay Test Automation Formula.

--

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