By Matthew Heusser firstname.lastname@example.org for Tricentis
Every now and again, I get an email from a company asking me to review their work. Occasionally, these are companies of which I have been critical. My long-standing relationship with Agile Testing Days started when I wrote, “Please do not support these fools and scoundrels” in a discussion group.
In response, Agile Testing Days offered to fly me to Germany to attend their conference. When I said I would not be muzzled and that I would tell the truth as I saw it, their reply was essentially, “We wouldn’t have it any other way.”
Last month, I got an even bolder email from Tricentis. They wanted me to take a look at Wayne Ariola’s talk on Robotic Process Automation’s (RPA’s) intersection with software testing. Wayne gave the talk at STARWEST 2019 (you can watch it on-demand—no registration required).
What’s the catch?
Software testers are a critical bunch. We grow immediately skeptical of the sales pitch. Personally, I was looking for value for the audience and specifically for things that were not a Google search away. I started with the definition of RPA. Wayne defined RPA this way:
Robotic Process Automation is a digital enablement technology that predominantly leverages a combination of user interface (UI) and surface-level features to automate routine, predictable data transcription work.
Breaking down Wayne’s words, we see that RPA is a way to drive the user interface to fill in fields, or to perhaps combine text pulled from fields, to create new material. Essentially, we take the old spreadsheet macros and apply them to any application. Most likely, we’ll apply them to two or more applications, pulling from one and putting into another.
Shadow IT and the RPA death spiral
Wayne talked about how RPA is typically born as shadow IT driven by the line of business, but turns into IT’s technical debt as the RPA bots that were so simple to create end up being not-so-simple to keep running (he calls this the “RPA death spiral”). This is a classic pattern. SQL, the Structured Query Language, was originally SeQL (the Structure English Query Language). The idea with SeQL was that line business managers would write code, except, of course, they didn’t. Instead, they hired analysts who wrote code that, eventually, was maintained by central IT. The same thing happened with Visual Basic and is happening now with low-code/no-code application tools.
I don’t see it as a death spiral. If IT leaders see value in RPA, they will allocate resources to maintain the systems. They will, of course, have problems. As the user interface changes through upgrades, the RPA bots will start to break. Who will fix them? Wayne suggests that software testers who have perfect skillset to create and fix bots. And, if they manage to make the leap to RPA, those testers are probably in line for a nice salary boost too.
Whether testers will actually get a shot at this work is an open question. When it comes to figuring these things out, the testing role is overlooked.
In other words, while testers might be great at RPA, getting a seat at the table will be the challenge. Start to find ways to lead the conversation and get attention right now.
The use cases for RPA
I’ve been skeptical of RPA. The common use case is claims analysis in insurance. I’ve worked in an insurance company. The claims that get kicked back to a human being are the kind that require a phone call to figure out (such as leaving the member ID off the claim form, for example). With a date of birth and a name, you can do a database query to try to find the answer and re-submit. A few years ago, the data entry team I worked with did just that on the back-end.
Wayne’s cases for RPA are reworking a legacy technology where the only interface is the front-end, which is likely to force integration and prevent manual rework or to accelerate manual tasks. His third use case is to validate critical checks in production to ensure that systems are synced up.
I have to admit that there are plenty of old systems, often client-server ones, that exist. On those systems, it is impossible to do what the data entry team did on the back-end. It has to be done through the user interface.
Are RPA and test converging?
Over the past fifteen years or so, all my personal devices have collapsed into a single one: my phone. My new iPhone 11 is good enough to be my camera, my camcorder, my audio recorder, and my handheld personal assistant/calendar. Wayne’s argument seems to be that with the right tools, we can collapse RPA and testing, reusing automation artifacts and skillsets. This could take the human UI-driving specialist to perform both roles and create automation for the operational parts of the business.
Imagine, for example, you have dual entry. Somewhere in your business, a hundred customer service representatives enter everything once into the sales system, get an order number, and then type it all in again in the manufacturing resource planning system. Imagine the service rep creates the sales order, gets the number, and then runs a little program that creates the order in MRP in thirty seconds instead of five minutes. The service rep can even start the next call. That saves five minutes per call, four calls per hour, over a hundred service reps, at twelve dollars an hour each, allowing the company to scale up the equivalent of 33 new service reps without adding to headcount.
That is the power of the STEM careers—we can take one thing and scale it out to hundreds or thousands of people to create business value. It also explains Wayne’s slide on salaries, where “RPA Experts” tend to command salaries that are two to three times higher than software testers. Those salaries are justified, not because the skills are different, but because it is easier to justify the value for the business.
The career cycle
Toward the end, Wayne points out that the basic title of “software tester” has a career progression limit within companies and that new and hot technologies allow the tester to leapfrog career-wise. When I heard that, I thought of Docker, Kubernetes, Business Intelligence Tools, Virtualization, the Private Cloud, and any other testing-adjacent technology. All of these were hot skills, that no one had, that allowed the user to command a premium (at least for a time). Some were hits, some were misses, and some, like Kubernetes, are becoming standards that DevOps developers need to learn just to stay in business.
Personally, I was surprised by Wayne’s comment that RPA will be hot for a short time and then fizzle out. While I don’t have enough data to make a prediction here, I can’t disagree with his reasoning. New technologies will come with built-in APIs that programmers will easily integrate. That means the opportunity will be with legacy systems, doing a new kind of “screen scraping”, similar to what companies were doing with COBOL green screens at the turn of the century. Once the low-hanging fruit is removed from these tasks, the gold rush will be over.
Seriously, what’s the catch?
Tricentis’s core technology, one of its secret sauces, is the ability to automate almost any technology via “model-based automation.” Tricentis Tosca has a way to control all those odd code generators and third-party apps. As such, it is a natural fit to repurpose the core Tricentis Tosca technology to drive Tricentis RPA. Companies that use Tricentis Tosca “plus” Tricentis RPA will be able to re-use automation artifacts between the two, using very similar technology stacks.
Of course they want to earn your business. Doing that in the test community is particularly difficult. We can smell a sales pitch a mile away, and I expected Tricentis to do something like this.
I just didn’t expect them to give it away.
Editors note: To learn more, watch RPA: A New Opportunity for Testers, visit the Tricentis RPA site, and download Tricentis RPA (free forever, no credit card required). Also, read Matt’s recent TechTarget article, Is RPA the future of test automation?