Your team shipped a feature last sprint that was scaffolded by an AI coding assistant, tested by an AI test generator, and merged after a reviewer skimmed the diff for ten minutes. Two hundred tests passed. Nobody on the team can tell you what forty of them actually assert.
Which quadrant does that test suite belong to? Brian Marick's agile testing quadrants, later popularized by Lisa Crispin and Janet Gregory, never had to answer that query. The model is more than 20 years old, and it has aged well for one simple reason. It organizes tests by why you're running them, instead of what tool executes them. But it built that organization on one assumption: that a human wrote the test, understood the test, and could explain why it existed. This assumption no longer holds for a huge share of the tests running in your pipeline.
For readers who need the refresher, the model sorts tests along two axes: business-facing versus technology-facing. And tests that support the team versus tests that critique the product.
| Quadrant | Facing | Purpose | Examples |
|---|---|---|---|
| Q1 | Technology, supports the team | Fast, automated feedback during development | Unit tests, component tests |
| Q2 | Business, supports the team | Confirms the build matches business intent | Functional tests, acceptance criteria |
| Q3 | Business, critiques the product | Validates real-world usability and value | Exploratory testing, usability testing |
| Q4 | Technology, critiques the product | Confirms the system holds up under stress | Performance, load, and security testing |
The grid still describes why a test exists. What it has never described is who or what wrote it, and how much you should trust it without a human checking its work. (For a full walkthrough of what each of the four quadrants covers in practice, Agile Testing Quadrants explained is a solid starting point.)
Crispin and Gregory have revised the quadrants themselves more than once, most recently in Agile Testing Condensed, and have said publicly that they welcome suggestions for how the model should keep evolving (Lisa Crispin, "The Agile Testing Quadrants" ). None of those revisions added a dimension for test authorship. Because until very recently, there was only one kind of author.
Marick built this model where every test in Q1 came from a developer who understood the code path it exercised, and every test in Q3 came from a tester who understood the user it represented. That authorship was implicit. It didn't need its own axis because there was only one kind of author.
That's no longer true. According to a survey by quality assurance practitioners, 65% say that the development teams they work with actively use AI to generate code. Another 16% do so occasionally, meaning AI-assisted development is becoming a common input into modern testing workflows (State of AI-Generated Code). The exact survey found that respondents rated their trust in AI-generated code at 3.16 out of 5, and 58% said their testing workload has grown as a direct result.
The gap between adoption and trust is something the original quadrants were never designed to express. A Q1 unit test generated by a large language model from a docstring and approved by a developer without review can sit in the same box as a Q1 unit test written by a senior engineer after a production incident. The grid treats them identically, but your defect escape rate will not.
One possible evolution of the model is to add a third dimension: provenance. Not what type of test is this, but where did it originate from, and how much unsupervised trust does it carry?
Think of it less as adding another box to the existing grid and more as adding a Z-axis that transforms the flat model into a cube. Every quadrant can now be evaluated through an additional trust dimension based on three states of test provenance:
Human-authored and reviewed: The traditional case the original model assumed.
AI-authored, human-verified: A developer or tester used an AI test generator or agentic test-writing tool, reviewed the output before it was merged.
AI-authored, unverified: The test passed continuous integration (CI), and nobody meaningfully reviewed the assertion logic behind it.
That third bucket is where flaky test root-cause analysis gets expensive fast. A Q4 performance test that an autonomous agent scaffolded against a staging environment, with load parameters nobody validated against real production traffic, isn't a technology-facing test anymore in any way Marick would recognize. It's an unverified hypothesis wearing the shape of a test.
Coverage percentage has always been a blunt instrument, but it becomes actively misleading when test authorship is mixed. A suite that reports 85% coverage tells you nothing about whether that 85% reflects deliberate risk-based testing or an AI test generator filling gaps to balance a coverage gate.
Picture a payments team that asks an AI test generator to bring a checkout module from 60% to 85% coverage before a release freeze. The tool delivers. Every new branch has a corresponding test, the build goes green, and the coverage dashboard reports success. Three weeks later, a currency-rounding edge case reaches production, because eleven of those new tests asserted that a function returned a value, not that the value was correct. Coverage went up. Risk did not go down. The dashboard just never had a field for "asserted with intent" versus "present to satisfy a gate."
This is the same gap that's pushing more QA teams toward predictive, risk-based approaches instead of flat coverage targets. Using historical defect data and code complexity to flag where testing effort actually matters rather than where it's easiest to generate a test through predictive analytics in testing.
Mean time to detect (MTTD) suffers the same distortion as coverage. An AI-authored test that passes without asserting anything meaningful doesn't reduce your MTTD. It just delays the moment you discover the gap until a customer does.
You don't need to rebuild your test management tooling to start using this. Three moves get you most of the value:
Tag provenance, not just category. Whatever test management system you run, include a field for authorship: human, AI-generated-verified, or AI-generated-unverified. These alone surface where your actual risk is concentrated, quadrant by quadrant.
Route unverified AI tests through a human-facing quadrant regardless of their technical label. A Q1 unit test that no human has verified behaves, from a trust standpoint, more like an unreviewed Q3 exploratory finding than a reliable technology-facing check. Treat it accordingly until someone signs off on it.
Build verification into the pipeline, not just generation. Generating tests faster without a matching investment in verification just moves the bottleneck downstream. Self-healing automation can reduce the maintenance burden caused by application changes. However, maintenance and verification are different challenges, and solving only one still leaves the trust gap open.
The four quadrants still answer why a test exists. The missing question in an AI-native pipeline is whether that test deserves trust. Adding provenance does not replace the Agile Testing Quadrants; it extends the model for a world where humans and AI systems increasingly collaborate to build, test, and maintain software.