What's the technical difference between Robotic Process Automation (RPA) and Test Automation Tools?

Hi,
I've worked with test automation tools and know technically how it works, basically record (generate scripts) and replay (the generated scripts with data).

Now I heard of RPA, and people tell me its advantage is handling non-structured process, pattern and data. I want to know how exactly RPA does the work, how much different from the record and replay?

Comments

  • Here is my 2 cents ...

    RPA is all about replacing the human being for mundane work. If we imagine a person who is working a repetitive task (and repetitive is a key here). We can automate the work they perform by looking at what they do now and scripting some or all of that by driving the screen/keyboard/apps. For example, imagine if I am processing a loan application and, due to my current IT environment, I receive loan requests in application A and the data needs to be transcribed to application B. Today I bring up two windows and swivel chair copy the data from app A to app B. This might take me 5 minutes per application. RPA allows me to describe that task and have the RPA engine perform the work on my behalf. It will execute quicker than I can type, be far less error prone and frees me up to do other work.

    This is a trivial example but may start to give an idea of the purpose of RPA. The secret sauce of a good RPA engine is the ease/simplicity by which an RPA engine user can describe the automation of the task. A good RPA engine can also leverage dynamic decisions such as doing one thing if data indicates and doing another thing if the data indicates that. We end up with a "flowchart" of steps to be performed to perform the task.

    A common question injected at this point is "Why do this rather than re-write/integrate the applications in the first place?" ... but the true answer is in the question. It takes time, effort, skills and cost to "re-write/integrate". RPA replaces a human without having to code. This means that the effort to achieve a human replacement might be as little as hours as compared to potentially weeks/months with a full scale integration story. No-one is arguing that if the integration between the applications using a data integration engine is available and strategic and you were to leverage (perhaps) a Business Process Management engine to orchestrate business steps ... then you would not need RPA. RPA is merely another tool in your tool box to use or not use as you desire.

    As for the overlap between RPA and Test Automation tools ... they both drive screens, they both drive keyboards, they both can be scripted and one would imagine that at the lowest level, they probably are engineered very similarly. The distinctions are likely to be the development experience of how to describe the task and run-time considerations. In testing, if you drive the screen and expect something to happen and it doesn't, you flag the test failed and go on to the next test. In RPA, if you expect something to happen and it doesn't, your task must take remedial action to resolve the issues and then carry on. There are more distinctions ...

Sign In or Register to comment.