Is manual testing dying?

Here is the position this page defends. The activity of testing by hand is becoming more valuable per hour and is required in fewer total hours. Human judgment about risk is genuinely irreplaceable. But irreplaceable work still gets concentrated into fewer, more senior people. A team that once needed five manual testers to get through a regression cycle now needs one strong tester with judgment, plus a suite. That's excellent news for the one and difficult news for the other four.

If you are a manual QA engineer with a few years of experience, the question you actually care about is not philosophical. It's whether to spend the next year of evenings learning to code. The answer is yes — and the reason is not that manual testing is worthless. It's that "manual tester" is no longer a defensible position to hold on its own, and the people who stay there are competing for a shrinking number of seats against everyone else who stayed there.

What has actually changed

Three things, none of them "AI replaced testers".

Regression execution got automated, slowly, over fifteen years. This isn't new and isn't AI. The share of a QA team's week spent re-running known scenarios by hand has been falling for a long time — and that work was the volume employer of manual testers.

Test artefact production got cheap. Writing test cases, filling out a test plan template, drafting a traceability matrix, generating a hundred input permutations. An LLM does that in seconds at roughly the quality of a mid-level tester's first draft. If a meaningful part of your visible output was documents, your visible output just became commoditised. This is the change that happened fastest and hurt most, because documents were how many testers demonstrated they were working.

Automation got much easier to start. Writing a first Playwright test is far less painful than writing a first Selenium test was, and AI assistance flattens the beginning of that curve further. The consequence is not that automation engineers are obsolete. It's that "I can write a basic UI test" stopped being a differentiator, and the bar moved up to framework design, flake, CI, and knowing what not to automate.

Notice that none of these removed the need to decide what matters. They removed the need for humans to do the mechanical parts around that decision.

What AI is genuinely bad at

Knowing what "wrong" means here. A model can tell you the button is misaligned. It cannot tell you that a 200ms delay on this particular screen will cause support tickets, because this is the screen where users enter payment details under time pressure. That knowledge lives in the heads of people who watched it happen.

Deciding what not to test. The hard skill in QA has always been subtraction. Given four hours before release, what do you check? Models are biased toward comprehensiveness and produce enormous, undifferentiated suites. Someone has to say "these eleven cases matter, delete the rest" — and be right, and be accountable for being right.

Testing across the seams. Most expensive production bugs live between systems: the payment provider's webhook arrives twice, the timezone converts wrong between two services, a retry creates a duplicate order. Finding those requires holding a mental model of the whole system, including the parts nobody documented.

Being accountable. Someone signs off on the release. "The model said it was fine" has never been an acceptable answer to an incident review and won't become one.

There is evidence the ambition is running ahead of the deployment, too. The World Quality Report 2025–26 found the large majority of organisations pursuing generative AI in quality engineering while only a small fraction have scaled it enterprise-wide, with reliability and integration among the main blockers. Most teams are piloting. Pilots need people who understand testing to evaluate them.

The uncomfortable part

The section above is where most articles stop, and it's where they become dishonest by omission.

"Exploratory testing is irreplaceable" is true. It does not protect your job. Exploratory testing is a high-skill, low-headcount activity: a product that needed a team of six for scripted regression might need two people doing serious exploratory work. The work is more interesting, more valuable, better paid — and there is less of it. Being irreplaceable in aggregate is not the same as being individually hard to replace.

Second, exploratory testing is not a junior activity. It's usually the most experience-dependent thing a tester does. So the safe ground is real, but it's uphill from where a lot of people are standing, and pointing at it as reassurance without saying "and here's the climb" is not helpful.

Third, the market increasingly asks manual testers to prove technical credibility before it will listen to their judgment. This is partly unfair — judgment doesn't require Python. But hiring processes need a filter, and code is a legible one. Being able to read the codebase, query the database, inspect the network tab and write a script also makes your judgment better and your bug reports much harder to dismiss.

So what should a manual QA actually do

Not "learn automation" in the abstract. That advice has been given for a decade and hasn't worked, because it has no sequence and no way to tell whether you're progressing.

Learn one language properly. Python or TypeScript. Properly means you can solve a problem you haven't seen before, not that you finished a tutorial. Most people who stall, stall here — they jumped to Selenium before they could write a loop with confidence, then spent a year copying snippets they couldn't debug. The Code Lab exists for exactly this: writing and running real code, without a reference solution open in the next tab.

Build one thing that exists. A small framework testing a real public site, in a repo you can send someone. Config for two environments, some API setup so UI tests don't log in through the form every time, a CI run on push. This single artefact does more in an interview than any certificate, because it's checkable. Drill the locator half of that skill in the Locator Lab.

Get technical about the job you already have. Read the logs. Learn the schema. Reproduce a bug via API instead of the UI. Ask for the ticket before the build. None of this needs approval, and all of it is material for interview answers about impact.

Use AI as a fast collaborator, not an oracle. The testers doing well with it treat it like a very quick junior: ask it for the first draft, then be the person who knows which parts are wrong. That role only exists if you understand the domain well enough to review the output. It rewards experience rather than replacing it.

Stop describing yourself as a manual tester. Not as a trick — because the useful framing is what you're accountable for, not the tool you use. "I own the quality of the checkout flow" is accurate and doesn't put you in a category people are actively filtering out.

What this looks like in twelve months

Realistically, with a full-time job and most evenings: a few months to get genuinely comfortable writing code, a few more to build UI and API automation you actually understand, then a stretch on architecture, CI and interview preparation. Call it six to twelve months to be interviewable for an automation or junior SDET role, with the range coming down to how consistently you can protect the hours rather than how smart you are.

The people who don't make it usually don't fail at any of the technical content. They fail at sequence. They restart four times, each time from a different YouTube playlist, and after a year they have four partial foundations and no proof of any of them. That failure mode is the reason the roadmap is ordered and finite instead of a content library.

The honest summary of the position

Manual testing as a skill is appreciating. Manual testing as a job title is depreciating. Whether that's good or bad news for you personally depends entirely on whether your value is in the judgment or in the execution — and on whether you can demonstrate the judgment to someone who has never met you. Where the two roles land after the transition is mapped in SDET vs QA engineer.