Manual Testers Are Getting Promoted
Learn with AI
X (Twitter)
Learn with AI
AI isn't coming for the manual tester's job. It's coming for the worst parts of it. What's left is the part you love, the part that always mattered most. And it's about to matter a lot more.
There's a lot of talk right now about AI agents that can run the tests teams already have, keep them working as the application changes, and do it at a scale no team could staff. If you're a manual tester, I can guess what goes through your head when you read that. Great for the company. Where does it leave me?
It's a fair question, and it deserves a real answer.
The short answer
What AI changes for manual testers, at a glance:
- What AI takes on: the repetitive runs, the worst parts of the job.
- What stays with testers: defining what should be tested, deciding where the risk is, and judging the results.
- The mental shift: treat AI as a colleague you guide, not a tool you operate.
- For team leads: frame AI as added capacity, say where the freed-up hours go, and stop measuring executions.
Manual testers aren't being replaced. They're getting a colleague to handle the repetition.
The Fear Makes Sense
Manual testers have heard "this will replace you" before. Record-and-playback was going to do it. Then codeless automation. Then every wave of test automation tooling for twenty years. Each time, the manual testers were still there afterward, usually running the tests the automation couldn't handle.
This time does feel different, and pretending otherwise would insult everyone's intelligence. An agent that can read a test case and run it is doing something that looks a lot like what a manual tester does all day. If your value is measured in test cases executed per sprint, that's unsettling.
But that's exactly the problem. Executions per sprint was never a good measure of what a good tester is worth. It's just the easiest thing to count.
What the Job Becomes
Think about the best manual tester you've ever worked with. I'd bet what made them great wasn't how fast they clicked through a regression suite. It was that they knew the application better than almost anyone. They knew which flows users actually used, which features broke every time someone touched the payments code, and which "minor" bug was going to blow up in production. They noticed things nobody had written a test for.
That's the job that's left when the repetitive runs go away, and there's more of it than most teams have ever had time for. It comes down to three things.
-
Defining what should be tested. Someone has to turn a feature into clear, complete intent: what has to be true, for which users, under which conditions. That intent is becoming the most valuable asset in testing, and the people who know the application best are the ones who can write it.
-
Deciding where the risk is. Not every test deserves the same attention, and an agent doesn't know that the reporting module is where your biggest customer lives. Testers do.
-
Judging the results. An agent can tell you a step passed. A tester can tell you whether the outcome actually makes sense, whether that discount looks right, and whether the release is ready. That call doesn't get delegated.
A Colleague, Not a Tool
Here's the mental shift I'd encourage. Stop thinking about AI in testing as a tool you operate. Start thinking about it as a new member of the team, one you guide.
The difference matters. A tool sits there until you pick it up. A colleague takes work off your plate, tells you what it found, flags what it wasn't sure about, and asks before it changes something important. You don't operate a good colleague. You give them context, set expectations and review their work.
That's what working alongside a testing agent should feel like. You hand it the regression run on Thursday night. On Friday morning it tells you 412 tests passed, 6 failed, and 2 of those failures look like real defects rather than a moved button. It walks you through the evidence. You decide what goes to the developers. Then you spend the rest of your day on the exploratory session you've been putting off for three sprints.
It's also a colleague with some obvious gaps. It doesn't know your customers. It wasn't in the meeting where product said the checkout redesign is the thing the CEO cares about. It doesn't have the instinct that something feels off. That's your job, and it's the part of the job that was always hardest to hire for.
If You Lead a Testing Team
How this shift lands depends a lot on how leaders frame it. If AI shows up as a cost-cutting exercise, your best testers will read it as a countdown and start updating their resumes. If it shows up as added capacity, and as a chance to finally do the work they were hired for, you get a very different team.
A few things help. Be explicit about where the freed-up hours go: refining requirements so they turn into better test cases, more exploratory testing, deeper risk analysis, and earlier involvement in design reviews. Invest in the skills that are becoming more valuable, especially writing clear test intent and reviewing an agent's work critically. And change what you measure. If you keep counting executions, you'll keep getting people who optimize for executions.
AI can now take on more of the testing load than ever. Testing capacity no longer has to grow one hire at a time. Manual test libraries are automation waiting to be set free. The durable part of a test is its intent, not its script. None of that works without people who know what good looks like.
Manual testers aren't being replaced. They're getting a colleague to handle the repetition, and a job description that finally matches what the best of them were doing all along.
Frequently asked questions
Will AI Replace Manual Testers?
No. AI is taking on the repetitive parts of the job, like running the same regression steps again and again. What remains is the work that depends on knowing the application: defining what should be tested, deciding where the risk is, and judging the results. Earlier waves of tooling, from record-and-playback to codeless automation, were also expected to replace manual testers. Each time, the testers were still there afterward, often running the tests the automation couldn't handle. For the data behind this, see Will AI replace manual testers?
What Does a Manual Tester Do When AI Runs the Repetitive Tests?
They spend more time on the three things an agent can't do for them: defining what should be tested, deciding where the risk is, and judging the results. In practice that means refining requirements so they turn into better test cases, more exploratory testing, deeper risk analysis, and earlier involvement in design reviews.
Which Skills Matter Most for Manual Testers Working With AI?
Writing clear test intent and reviewing an agent's work critically. Intent means spelling out what has to be true, for which users, under which conditions, and the people who know the application best are the ones who can write it. Reviewing means checking whether an outcome actually makes sense, not just whether a step passed. See reviewing AI-generated test cases for how that review works in practice.
Why Treat AI as a Colleague Instead of a Tool?
A tool sits there until you pick it up. A colleague takes work off your plate, tells you what it found, flags what it wasn't sure about, and asks before it changes something important. With a testing agent, you give it context, set expectations and review its work, instead of operating it step by step. It also has gaps: it doesn't know your customers, your priorities or the instinct that something feels off, and that part stays with the tester.
How Can QA Leaders Introduce AI Without Losing Their Best Testers?
Frame it as added capacity, not cost-cutting. Be explicit about where the freed-up hours go, invest in skills like writing test intent and reviewing an agent's work, and change what you measure. If AI arrives as a cost-cutting exercise, your best testers will read it as a countdown. If it arrives as a chance to do the work they were hired for, you get a very different team. For more on the capacity side, read AI Gave Developers More Capacity. Testers Are Next.
Why Is Test Execution Count a Poor Measure of a Tester's Value?
Executions per sprint is just the easiest thing to count. It says little about what makes a tester valuable: knowing which flows users rely on, which features break when the payments code changes, and which minor bug could blow up in production. If you keep counting executions, you keep getting people who optimize for executions.
|