Digivante CEO Conor Whelan has spent years working with digital teams on the QA behind website launches, migrations and major transformation projects. Here, he shares why he thinks businesses often start the QA conversation in the wrong place, and why the project itself should come first.
There's a fairly common problem I keep seeing with digital teams. You've got a project coming up, the development resource is there, there's a deadline attached to it and then you get to the question of who's actually going to manage the QA.
It might be a replatform, a new checkout, a migration, a big release or something that's been sitting on the roadmap for months. Whatever it is, your existing QA team is normally already doing a job. They're looking after BAU, releases and everything else the business is working on, so adding another project doesn't suddenly give them another 20 or 30 hours in the week.
You could hire somebody, but if the problem exists for the next two or three months rather than the next three years, that doesn't necessarily make much sense either.
I think this is where we sometimes start the conversation in the wrong place with QA, because we jump straight into what type of testing a business needs before we've properly understood the project.
If you came to me and said you've got a replatform happening over the next eight weeks and you're worried you don't have enough QA resource to cover it, my first question wouldn't be whether you want exploratory testing.
I'd want to know what you're building, what resource you've already got, where you think the gaps are and what you're actually trying to get live.
An experienced QA person coming into that project should be able to look at the requirements, speak to the product owner and development team and start questioning things before you even get to execution. Are the requirements actually clear? Has something obvious been missed? Have product and development understood something differently? Where is the risk in what you're changing?
Once you've got that right, you can build the test plan and decide what you actually need.
It might turn out that your existing team can execute most of it and what you've really been missing is somebody to take ownership of the QA and manage the process. You might need additional people for a few weeks. You might need accessibility or performance testing. If you're launching into new countries, you may need people in those markets testing the local experience and making real payments with local payment methods.
You might need exploratory testing across a wider range of devices and real customer scenarios.
Usually it's not one thing.
That's why I've increasingly come back to the idea of having an experienced QA person who can slot into the project and has a much bigger set of capabilities sitting behind them.
If they work out that you need 50 people testing something across different countries and devices, we can provide that. If you need localisation and live payments, that's there. If you need accessibility expertise, performance testing or exploratory work, that's there as well.
But you don't need to know all of that when you first ask for help.
You can simply have a project that needs delivering and a gap in the QA resource or expertise available to deliver it.
For me, that's also where the flexibility becomes important. A lot of businesses don't want another permanent person and they don't necessarily want to sign a big annual outsourcing agreement either. They might need somebody for a few days a week, or they might have a project that needs additional support for a month or two and then doesn't.
There's no reason external QA support shouldn't work like that.
AI doesn't really change the problem
Obviously AI comes into this because it's changing development incredibly quickly.
Developers are already able to produce far more code using these tools and we're going to see the same thing happen in testing. AI can already generate test cases, help write scripts and automate parts of the process, and that's going to get much better.
We should use it. What I don't agree with is the jump from "AI can generate test cases" to "AI can manage the QA for this project." They're not the same thing.
I can take a requirement now, put it into Claude and ask it to write me a set of test cases. It will do it.
What it doesn't know is whether the requirement I've given it is any good.
If we've forgotten something, it doesn't necessarily know we've forgotten it. If the requirement is ambiguous, somebody needs to question it. Somebody needs to speak to the product owner, understand what development is actually building and make sure all of those things line up.
That's a very different job from generating a test script.
I'm sure AI will get much closer to doing that eventually. If you've got AI connected into your requirements, development environment, testing, analytics and everything else, then you can start to imagine a system that understands far more of the whole picture.
But we're not there today, certainly not consistently enough that I'd hand over the QA of an important ecommerce project and assume it's all going to work.
And if AI can do part of the job better or faster, then use it. I don't see any value in getting a person to spend half a day writing something that AI can reliably produce in five minutes.
It just becomes another tool available to the person managing the QA.
The bit I think matters is having somebody who knows when to use it, when not to use it, what else the project needs and when something doesn't look right.
It's the project you're trying to deliver
This is the bit I think we sometimes lose sight of when we talk about testing.
Nobody particularly wants to buy testing.
You've got a website to launch. You've got a checkout change that needs to go live. You're moving platform. You're expanding internationally. You've got a project with a deadline and somebody in the business needs to get it delivered. Testing is part of getting there.
So if you've got all the QA resource and expertise you need internally, great. You probably don't need us.
If you've got a project coming and there is a gap, that's where I think an external partner becomes useful.
Bring somebody in who can understand what you're trying to deliver, work with the team you've already got, get the QA organised and then bring in additional capability where the project actually needs it.
That could be people, specialist testing, a crowd, automation or increasingly AI.
It doesn't really matter which until you understand the project.
That's probably the biggest thing for me. Start with what you're trying to get over the line, not with which testing service you think you need to buy.
