RPA Vs Traditional Automation Tools [closed] - automation

Question

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed last year.
Improve this question
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

Answer 1

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.

Answer 2

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.

Answer 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)

Answer 4

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.

Answer 5

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:
Security-oriented approach, RPA platform is designed to make sure it could handle important data responsibly.
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.
Working with unstructured data inputs, like OCR'ing documents and acting on them
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
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.

Answer 6

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.

Answer 7

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.
If we talk in terms of coding knowledge then traditional automation required more coding knowledge in comparison to RPA.
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.