Talk to any developer who has been using an AI coding assistant for a few months, and you'll hear some version of the same thing: "I'm getting through a lot more than I used to." Same person. Same hours. More output.
Now ask a QA manager how they're keeping up with all that extra output. You'll usually get a tired laugh, followed by: I'm not. And I can't hire.
That's the gap I want to talk about. Development is finding ways to grow its capacity without growing the team. Many QA teams are still struggling to do the same. I think they can, and sooner than most expect. Not by replacing testers, but by handing AI more of the repetitive work that eats their week. That's the real promise of AI for manual testing.
You probably know this moment. Development wraps up on Wednesday. The release is planned for Friday. Regression takes eight days. The tests are all written down, some of them in painful detail. There just aren't enough people to run them in two days.
So the conversation turns to the usual three options:
Adding people buys capacity. Risk-based testing makes better use of what you have. But neither changes how much repetitive work each test requires. What that meeting is missing is a way for the existing team to get more done.
Look at the rest of the software lifecycle. In the cloud, adding infrastructure capacity can be an API call. Builds and deployments used to eat somebody's whole Tuesday. For many teams, they now happen on every commit. And coding assistants are helping developers get through work that once required more hours.
The 2025 DORA research found a positive relationship between AI adoption and software delivery throughput, but a negative one with delivery stability. More speed doesn't automatically mean a stronger release. The controls around that speed still matter.
Testing has automation too, of course. But the workload keeps compounding:
For teams with large manual suites, each of those can still turn into more human hours: someone to run the tests, someone to automate them, and someone to fix the automation when it breaks.
When development output grows faster than a team's ability to check it, a velocity-quality gap opens up. It's where release risk builds, usually without anyone deciding to accept it.
That pressure isn't just anecdotal. In Katalon's State of Software Quality Report 2025, 55% of QA individual contributors using AI, and 57% of those not using it, identified insufficient time for thorough testing among their top three challenges. Using AI alone isn't enough. What you hand over to it matters.
And here's what makes it frustrating. It isn't just a knowledge problem. Your team already knows a great deal about what to test. It's in your test management tool, your spreadsheets and the heads of testers who have lived with the product for years.
What you're short on is attention, and too much of it goes to running the same steps for the fortieth time, translating test cases into scripts, and chasing a "failure" that turns out to be a button someone renamed from Submit to Continue.
Here's where I believe the shift happens. Three jobs in testing grow with every release. AI can reduce the routine work in the first two. The third is where I want your people to have more time.
| The Job | Where AI Helps | What Stays With Testers |
|---|---|---|
| 1. RUNNING THE TESTS YOU ALREADY HAVE | Executes natural-language test steps, checks expected results and records evidence, including unattended runs | Writing and sharpening test cases, reviewing what the agent did |
| 2. KEEPING IT ALL WORKING | Adapts to interface changes or suggests updates, organizes failure evidence and suggests a likely cause | Confirming the diagnosis, approving changes to a test's intent and expected results |
| 3. JUDGMENT | Informs decisions with steps, screenshots and results to inspect | Deciding what's worth testing, where the risk sits, what to explore next and whether the release is ready |
Every team I talk to has the same thing sitting in their test management tool: hundreds, sometimes thousands, of manual test cases. They might not always be up to date, but they're how a new tester starts to understand the application. Many remain unautomated because turning them into scripts takes dedicated engineering time and ongoing maintenance.
What's changed with AI for manual testing is that an AI agent can now read a test case in plain natural language and execute its steps in a supported application. It checks the expected results and records evidence of what it did. These are still the team's manual test cases, but a person no longer has to perform every action. The test case stops being just a to-do item for an automation engineer. It becomes the instructions the agent runs.
Your testers don't disappear from this picture. They use AI to write and sharpen the test cases, expanding coverage. And they review what the agent did. If that sounds familiar, it's because it's what developers are doing with their AI coding agents: describe what you want, then review what comes back.
Once a test can run without a person driving it, another constraint starts to loosen. For a suite run entirely by hand, execution capacity is roughly the number of testers multiplied by the hours left before release. Each tester can only work through so many cases. That's how you get to eight days.
Unattended execution can use hours when nobody is at their desk. Where parallel execution is supported, independent tests can run side by side. Available concurrency, supported environments and test data still set limits. But you no longer have to match every additional run with another block of a tester's time.
Meanwhile, your testers spend more of their time reviewing evidence and investigating uncertainty, rather than clicking through the same steps again.
Anyone who has owned a test suite knows this one. Somebody redesigns a page or renames a button, and the next morning your scripts are red. Sometimes the application is fine. The tests just can't find their way anymore. As suites grow, fixing them quietly becomes a major automation job.
An agent guided by what a test is meant to prove, not just which element to click, can help here. Depending on the tool, it may adapt to a changed interface during a run or help identify an update for a tester to review. AI can also organize the evidence from a failed run and suggest whether the problem lies in the application, the environment or the test itself.
But finding a new button is not the same as deciding that a new result is correct. A suggested fix still has to earn trust. Testers need to confirm the diagnosis and approve changes to the stored test's intent and expected results. Otherwise, "healing" can turn into teaching a test to overlook a real regression.
The opportunity is less time spent chasing broken steps and more time deciding which fixes are right. That's a much better use of a Tuesday.
This is where the hours from the first two should go.
Deciding what's worth testing, where the risk sits, what to explore next and whether the release is ready: that's the work that needs experience and context. AI can inform those decisions. It doesn't take responsibility for them, and I'd be suspicious of anyone who told you it did.
It's also exactly the work that gets squeezed when everyone is heads-down running regression. With steps, screenshots and results to inspect, testers can make those calls with more to go on. But a passing check is still evidence about that check, not proof that the whole release is ready.
To put this into practice:
And count all the work: execution, review and maintenance. Track that effort alongside:
The question isn't whether the agent can click faster. It's whether your team gets dependable capacity back.
Put it together and what you scale by starts to change. More releases, more features and more configurations don't have to mean proportionately more repetitive work for your testers. They can mean more runs handled by AI, with your team steering.
That's the deal many developers are getting right now. A developer with an AI assistant isn't doing less. They're getting more done in the same hours. I think testers deserve the same deal, and I'd think of it less as a new tool and more as an extra pair of hands on the team for the repetitive work.
To explore AI-led execution, take a look at the AI Test Runner in Katalon TestOps, part of Katalon True Platform, which executes natural-language test steps and captures step-level evidence in supported configurations.