Home / Blog / AI in Software Testing: What It Can and Cannot Do

AI in Software Testing: What It Can and Cannot Do

By Mike Krasnovskyi, Head of Automation at QA Madness · Published 2026-09-10

Dark violet illustration of a test case panel with generated input rows filled in and the expected-result row left blank and highlighted.

AI is reliable in software testing wherever a person still supplies the definition of correct, and unreliable wherever it has to invent that definition itself. That one line predicts most of what works in 2026: drafting cases from a written specification, clustering a wall of failures into a handful of probable causes, finding duplicates in a suite nobody has pruned in three years, turning a messy bug report into a reproducible case. It also predicts the failures. Point a model at an implementation and ask for tests, and it will treat whatever that code does as intended behaviour, including the defect you were hoping to find. The limit is not task difficulty and it is not model size. It is whether the information the model needs was ever written down.

This article maps AI capability across QA work by that criterion: what holds up without a reviewer, what only counts after a competent review, and what does not work at all for reasons that better models will not fix. Where there is measured evidence, it is cited with its scope. Where the honest answer is that it depends, the article says what it depends on.

The oracle problem is the dividing line

Every test does two things. It puts the system into a state and applies a stimulus, and it decides whether what came back was right. The second half is the test oracle, and it is where automated test generation has been stuck since long before language models existed. Generating plausible inputs is comparatively easy. Knowing that a discount of 12% on a 40-euro basket should produce 35.20 and not 35.19, and that a negative basket total should raise an error rather than clamp to zero, requires knowing what the business decided. A model reading the code sees only what the code does.

That gap has now been measured directly. A study accepted at ISSTA 2026 by researchers at the University of Toronto ran 13 model configurations, including Claude 4 Sonnet, Gemini 2.5 Pro, GPT-4.1 and DeepSeek-R1, over 318 buggy methods drawn from 233 real defects in the Defects4J benchmark, then executed every generated test against both the buggy and the fixed version of the code. When the models were prompted with the buggy implementation, an average of 3.84% of the tests they produced passed on the buggy version and failed on the fixed one, meaning those tests asserted the defect as correct behaviour. Prompted with the fixed implementation, that figure fell to 0.46%. The damage runs in both directions: tests that actually caught the bug made up 2.98% of output from buggy code against 8.51% from fixed code, close to a threefold reduction in bug-finding power.

Two details in that result matter more than the headline. First, the authors found the models with the strongest code comprehension were also the most susceptible to being misled, because a model that reads implementation intent well reads a bug as intent. Second, their mitigation was not a better prompt bolted onto the same input. It was removing the code from the prompt entirely and replacing it with a generated behavioural specification. Supplying the specification alongside the code barely helped. The implementation, when it is visible, wins.

The practical translation for a QA team is uncomfortable and useful. Tests generated from an application's current behaviour are regression tests, not correctness tests. They tell you that something changed. They cannot tell you that anything was ever right. That distinction is fine when you are locking in behaviour before a refactor, and it is close to worthless when you are validating a new feature against what the product manager actually asked for.

Here is the shape of it in the smallest form that still shows the failure:

// implementation under test, with a rounding defect
function lineTotal(price, qty, discountPct) {
  const gross = price * qty;
  return Math.floor(gross * (1 - discountPct / 100));
}

// what a model generates when it reads the implementation
expect(lineTotal(9.99, 3, 10)).toBe(26);   // asserts the truncation

// what a model generates when it reads the pricing rule instead
expect(lineTotal(9.99, 3, 10)).toBe(26.97); // fails, and should

Both tests compile, run and look professional in review. The first one passes, which is exactly why it gets accepted. A reviewer skimming for syntax approves it; a reviewer who knows that prices round to the nearest cent catches it in four seconds. The whole question of whether AI helps or hurts a test suite sits in which of those two reviewers you actually have.

A map by activity

The table below is the short answer for each kind of QA work. The rows are not equally important, and the sections after it explain the ones that carry the most weight.

