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
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.
You can tell that there are similarities by the fact that Tricentis, the company behind the testing solution Tosca, is now also developing a RPA product (Tricentis RPA).
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.
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.
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)
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.
来源：https://stackoverflow.com/questions/54767146/rpa-vs-traditional-automation-tools