What a QA Lead Actually Does When Test Cases Are Free

A QA lead at a mid sized SaaS company opens her sprint on Monday and finds forty new test cases waiting in the tracker. Nobody on her team wrote them. An AI model read the ticket, looked at the existing suite, and generated them overnight.

Three years ago this would have taken her two engineers most of a week. Now it costs a prompt and a coffee break. That sounds like a win, and in one sense it is. But it hands her a different problem than the one she used to have. This post is about quality engineering with AI generated test cases, and specifically about what that new problem actually is.

Qase has argued, correctly, that quality is engineering. That framing is true and it is also incomplete. It answers the question of whether QA deserves a seat at the table. It does not answer the question of what QA people do once the seat is theirs and the typing is gone.

The bottleneck used to be writing, now it is deciding

For most of the history of software testing, the limiting resource was labour. Someone had to sit down and write out steps, expected results, edge cases. A 900 case regression suite represented weeks of somebody's attention.

That scarcity shaped the whole discipline. Coverage targets, case counts, and sign off checklists were all built around one assumption: producing a test case was expensive. Teams rationed testing effort the way they would ration any expensive resource.

Generation breaks that assumption. When a model can produce forty plausible cases from a ticket in under a minute, the cost of producing a case drops close to zero. What does not drop to zero is the cost of knowing whether a given case is actually true. Does it describe the correct behaviour for this feature, in this account state, for this customer segment.

That judgement call is now the scarce resource. It did not get any cheaper just because the typing did.

Concretely, the shift looks like this. Before, a QA lead's week was dominated by writing new cases and maintaining old ones. Now her week is dominated by reading a pile of generated cases and deciding, one by one, which of them describe real, correct behaviour.

The confidently wrong ones are the dangerous kind. A generated case can assert that a refund should silently succeed on a cancelled subscription. It reads exactly as tidy as a case that is correct. Nothing in the formatting tells you which one it is. Only someone who knows the product can tell.

What this does to the QA role, day to day

The honest version of this change is not that the job gets easier. It gets different, and in some ways harder, because reading critically is slower and more tiring than writing from a template.

Typing from a checklist is mechanical work. Deciding whether an assertion is true requires holding the whole feature in your head, including the edge cases nobody wrote down.

A QA lead's day now looks less like typing and more like this:

• Reading a batch of generated cases against the actual ticket and the actual product, not against what sounds plausible
• Deciding, case by case, whether the asserted behaviour is the behaviour the team actually wants
• Rewriting or rejecting the cases that are wrong, and noting why, because the reason matters later
• Spending the time saved on writing to instead go find the behaviours nobody thought to generate a case for at all

That last point deserves its own attention. Generation is good at producing cases for behaviour that is already described somewhere, in a ticket, a spec, an existing test.

It is much weaker at surfacing the behaviour nobody wrote down because everyone assumed it was obvious. Finding that gap is a judgement task. It does not get automated by the same tool that automated the typing.

If anything, that gap finding work becomes more important once generation is cheap, because a team that trusts generated coverage completely will stop looking for the gap at all. The habit of asking "what did we not think to write down" has to survive the arrival of the tool that makes writing things down effortless.

Why the decision needs to leave a record

If the argument above is right, and the valuable thing a QA lead does is decide which generated case is true, then that decision is the actual work product. Not the case text itself, which the model wrote. The decision.

Here is the problem. A decision that lives only in someone's head is indistinguishable, six months later, from a decision nobody ever made. Say a generated case slips through unreviewed and it later turns out to describe the wrong behaviour.

There is no way to tell whether a person looked at it and missed the flaw, or whether nobody looked at it at all. Those are very different failures with very different fixes. One means the reviewer needed better context or more time. The other means the review step got skipped entirely.

Without a record you cannot tell them apart, and you end up fixing the wrong problem. That is why the record of the decision has to exist: who reviewed a given case, what they changed, when they approved it.

It has to live somewhere outside the model's output, as an artefact a person can point to and say: I looked at this, and here is what I decided.

Without that artefact, the judgement that is supposedly the valuable part of the job is invisible. Invisible work does not survive a headcount review. It does not survive an audit. It does not survive a postmortem when something generated slips through and a customer notices before your team does.

Where this argument gets weaker

This case is strongest for teams whose main risk is correctness: does the feature do the right thing for the right customer in the right state. It gets noticeably weaker for teams whose main risk is availability or performance instead.

Suppose your worst outage last quarter was a database connection pool exhausting under load, rather than a feature behaving wrongly. In that world, the scarce judgement is not "is this generated case true." It is closer to "will this hold up at ten times the traffic."

That is a different kind of question. Load testing and observability answer it better than a reviewed functional test case ever could.

For those teams, AI generated functional test cases are still useful for the correctness slice of their risk. But they are not the main event. Framing everything around case by case judgement would undersell the work that actually keeps the service up during a traffic spike.

The honest scoping matters more than the pitch. A QA lead running a payments feature with complex business rules should weight this argument heavily. A QA lead running a high throughput ingestion pipeline should weight it much less, and spend the saved time on load and chaos testing instead.

Think of it as a dial rather than a switch. The more a feature's risk comes from getting the logic wrong for a specific customer, the more this framing applies. The more the risk comes from too many customers at once, the less it applies, and the more the team should keep investing in the kind of testing that generation cannot help with at all.

Where to read next

This post has been about where the work goes, not about how many people do it, and that boundary is worth stating plainly. Nothing here predicts job losses or headcount changes. It describes a shift in what the remaining hours get spent on, not a shift in how many hours exist.

We have written elsewhere about the broader shape of AI in software testing, covering how generation, execution, and analysis are each changing at a different pace and on a different timeline. We have also written separately about whether AI will replace QA as a discipline, which asks the labour market question this post deliberately leaves alone.

Both are worth reading if this shift is one your team is living through right now, rather than reading about it from a distance. The practical version of this argument only really lands once you have watched a pile of generated cases show up in your own tracker and had to decide, one by one, what to do with them.