.svg "Leapwork")
Knowledge base
Tips and tricks Best practice guides, FAQ & more
What kind of language do we need to speak to make QA-driven challenges resonate more clearly with business people? Maybe you’re a champion of test automation, or you’re trying to convince people in your company to move past repetitive and error-prone manual testing. Whoever you are, you’ll need to know how to approach management.
Skip to:
The problem with manual testing
Within companies, they’ll typically have created an internal hub tasked with automation, to make stuff work automatically. Let’s be generous and say there are 30 or 40 people in it.
Everyone knows how it is in reality. You put in a request to IT and it’s going to take a year—that’s the way the world works. IT is constantly overburdened. What you in fact create with an automation hub is the exact same dynamic, there’s so much demand to automate in order to remove monotonous, repetitive processes, that the automation itself becomes monotonous and repetitive.
While QA manual testing is repetitive, time-consuming, and error-prone, scripted automation testing comes with its own problems. The paradox is that scripted automation testing has become synonymous with programming while it is supposed to reduce the time used on repetitive manual testing. It takes time and developer resources to maintain the scripted tests.
If you ask them directly, the automation team will say “we’re a huge success. We’re continually working around the clock to add new functionality.” However, in a bar late at night, they might give a more candid answer as to whether they’re struggling to keep up with the automation scripts they have written.
The people around them, however, those with the problem, will say they hate this. “These guys promised me a solution. Now we have this automation hub. I thought it would provide me with a solution, but I'm as powerless as I was before”.
The problem with the type of automation that’s being introduced is that it’s synonymous with programming. This solution doesn’t solve the problem. It exacerbates it. Employing more developers to script automation and using open-source solutions because they’re cheaper is just like slapping a bandage on a problem.
Given this situation, how can we push the conversation with management towards a new approach to test automation, and avoid getting sent down to the basement.
Read more: What is scriptless test automation?
Too often in the journey towards adopting a new solution in an organization, we get delegated to the people we sound like. When you get hold of management, you give them the QA agenda, which in recent years has become focused on automation
But here’s the problem: that agenda isn’t necessarily suited to those with the lack of ability to get things up and running at the speed they want, when they need it.
Imagine you’re speaking to a car manufacturer. You say:
“I've noticed that your wrenches, you know, they're a bit… They're a bit soft around the edges. So when you turn them the bolts are not following suit. I think I've identified that this problem alone is costing you six dented bonnets down the road”.
And they'll go “look, I have a mechanic down there. Please go down and have a chat with him. I'm sure he'll be interested.”
That’s basically what’s happening to you when you push the QA agenda to senior management. The problem with this agenda is that when you’re talking to business people, they don't care. You’re not speaking their language. So what do they do? They send you down to the basement. In this case, down to the developers.
The issue with getting sent there is that the problem we claim to solve is not a problem for developers. They are the people who can code. When faced with the proposition of no-code test automation, they’ll say:
“What am I looking at this for? I can do automation. Why are you asking me this question? It probably won’t be as good as I am.”
Then they’ll typically start pinpointing things that it can’t do. The issue is that you’re talking to the wrong people.
Read more: Will no-code test automation solutions replace developers?
Imagine you’re back with the car dealer. Instead of focusing on the wrench, you say:
“Your competitor is pushing out new models every eight months, you're doing it in twenty. And your customer segments are complaining. Your assembly lines aren’t working as they should.”
This way, you’re speaking the right language. You’re speaking to their pains and you give them the chance to enter into a conversation.
But how do we translate that language for codeless test automation? We need to change the way we communicate. We need to adopt a new mindset. When people haven’t experienced the efficiency gains of codeless test automation yet, and haven’t felt benefits or improvements coming out of a codeless approach, it’s about defining the value of what codeless automation brings.
We need to have a conversation along the lines of:
“If you don’t have automation in place, why is this impacting your ability as a business or organization to achieve your goals? Are you able to reach your business targets? Are you able to obtain your strategic objectives?”
Rather than communicating how many bugs are in the software, you’re talking about how automation impacts larger business goals—like revenue.
What are those benefits? It accelerates the testing process. It reduces the amount of interaction between testers and code so that more members of a QA team can be brought into the testing process.
Adopting Leapwork’s unique, visual test automation language—which doesn’t require traditional resources—helps close the skills gap, reduce bottlenecks and deliver quality at speed. We need a whole new mindset, and we need to define the value of what another mindset can bring.
Using the link below, you can download our Test Automation Strategy Checklist. It can help you get your approach on the right track.
