1

I am Test Automation engineer and recently got opportunity to explore RPA tool blueprism. After exploring I found it similar to UI automation tools supporting various technologies. Can anyone tell me what value RPA adds compare to traditional tools. I was interested to see how it can use 'intelligence' but couldn't find any feature.

Can expert in this forum help me understand what RPA can do which traditional tool can not do ?

I see similar questions but they do not give any answers I am looking for.

Thanks, Nilesh

Nilesh G
  • 103
  • 1
  • 9
  • 2
    This question's a bit broad for the Stack Overflow Q&A format, but I'll take a stab: the primary benefit of using RPA over another tool/platform is the scale at which you can perform automated processes. Scaling from one instance to 1,000 is trivial when your infrastructure is properly set. – esqew Feb 19 '19 at 13:21
  • 1
    I'm voting to close the question because at the core it's more of a request for recommendation for a particular tool, which is off topic for SO. – Jerry Feb 20 '19 at 05:21

7 Answers7

7

The technological challenges of RPA and automation tools are quite similar. RPA and testing products differ in their user experience and reporting. While testing tools often offer features to assess risk or create testing data, RPA tools have bigger focus on bot creation and user data storage.

MartinThé
  • 706
  • 7
  • 19
  • Hi Martin. What you say is not wrong but, in my opinion, not the main point. The main difference between both techniques is the goal: test automation is for application test i.e. quality check, generally running on a test environment. RPA is for the implementation of a real business process running in a productive environment. I go into more detail in my post below. PS: Tricentis is developing RPA probably because they reuse the part of the system source that is responsible for driving applications. – primehunter Jun 27 '19 at 15:23
  • By the way: Tricentis has abandoned its RPA functionality. – primehunter Mar 18 '21 at 12:10
  • @primehunter, you're right. I removed the vendor specific information. – MartinThé Mar 18 '21 at 13:11
5

The main difference between the two very similar techniques Test (Process) Automation and Robotic Process Automation is the Goal. Almost all the points contained in the previous posts are, in my modest opinion, consequences of the goal of both techniques:

  • With a Test (Process) Automation tool you want to test an application or system under test. I.e.: Want to find bugs or to prove that the quality of the application has reached a certain level. The Test Process Automation will in general run in a test environment. If something goes wrong with your test automation code or tool breaking completely down the test environment, it is not that bad: You can reset the environment and have not hurt anyone.
  • With a RPA tool you want to implement a real life business process. The robot works in a productive environment. If something goes wrong you may really hurt someone, i.e. damage productive data or environment. The robot does the work of a user, not just simulates it. Therefore, the robot must be "save". It must also be possible to understand what the robot exactly did with the job it got.

I hope, this help to clarify.

PS: I include the word "Process" in the context of testing, because initializing or resetting a test environment, providing secondary data, booting a system under test, running a test, collecting results, comparing actual with expected results, creating reports for test management or DevOps is usually a process you automate using some kind of "Test Process Automation" not just Test Automation.

primehunter
  • 280
  • 4
  • 10
3

on a less official and serious note, RPA is a marketing term for a Test Automation Robot pumped up with some kind of a Workflow Editor and some remoting Technologies

We were using standard Test Automation Robots(UFT, Selenium etc) to do some RPA with the backlash that the automated workflow was rather coded than visualized and we had to have some effort invested into the infrastructure to support scaling. (launching them en-masse and automatically)

What does it solve? - As mentioned above, visualising worfklows and scaling - although here it has limitations

What are the weak points?

  • The Test Automation Robot wrapped inside the RPA can be very limited - in many cases they are less mature than state of the art TA Robots.
  • The promise of record & replay and drag & drop your workflow. As always - we are not yet there
  • It solves a problem in a way it shouldn't be solved; The GUI is for the user the APIs are for the software (or call them robots in this case). These problems should be solved by writing integrations between systems or extending existing APIs (safer, cheaper, much more reliable etc)