QA activity	Works without a specialist reviewer	Only counts after review	Does not work
Test design from a written spec or ticket	Producing candidate scenarios, boundary values, negative paths you had not listed	Every expected result; scope and priority of what was produced	Inferring requirements that were never written down anywhere
Test design with no spec	Nothing	Recovering probable intent from code and naming, as a draft to interrogate	Distinguishing intended behaviour from a long-standing defect
Unit and API test generation	Scaffolding, fixtures, parameterisation, filling in obvious coverage gaps	Assertions, error-path expectations, anything touching money, time zones or permissions	Deciding which behaviours are worth pinning down at all
UI automation authoring	First-draft page objects, selector suggestions, converting recorded steps into structured code	Waiting strategy, test isolation, data setup and teardown	Judging whether a flow makes sense to a user
Locator repair and self-healing	Proposing a replacement selector after a DOM change	Whether the element it found is the element the test meant	Telling an intentional redesign apart from a regression that broke the page
Failure triage on a large run	Clustering failures by likely cause, deduplicating, ranking by blast radius, drafting the bug report	Root cause attribution before anyone files it against a team	Deciding whether the failure blocks the release
Suite maintenance	Duplicate detection, dead-case detection, tagging, normalising titles and structure	Deletion. Always deletion	Knowing which barely-used case covers the one contract the audit will ask about
Test data	Synthetic records that satisfy a schema and stated constraints	Referential integrity across systems, and anything derived from production data	Guaranteeing a distribution matches real user behaviour
Exploratory testing	Generating charters, heuristics and variation ideas before a session	Which anomalies from the session are worth chasing	The session itself, which is a learning loop, not an execution loop
Usability, tone and accessibility judgement	Flagging mechanical accessibility violations that a linter would also catch	Suggestions about wording, contrast, flow order	Deciding whether an experience is acceptable for the people who use it
Release decisions	Assembling the evidence: what ran, what failed, what is untested, what changed	The summary, before anyone acts on it	Owning the go or no-go

What holds up: reshaping material that already exists

The strongest results come from a pattern that gets less attention than test generation: giving a model something that already exists and asking it to restructure, compare or compress it. There is no oracle to invent, because the correct answer is already present in the input.

Failure triage is the clearest case. A regression run of a few thousand automated tests fails in clusters, and the clusters are usually four or five underlying causes wearing several hundred different stack traces. Grouping those by similarity, spotting that 90 of them share a timeout on the same endpoint, and drafting a report with the shared evidence attached is work a model does quickly and consistently, and the cost of an occasional wrong grouping is small because a human opens the cluster anyway. The same applies to finding duplicate and near-duplicate cases in a test base that has grown through five reorganisations, and to migration work where fields have to be mapped between two schemas.

Drafting from a written specification is nearly as strong, with one condition: the specification has to actually specify. A ticket that says "user can reset password" yields generic cases you already knew. A ticket that says the reset link expires after 30 minutes, is single-use, and must not reveal whether the email address exists, yields a set of negative cases worth reviewing, including a couple most people forget on the first pass.

The best-documented industrial result for generated tests still comes from Meta's TestGen-LLM, reported in 2024 on Kotlin unit tests for the Instagram and Facebook codebases. Of the test cases it produced, 75% built correctly, 57% passed reliably, and 25% increased coverage. In test-a-thons on those products the tool improved 11.5% of the classes it was applied to, and 73% of the recommendations it put in front of engineers were accepted into production. Read the first three numbers together and the lesson lands: roughly a quarter of output was worth keeping, and the reason the deployment succeeded is that Meta built an assurance pipeline that discarded anything that did not build, did not pass repeatedly, or did not measurably raise coverage before a human ever saw it. Most of that result belongs to the filters. Any team getting a small fraction of value from generated tests without an equivalent filter is paying the review cost on the whole 100%.

The review is the expensive part, and it is usually unbudgeted

Adoption is no longer the interesting variable. The World Quality Report 2025-26 from Capgemini, Sogeti and OpenText, based on a survey of more than 2,000 senior executives across 22 countries and 10 sectors, found 89% of responding organisations piloting or deploying generative AI in quality engineering, with 37% in production. Only 15% had reached enterprise-wide implementation. Reported gains averaged 19% productivity, and about a third of respondents saw minimal gains. Among the barriers respondents named, hallucination and reliability concerns came in at 60%, behind data privacy at 67% and integration complexity at 64%.

