The classic Agile Testing Quadrants model, introduced by Brian Marick and later refined by Lisa Crispin and Janet Gregory, has served the software testing community for over two decades. It organizes tests along two axes: business-facing versus technology-facing, and tests that support the team versus tests that critique the product. This framework has aged well because it focuses on why a test is run rather than what tool executes it. However, the model was built on a critical assumption: that a human wrote the test, understood its purpose, and could explain why it exists. In today’s AI-native development pipelines, that assumption no longer holds for a significant portion of tests.
The Missing Dimension: Test Provenance
When a feature is scaffolded by an AI coding assistant, tested by an AI test generator, and merged after a quick skim review, the resulting test suite may pass hundreds of tests—yet no one on the team can articulate what many of them actually assert. The quadrants treat all tests within a given quadrant identically, but the trustworthiness of those tests varies dramatically. A Q1 unit test written by a senior engineer after a production incident is fundamentally different from a Q1 unit test generated by a large language model from a docstring and approved without meaningful review.
According to a survey by quality assurance practitioners, 65% of development teams actively use AI to generate code, and 16% do so occasionally. Respondents rated their trust in AI-generated code at 3.16 out of 5, and 58% reported that their testing workload has grown as a direct result. The gap between adoption and trust is exactly what the original quadrants were never designed to express.
Introducing a Third Axis: Provenance
A natural evolution of the model is to add a third dimension: provenance. This axis captures where a test originated and how much unsupervised trust it carries. Rather than adding another box to the existing grid, think of it as 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, reviewed the output, and signed off before merging.
- AI-authored, unverified: The test passed continuous integration (CI), but no one meaningfully reviewed its assertion logic.
The third bucket is where flaky test root-cause analysis becomes expensive. A Q4 performance test scaffolded by an autonomous agent against staging, with load parameters never validated against real production traffic, is no longer a technology-facing test in the way Marick intended—it’s an unverified hypothesis wearing the shape of a test.
Why Provenance Changes Coverage Metrics
Coverage percentage has always been a blunt instrument, but it becomes actively misleading when test authorship is mixed. A suite reporting 85% coverage tells you nothing about whether that coverage reflects deliberate risk-based testing or an AI test generator filling gaps to satisfy a coverage gate.
Consider 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 never had a field for “asserted with intent” versus “present to satisfy a gate.”
Mean time to detect (MTTD) suffers the same distortion. An AI-authored test that passes without asserting anything meaningful doesn’t reduce MTTD; it merely delays discovery until a customer reports the issue.
Applying the Updated Model Today
You don’t need to rebuild your test management tooling to start using this extension. Three practical moves deliver most of the value:
- Tag provenance, not just category. Add a field in your test management system for authorship: human, AI-generated-verified, or AI-generated-unverified. This alone surfaces where actual risk is concentrated, quadrant by quadrant.
- Route unverified AI tests through a human-facing quadrant. 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.
- Build verification into the pipeline, not just generation. Generating tests faster without a matching investment in verification simply moves the bottleneck downstream. Self-healing automation can reduce maintenance burden, but maintenance and verification are different challenges—solving only one still leaves the trust gap open.
The Final Argument
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. By acknowledging the provenance of each test, teams can make smarter decisions about where to invest verification effort and how to interpret coverage and quality metrics.