Bela Tamas Jozsa
  • 714
  • 5
  • 10
  • Totally agree. It looks nice on paper, but when it comes to actual development, you still end up needing someone who can actually write decent code, otherwise you'll get a mess that hardly works. And when that happens, you really could just let that programmer write it in pure C#/python/whatever, maybe using stuff like selenium. On the other hand, if all you need is a small script to fiddle with your excel files - you can do it with autoit/autohotkey. Only real advantage of RPA tools is that it is easier to sell them to your management, despite the price... the irony. – Elhana Mar 15 '19 at 22:19
  • You probably were unlucky in your RPA platform. WF or BP are similar to what you describe but there are other platforms which are accessible to business users. See some of the UiPath videos or go to Academy and try it out yourself. No coding skills required for most tasks – Ilya Kochetov Apr 07 '19 at 19:16
  • A Test Automation Robot is just an API for the desktop, aka it gives you some easy ways to work with the mess we call Desktop. They all come with Record and Replay and Drag and Drop test creation methodologies(marketing), but they become unuseful very fast - or put it in a different way - their expression power is very limited. This industry is still in it's childhood and maybe there is no real need for it - at all - or opposite, systems are getting so complex that you won't be able to test / automate / integrate(RPA) on lower levels but only via the UI. P.S: No bad experiences here :) – Bela Tamas Jozsa Apr 13 '19 at 15:36
  • I think the difference is the same like to have one set of tools vs. one bag full with tools. You can use both of them to reach your goal. For me it's easier to use a standard RPA platform and yes it contains selenium activities, cloud activities, OCR activities etc. and yes the same result could be reached without RPA platform but it would be much more time and effort consuming. – Николай Нунев Nov 18 '19 at 13:02
  • @BelaTamasJozsa: For your first and second point, I recommend you take a look at **UiPath**. On the third point, I would like to point out that, on the one hand, system integrations are of course better than robots. There may nevertheless be reasons not to strive for integration: The system is too critical (never change a running system), the system landscape must remain unchanged, source code is lost, the manufacturer wants a horrendous sum for integration... Nevertheless, they want to "optimize" the processes through automation. Therefore we will be dealing with software robots for a while. – primehunter Jan 07 '20 at 08:13
2

RPA platforms provide you a singular place where various different type of applications can be automated.

These platforms fundamentally will try to consolidate and formalize the automation effort in an enterprise. and here the word "enterprise" is key.

for small businesses where they want to automate some task/s the intern can be asked to quickly build up something. no one cares what technology or tools were used. maybe he likes python, and someone else likes VBA. so a single task may be automated using several different technologies. no one cares as long as it works. the intern leaves and the next intern figures something new...

RPA platforms on the other hand are a larger "formal" effort that will try to automate tasks that otherwise require a lot of FTE (full time employee) count to accomplish. typical RPA use cases are repetitive tasks that humans are doing all day without using much brain. think of extracting each line item from a PO (purchase order) and putting it in an excel spreadsheet and then posting it on some internal application. now imagine a single guy doing this maybe for 100s of POs a day.

You cannot imagine how uneven the IT landscape in most of the enterprises is. old applications that were either built in house a long time ago or versions that arent being updated by the vendor any more. the bigger problem is when these applications do not have any integration points, so these RPA platforms provide the lease invasive (changes to old applications or upgrading even)

i can go on all day about RPA, do let me know if you have any follow up qns. i work for one of these RPA platforms, maybe i will be able to help.

ksm
  • 401
  • 4
  • 12
  • Can you be specific. I mean what features RPA has which traditional tool does not have. Say reading PO and entering in UI screen , can also be done by test automation tools. I am trying to figure out differential factor between two. Please be specific as I know that it support multiple technologies etc but other automation tools also do that (TOSCA) – Nilesh G Feb 20 '19 at 13:12
  • Hi Nilesh, one thing that RPA tools definitely have but automation tools don't necessarily have is the logging of all actions by default: you have to be able to track what a robot has done at all times: It runs in a productive environment, with real data. Therefore Robotics Tools log by default all actions they perform, with which Inputs and with which outputs. This is not always the case for automation tools: You can (in some cases, you have to) implement logging yourself. – primehunter Aug 22 '19 at 15:34
