Agile Testing Quadrants are a visual tool for understanding different QA tests. They differentiate between business- and technology-facing tests, and those that support programming or 'critique' the product. Testing types are sorted into these four categories on a grid.
You can use that grid to decide on your QA approach and manage your goals. It also allows you to quickly and persuasively communicate the purpose of testing types to non-technical stakeholders.
Brian Marick, a software consultant, published an influential series of articles about Agile Testing in 2003. He did so after being told that he was 'not doing enough to aid the development of Agile testing as a discipline, as a stable and widely understood bundle of skills.'
He aimed to address this criticism, starting with Agile Testing Quadrants. Originally known as the 'Marick Test Matrix', these quadrants form a basic grid:
(Hat tip to Brian Marick)
From there, he suggests placements for testing types within each of the four quadrants, and expands on the reasoning behind each choice. You can find his original essay series here.
(Hat tip to Medium)
Since Marick's original vision, practitioners in the field have created variations of Agile Testing Quadrants, adding more information to the grid. These aren't hard and fast rules, but, generally speaking, here's what each quadrant means:
Unit and component tests are performed throughout your application's development. They provide feedback to your developers on the quality of their code on an ongoing basis, usually through repeated, automated processes.
With a combination of manual and automated tests, these 'business-facing' tests are more customer-focused, but they support your application build as well. These include functional tests, which ensure the product does what it is meant to do.
User Acceptance Tests (UAT), usability and exploratory testing all belong in this quadrant. These involve manual testing by experienced QA engineers and end-user testing. Your aim here is to gain feedback and improve the quality of the product, ensuring it is fit for the designed purpose.
These are technology-facing performance tests, like load testing and checking the data security of your software application. There are many tools available to automate this type of testing, such as Selenium used alongside JMeter.
This visualization doesn't give you a means to prioritize. You don't start at Q1 and work your way around. You need to make those choices based on requirements, risks and dependencies.
Agile Testing Quadrants do, however, provide a holistic overview of QA software testing. In doing so, they can inform your decision-making. (For example, in answering the question, 'Have we covered all the bases?') Public policy is not dictated by science, but informed by it. The same principle applies to your choices about testing.
If you'd like to know more about testing visualizations, check out this article next: Your QA tester's hierarchy of needs: what is the agile testing pyramid?