OK everyone, I have a candid confession to make. I started writing this article as a way to link up "Appium" and "RPA (Robotic Process Automation)", since RPA is such a hot thing right now. I even found an appropriately vague and generic technology graphic to accompany it. (Did you know that this graphic came with the following tags: Industry, Energy, Power, and Businessman? I kid you not). But the more I tried to write some SEO gold, the more I realized how ridiculous this all is. So you're just going to get my honest thoughts here.
Robotic Process Automation (or RPA) has become a huge industry. This article has a wordy but standard definition for RPA:
RPA is an application of technology, governed by business logic and structured inputs, aimed at automating business processes. Using RPA tools, a company can configure software, or a “robot,” to capture and interpret applications for processing a transaction, manipulating data, triggering responses and communicating with other digital systems.
Once you parse out all the nonsense from this definition, what you arrive at is the idea of ... software controlling software! At a first pass, this is kind of a ridiculous idea. Software is already programmed to do things. Why do we need a second level of software to control other software? Why not just make that basic software do what we want to begin with? This is, in fact, what we should do if we can. Adding layers of indirection is never a good idea. Sometimes, though, we wind up in a situation where we can't actually modify the software we want to control. (Does this sound familiar to any of testers out there?) In that case, we can write additional software to use the first piece of software, as if it were a user.
Before everyone just says, "wait a minute, that's exactly what we do with UI test automation!" let me make one more point. The main motivation for RPA in my opinion is the proliferation of software as the primary mechanism of business. Employees are faced with the same kinds of mechanical, menial tasks they were faced with before the software revolution, but now they just happen on computer screens instead of in assembly lines. In this context, it makes sense to ask how software that you don't own, but need to use in various robotic ways, can be controlled. And the answer, as always, is "robots!" When it comes to manufacturing cars, that means physical robots. When it comes to entering data into spreadsheets, that means software robots.
So now, let's say it together: RPA is no different from UI test automation. It has a different purpose, sure, but the nuts and bolts are identical. All the tools you use for UI automation can also be used for RPA! So let's look at how Appium fits into all this. What makes Appium a good RPA tool?
Of course, using Appium as a scripting solution is likely not going to appeal to the audience that wants a fully point-and-click RPA development environment. However, with tools like Appium Desktop, the barrier is slightly reduced, and there are already products built on top of Appium that allow for a fully visual experience.
So, next time you stumble across an article on RPA like the one above, and see 10-step guidelines that include phrases like "5. Don't fall down the data rabbit hole" or "10. Put RPA into your whole development lifecycle", you safely discard it as unnecessary fluff. All you really need to know about RPA is that it is UI automation, plain and simple. The rest is details. I'm not implying that there is no business or managerial complexity to implementing RPA solutions. I'm merely pointing out to all the CIOs out there that their "RPA Center of Excellence" is already staring them in the face in the form of their test automation team!
OK, now you can go and add "RPA" to your resume and ask for a raise. You're welcome!