1

There are many flavours of RPA. Blueprism is not an ideal example of what modern RPA should look like, consider checking out Automation Anywhere or UiPath (both offer Community Edition you could download and try for free). While technological differences may not be that vast (and indeed RPA vendors are now looking at test automation as a market for their products), biggest differences are in the ways the platforms are engineered, to name a few:

  1. Security-oriented approach, RPA platform is designed to make sure it could handle important data responsibly.
  2. Design for ease of use for non-technical people. Selenium is great but you need to know how to program to use it. UiPath requires easy drag-and-drop for the same things.
  3. Working with unstructured data inputs, like OCR'ing documents and acting on them
  4. ML integration, for decision making or extra capabilities. E.g. NLP stuff, sentiment analysis, helping OCR recognize new document formats etc.5. Integration with third-party like chat bots or BPM
  5. Analytical and monitoring capabilities, to make sure that you know how long your bots take to do their work and to help them if they fail

Easy of use should not be discarded: With RPA it's a half an hour job to receive a request by mail, take data from SAP, build pivot in Excel and upload to a website in JSON format. Could you do that in other tools? Sure! Is that as easy? Usually no. So you could do poor man RPA with Selenium or AutoIT or bash or PowerShell, it will just be not as easy and will provide less capabilities while requiring more effort every step of the way. And if you do it properly you'll end up replicating one of the RPA platforms anyway.

Also in RPA there is usually but not always central coordination mechanism (ala Selenium Grid) to orchestrate several robots (up to 10k in UiPath case) to make sure they act in sync, have some sort of work queue, shift their workload, deploy processes to them etc. This makes all the difference for enterprise usage scenarios.

Ilya Kochetov
  • 17,988
  • 6
  • 44
  • 60
0

RPA and UI Automation tools have some technical features that intersect. For example;

  • UI Component utilization: These tools may utilize a UI screen image-based approach, OS platform frameworks (i.e. Microsoft Accessibility Frameworks), or technology-centric platforms extension (i.e Chrome or Firefox extension)
  • End-2-End application driving: These tools have the capabilities to drive applications to complete their duties. For example, log in to an application and get some data and shift to other legacy applications and enter data.
  • Screen scraping: These tools have screen scraping features to retrieve some data on screens there other techniques are not applicable.
  • 3rd party application integration: Also these tools can integrate web services or databases to get data and use these in their application usage scenarios. ...

As you see lots of features these RPA and UI Automation tools share. But, the main concept is here not technology but application methodology. In this point of view, RPA Tools

  • Designed to drive real-life business flow in the production environment.
  • May have some cognitive power to complete human-exhibit tasks (i.e. document analysis, high OCR capability, pattern recognition)
  • Can work attendant and unattended
  • Doesn’t require any programming language knowledge. That non-technic staff can easily use and learn.
  • Contrast to below: for implementing complex flows, gaining scalability, achieve seamless integration to Third-Party application, and native integration of external technology into your business flows (i.e. third party microblog sentence classification A.I. library that you developed your own) Some RPA tools (Voodoo RPA) have their own Embedded Development Environment (EDE) for programmers.
  • Invented for doing the high-value repeatable task in 7/24 in reliable and secure manners
  • Enhanced workflow management, impersonation, and logging capabilities

In sum, RPA tools developed to easily implement high-volume repetitive tasks in a business environment but UI automation developed to test the application's UI and verify business rules suited for the baseline paradigm.

RPA Developer
  • 1
0

  1. The main difference is a type of task we can automate using traditional automation and RPA:

    • Traditional automation is mainly used to automate test cases of applications/products.
    • RPA is mainly used to automate business processes.

    1. If we talk in terms of coding knowledge then traditional automation required more coding knowledge in comparison to RPA.

    2. Traditional automation can either support desktop app automation or web app automation at a time without integration of 3rd party tools. whereas RPA can support both web and desktop app automation.

bhumil raval
  • 51
  • 2