Agile Testing Quadrant, Test Pyramid, and Layered Automation: Concepts and Practices
This article explains the origin and structure of the Agile testing quadrant, compares it with the traditional V‑model, introduces the test pyramid and its evolution into layered automation, and discusses the purposes and benefits of test automation while also noting a related training event.
The Agile testing quadrant originated from Brian Marick's Agile testing matrix and was later expanded by Lisa Crispin and Janet Gregory, who presented the quadrant model in their book "Agile Software Testing: A Practical Guide for Testers and Agile Teams".
The quadrant divides testing into four areas based on technical vs. business focus and support vs. product evaluation, resulting in Q1 (technical, support), Q2 (business, support), Q3 (business, evaluation), and Q4 (technical, evaluation).
Each quadrant is described in detail: Q1 covers unit and integration testing performed mainly by developers; Q2 includes functional, story‑based, and prototype testing performed by testers; Q3 involves exploratory, usability, and acceptance testing; Q4 focuses on performance, security, and other non‑functional tests.
While the quadrant provides a comprehensive overview, its practical guidance is limited, leading Mike Cohn to propose the test pyramid as a more actionable framework. The traditional V‑model, common in waterfall development, separates testing phases but does not fit well with agile's continuous integration approach.
In agile environments, the "ice‑cream" model often emerges, where most testing effort is concentrated on UI automation, causing fragility, delays, complexity, and higher costs. The test pyramid addresses these issues by emphasizing a large base of unit tests (≈70% effort), a middle layer of API tests (≈20%), and a small top layer of UI tests (≈10%).
Lisa Crispin later added a "cloud" of exploratory testing atop the pyramid, forming the complete test pyramid model.
Layered automation extends the pyramid concept by automating not only UI tests but also API and unit tests, and by considering automation of test data preparation and environment setup. This broader view reduces fragility and improves efficiency.
The article distinguishes between "automation testing" (automating test execution) and "test automation" (automating any test‑related activity, including data and environment provisioning). It emphasizes that the core purpose of test automation is to ensure software quality, with speed being a secondary benefit achieved through continuous, 24/7 execution and distributed execution via containers.
Finally, an enhanced layered automation diagram is presented, adding test‑data and environment automation at the lowest layer to complete the automation stack.
At the end, the author announces a 3‑hour live training session titled "Agile Environment Test Automation Practice Guide" scheduled for June 28‑29, with registration details and promotional images.
DevOps
Share premium content and events on trends, applications, and practices in development efficiency, AI and related technologies. The IDCF International DevOps Coach Federation trains end‑to‑end development‑efficiency talent, linking high‑performance organizations and individuals to achieve excellence.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.