It doesn't work without the tester. That's the design.

Ask about AI in testing and the conversation goes straight to volume. How many test cases a tool generates, how fast, and from how little input. The question almost nobody asks is a different one. Who signs off that the thing was actually tested?

That is not a formality. When something breaks in production, nobody asks which model wrote the test. They ask who approved it, and on what basis.

So an AI-native QA layer needs an answer to that question, and that answer has to be a named person. Which means the product has to be built so that a person can genuinely give that answer. A queue that only needs clearing does not produce one.

Approval can be done two ways

Approving a draft that an AI generated can be a real decision. Or it can be a click that clears a queue.

This is a documented pattern. It has nothing to do with the tester's character. Ben Green's 2022 survey of 41 policies requiring human oversight of algorithms found two problems with them: people are largely unable to perform the oversight function they have been handed, and the requirement itself supplies "a false sense of security in adopting algorithms" while letting vendors and agencies "shirk accountability for algorithmic harms" [E7]. What was presented as the solution was the oversight itself.

That pattern has a name. Automation bias is "the thoughtless acceptance of decisions or recommendations made by the system" [E8], and it happens because accepting a recommendation is cheaper than investigating one. The output becomes a substitute for the work of checking, which is exactly the work it was supposed to make possible.

Software is not exempt from this. When AI iterates on its own code and nobody reviews in between, security degrades as the rounds accumulate. A 2025 study by Shukla, Joshi and Syed measured a 37.6% increase in critical vulnerabilities after just five rounds of AI "improvements", and the authors' own recommendation is mandatory developer review between iterations [E18]. A loop with no human in it drifts.

I have watched the same pattern play out in QA. An experienced, well-functioning team was suddenly flooded with hundreds of test cases waiting for review. They had not been written by testers, but by people with no experience writing tests. The structure was wrong, information was missing, and the expected result was written into the action step. Senior specialists spent hours fixing someone else's work, and sending the tests back to their authors only meant more waiting. So in the end they usually rewrote them.

Volume does much of the damage on its own. In a case-control study of code reviews on the Chromium OS project, the likelihood of a security defect being caught falls as the scope of the change grows [E9]. Test-case review is not code review, but the same limit applies: attention does not scale with the amount there is to review.

So the real risk of AI in QA is volume. It produces so much work to review that the review turns into a formality.

A tool that ignores this has not solved the problem, only moved it one step further down.

Two fixes that don't work

Two responses to this are obvious, and neither survives contact with the evidence.

The first is to make the reviewer accountable. If the person approving knows they own the outcome, surely they look harder. Kupfer and colleagues tested exactly that and found the opposite: responsibility for the decision "did not lead to higher scores on verification intensity indicators or higher objective and subjective decision quality" [E22]. Being answerable did not make people check.

The second is to show the reasoning. Explain why the system produced what it produced, and the reviewer can judge it. Here the research disagrees with itself, and it is worth saying so instead of quoting whichever side is convenient. Buçinca and colleagues found that adding explanations does not reduce overreliance and may even increase it [E10]. The opposite result exists too: explanations can reduce it [E19].

What settles the disagreement is why people engage at all. On the second account, people "strategically choose whether or not to engage", and explanations fail when they do not "sufficiently reduce the costs of verifying" [E19]. The variable is price, not willingness.

Which leaves two levers worth building. Make verifying cheap, and make deciding unavoidable.

A decision needs support, not just a button

The first draft of every test case is generated. The role of the model is narrow and fixed: it writes that draft, and it decides nothing. Testuvion is built so that a tester can decide quickly, and with real knowledge of what they are deciding on. Most of what follows either lowers the cost of verifying or makes deciding unavoidable. One piece does neither, and simply records who decided.

Source material comes first, test cases second. Testuvion takes the documentation you already have, connects it, and flags both the contradictions and the places where information is simply missing. Where the documentation is not enough, it maps the application itself and fills in what the documents left out. The tester does not inherit a queue of drafts built on a brief nobody checked.

Every step carries a traceable source. For each generated step, what it came from is visible. The tester compares the draft against the brief sitting beside it, instead of against their own memory.

The decision is made per output. Accept, reject or edit, on each test case separately, rather than one bulk yes over a batch nobody read.

The audit trail remembers who decided. Everything generated can be traced back to what it was based on, and to the person who approved it.

Underneath those four sits the one that does the real work. Generated test cases start unreviewed, which is to say they start with no standing at all. Executable tests can only be generated from test cases a human has accepted, and the server refuses the request for any other status. Approval here is not a checkpoint at the end of the line. It is the moment a draft acquires the standing to be used for anything.

What the tester gains

None of this makes the tester's job smaller, only more concentrated.

Transcribing a specification into test cases is work that requires no decisions. You move information from one document into another and try not to drop anything on the way. Nobody asks your opinion, and it still takes hours. Remove that, and what remains is the part the job was always supposed to be: deciding what is covered, what is risky, and what is missing.

There is a cost, and leaving it out would be dishonest. The designs that reduce overreliance most are the ones people like least. Participants in that same study gave "the least favorable subjective ratings to the designs that reduced the overreliance the most" [E10]. Per-item approval is slower than a bulk accept. A system that refuses to build on an unapproved draft is, in the moment, an obstacle. That friction is the design, not a side effect of it.

What the tester gets in exchange is a position they can defend. Sign off on a test case here and the source of every step and the identity of the approver are both on the record, months later, in front of whoever asks.

AI should not have the last word

AI in QA should not have the last word. It should have the first draft.

That is the whole argument. A generated test case is a proposal, and a proposal has no standing until a named person gives it some. Build the product so that giving it is quick and defensible, and the tester's judgement becomes the most valuable thing in the pipeline instead of the bottleneck everyone routes around.

Want to see it run against your own documentation? Book a walkthrough.

A note on how this was written. The draft was produced with AI assistance, and every claim in it was checked against its source by a person. That person is me. It seemed wrong to argue for this and then not do it.