The Rise and Reinvention of the Testing Quadrants

When testers had no seat at the agile table

Extreme Programming was a methodology built by developers for developers. Everything outside coding was bundled into the role of the "XP Customer," which translated loosely from developer-speak into "not my problem." When companies began adopting agile in the mid-2000s, business analysts became product owners and project managers became scrum masters. Testers, forever the poor cousins of the software world, were left wondering whether they still had a job.

The confusion was real. At one large financial services company, the entire testing department resigned within a week of hearing their organisation was adopting Scrum. Developers worldwide quietly hoped that a few well-written JUnit tests would make dedicated testers unnecessary.

A framework that saved a profession

Brian Marick first sketched the testing quadrants around 2003, organizing test activities along two dimensions. The vertical axis separated business-facing tests from technology-facing tests. The horizontal axis separated tests that support the team during development from tests that critique the finished product. It was a clean, intuitive taxonomy.

Lisa Crispin and Janet Gregory made the quadrants famous through their 2009 book Agile Testing. The model became the centrepiece of the book, the one diagram everyone remembered from every conference talk. In less than five minutes, you could use the quadrants to show a sceptical developer that unit testing occupied just one corner of a much larger quality landscape. The framework gave testers a language to defend their role and helped teams design balanced test strategies.

Why does the model no longer fit?

The quadrants were built for a world of two-week sprints with a clear boundary between development and release. By the early 2010s, that world was dissolving. Continuous delivery meant teams deployed multiple times per day. DevOps blurred the line between building and running software. Lean startup practices pushed teams to test product hypotheses before writing code.

The horizontal axis became the problem. It asked teams to separate activities that "support the team" from those that "critique the product." In a continuous delivery environment, that separation collapses. Performance tests run during development support the team by catching regressions and critique the product by measuring response times. Functional tests built through Specification by Example are simultaneously developer feedback and business acceptance. Exploratory testing, placed by many practitioners in the "critique" half, produces its most valuable insights when done early in the cycle.

Gojko Adzic, author of Specification by Example and Impact Mapping, put it this way: the more he tried to map modern practices onto four quadrants, the messier the picture became. Activities that once sat cleanly in one quadrant now span two or three. The framework designed to reduce confusion had started creating it.

One axis survives, one needs replacing

The vertical axis still works. Distinguishing business-facing tests from technology-facing tests remains a useful rule of thumb. It helps teams allocate skills, choose tools and structure conversations between technical staff and business stakeholders.

The horizontal axis needs a new question. Rather than asking "does this support the team or critique the product?" the more useful distinction is between checking and analyzing. Checking means verifying pre-defined expected outcomes: assertions in automated tests, compliance validations, regression suites. Analyzing means investigating areas where there is no pre-defined correct answer: exploratory testing, penetration testing, load testing to find breaking points, usability research, production log analysis.

What the new axis reveals

This reframing resolves several persistent debates. Security testing splits naturally into penetration testing on the analyzing side and compliance checking on the checking side, dismantling the myth that security is a single "non-functional" concern. Performance testing splits similarly: exploratory load tests that ask "where will it break?" belong to analysis, while automated SLA verification is a check.

The distinction also surfaces quality activities that traditional test plans rarely cover. A/B experiments, production analytics, hypothesis-driven product tests and trend analysis of operational data all sit on the analyzing side. They produce insights rather than pass/fail verdicts and require skilled interpretation rather than scripted execution. Much of today’s innovation in software quality happens in this space.

The context-driven testing community had been making a related argument for years: verifying expected results is not really testing in the fullest sense. Checking is necessary but mechanical. Analysis is where testers apply genuine skill and judgement. A model that makes this visible helps organisations invest more thoughtfully in both.

Frameworks should evolve with the industry

The original testing quadrants did important work. They legitimised the testing profession inside agile teams during a period when that profession was under genuine threat. The fact that we now need to update the model is not a criticism of its creators. It is evidence that the industry moved forward, partly because frameworks like the quadrants helped it move.

Teams still need a shared mental model for testing strategy. The checking/analyzing axis offers a better fit for organisations practising continuous delivery, running DevOps pipelines and applying lean product management. Keeping the vertical axis intact preserves the original insight that testing has both business and technical dimensions. Replacing the horizontal axis updates the model for a world where the boundary between development and operations has all but disappeared.