Those numbers describe a verification cost that most plans leave out. Google's 2025 DORA report, surveying nearly 5,000 technology professionals in mid-2025, found 90% using AI at work and more than 80% saying it raised their productivity, while 30% reported little or no trust in AI-generated code. The same report found AI adoption correlating with higher delivery throughput and with higher instability, which is what happens when more change flows through a review and release process that was not resized to match. Stack Overflow's 2025 survey of 49,009 developers put a name on the daily version of it: the single most common frustration, cited by about two thirds, is output that is almost right but not quite, followed by the time spent debugging it.

The most-quoted study on this is worth handling carefully, because it has been misused in both directions. METR's randomised controlled trial, run between February and June 2025 with 16 experienced open-source developers across 246 tasks in repositories they knew well, measured that tasks took 19% longer when AI tools were allowed. The developers had forecast a 24% speedup and, after finishing, still believed they had been 20% faster. The gap between measured and perceived is the finding that matters, and it is the one most likely to hold. The slowdown itself is not current evidence: in February 2026 METR published an update saying its follow-up experiment gave an unreliable signal, because a growing share of developers refused to participate in tasks where AI might be disallowed and 30% to 50% reported withholding tasks they especially wanted AI for. METR's own reading is that developers are likely more sped up in early 2026 than the 2025 estimate suggests, but that its data is weak evidence for the size of the change, and it is redesigning the experiment.

Take the honest version of all that into a QA plan and one number follows: whatever your team currently spends reviewing human-written test cases, generated volume will multiply the queue before it multiplies the coverage. Teams that come out ahead are the ones that treat review capacity as the constraint and generate against it, rather than generating first and discovering the constraint in the sprint after.

What AI does not do, and why that is not a matter of time

Some limitations shrink with each model release. Assertion quality, long-context reasoning over a large codebase, following a complex framework convention: those have improved measurably in two years and there is no reason to expect them to stop. Treating everything on the list below as the same kind of temporary is a mistake, because these fail for a structural reason. The information required is not in any artefact the model can read.

Intent that was never recorded. If the only place the rule about partial refunds lives is in the head of the person who negotiated it with the payments provider in 2023, no model can recover it from the codebase, the tickets or the test suite. It can produce something confident and wrong, which is worse than silence. This is the single most common cause of AI-generated tests that look excellent and validate nothing.

Missing behaviour. Absence is invisible to a model reading an implementation. A checkout that never validates expiry dates has no code to read, no failing test, no anomaly in the logs. Human testers find these by holding a model of what the system should do next to what it does. AI helps here only when the "should" exists as text it can be given.

Acceptable risk. Whether 40 open medium-severity defects block a release depends on the customer, the contract, the rollback story and how much goodwill the last outage consumed. An assistant can lay out the evidence well. It cannot own the decision, and in regulated work the sign-off has to attach to a named person regardless of how the evidence was assembled.

Judgement about people. Whether an error message helps or humiliates, whether a flow is confusing for a first-time user, whether a screen reader experience is dignified rather than technically compliant: these are evaluations against human experience, not against a specification. Automated accessibility checks catch the mechanical subset, and that subset has always been the small part.

Exploratory testing as a practice. AI generates good charters and useful variation ideas. The session itself is a loop in which what you learn in minute three changes what you try in minute four. The value is the learning, and it accrues to the tester who did it. Handing that loop to an agent produces coverage of paths, not understanding of the product.

The dividing line here has a practical consequence worth stating plainly. Where your organisation writes things down, models keep getting better at your work. Where it does not, the bottleneck is the organisation, and no procurement decision fixes it.

Where the gains leak away

Most teams that end up disappointed did not hit a capability limit. They hit maintenance debt, and it accumulates in four fairly predictable places.

Volume that nobody prunes. Generation is cheap and deletion needs judgement, so suites grow monotonically. A test base that doubles in a quarter without a review gate becomes slower to run, harder to trust and more expensive to migrate, and the second-order effect is worse: when a suite is too large to reason about, teams stop reasoning about it and start reading the pass rate as if it meant something. If you are already reporting on pass rate, it is worth reading which QA metrics survive contact with a management decision before you scale generation.

Baselines that lock in defects. This is the misguidance effect at organisational scale. Generate a regression suite from a legacy system's current behaviour and every existing bug becomes a green test. The bugs are now protected: the next engineer who fixes one gets a failing build and, in the average team, edits the test.

Self-healing that heals over the signal. Automatic locator repair keeps runs green through cosmetic DOM churn, which is a real saving. The same mechanism silently repairs a locator when a button moved because someone broke the flow. Unless repairs are logged, reviewed and rate-limited, the suite becomes optimistic in exactly the situations you built it for.

Review that degrades into rubber-stamping. The failure mode is quiet. Reviewers who have approved 200 correct generated cases approve the 201st without reading it, and the 201st is the one with the wrong expected result. Keeping a visible acceptance rate, and treating a rate near 100% as a warning rather than a success, is the cheapest control available.

None of these are arguments against using AI in QA. They are the reason the teams getting real value put the controls in before the volume, not after.

What this changes about where test artefacts live

Once a meaningful share of your cases, bug reports and run analyses starts as machine output, a few properties of your tooling stop being nice-to-have. You need to know which cases were generated and which were written, who accepted each one and when, and what the case looked like before the last edit. You need duplicate detection that runs across the whole base rather than the folder someone is looking at. You need automated results linked back to the manual cases they cover, or coverage reporting turns into two disconnected numbers. Spreadsheets and a wiki do not carry provenance, and a test management system that treats every case as anonymous text will not help you audit what the model did.

QAM Hub is built by QA Madness around that assumption. AI-generated cases and checklists arrive as drafts a person accepts, version history keeps the pre-edit state, and the Quality Analyzer scores the test base against run history and surfaces duplicates and low-value cases with the evidence attached, on the Advanced plan. Its MCP server, available on both plans, lets an agent such as Claude read and write test artefacts directly rather than through copy and paste, which is exactly the capability that makes review discipline necessary rather than optional. Agent Flows, our autonomous execution feature, is marked coming soon and will sit on the Advanced plan. If you are weighing up letting an agent write into your test management system at all, the trade-offs are set out in giving AI agents write access to your TMS.

What to prioritise, and what to leave alone this quarter

Start with triage and deduplication. They are the lowest-risk, highest-yield applications available, the review cost is small because a person opens the result anyway, and they pay back immediately on any suite that has been growing for more than a year. If your team does one AI thing this quarter, make it this.

Second, generation from written specifications, with an explicit review gate and a cap on how much you generate per sprint. Set the cap from review capacity, not from ambition. Track the acceptance rate from day one; it is the only early signal that tells you whether the output is worth the queue.

Third, and only once the first two are running, targeted generation against legacy code, framed honestly as regression pinning rather than validation. Say out loud in the ticket that these tests record current behaviour, so nobody six months later reads a green suite as evidence of correctness.

Leave two things alone for now. Do not put an agent in the path of a release decision, however good the summary looks. And do not try to replace exploratory testing with generated charters executed by a machine, because you will get a coverage report and lose the only activity that reliably finds the defects nobody predicted. Those are not permanent restrictions on the technology. They are the correct sequence for a team that wants the gains without buying the debt.

Frequently asked questions

Will better models solve the test oracle problem?

Partly, and only on one side of it. Where the intended behaviour exists in writing, in a specification, a contract, an API schema or a well-written ticket, models keep getting better at deriving correct expectations from it, and that improvement is real and ongoing. Where the intended behaviour exists only in someone's memory or in a decision nobody documented, there is nothing to infer from, and a more capable model produces a more convincing wrong answer rather than a right one. The Toronto study points the same way: their fix was changing what the model was given, not waiting for a better model.

Can we generate a regression suite for a legacy system with no documentation?

You can, and it can be worth doing, provided everyone understands what you are buying. Those tests pin current behaviour, defects included, so they protect you during a refactor and tell you nothing about correctness. Two things make the difference: label them as behaviour-pinning tests in the suite itself, and expect that when a fix later turns one red, the correct response is to change the test, not the fix. The research on misguidance suggests one more useful step, which is generating a plain-language description of what each component is supposed to do first, reviewing that description with someone who knows the product, and generating tests from the reviewed description rather than from the code.

How do we tell whether AI is actually helping our QA team?

Not by counting generated cases, and not by asking the team how it feels, given the size of the perception gap METR measured. Three signals carry weight. The acceptance rate of generated output tells you whether the drafts are good enough to be worth reviewing, and a rate that climbs toward 100% usually means review has stopped, not that quality has become perfect. Time from a failed run to a filed, correctly attributed defect tells you whether triage is genuinely faster. Escaped defects over a few releases tell you whether any of it reached the outcome. If none of those move after a quarter, the problem is more likely the review process than the tooling.