The Agile Testing Quadrants
Figure 3.3 Agile Testing Quadrants as presented in the book More Agile Testing by Lisa Crispin and Janet Gregory (2014).
Instead of focusing on levels and types, this model emphasizes the difference between business-facing and technology-facing tests. Business-facing tests are tests that make sense to a person responsible for business decisions. A typical example could be:
If a customer uses direct bank payments to pay for our product and pays too much, does he or she get a refund, or is the excess amount stored and used in the next transaction?
Technology-facing tests are expressed using technical terms and implemented by the developers:
If validation of the credit card fails, the transaction enclosing the purchase is rolled back, nothing is stored in the database, and the event is logged.
Another dimension of the testing quadrants is the distinction between tests that guide development, like tests written by developers to ensure that the produced code is correct, and tests that critique the product. The latter are directed toward the finished product and attempt to find deficiencies in it.
In my opinion, this is one of the most usable models in the domain of software testing. No, it’s the most usable. It facilitates teamwork by turning testing into a cooperative activity, instead of an adversarial one, while at the same time reminding us of the duality of guiding/supporting testing and the critiquing kind. The model also tells us that in order for a team to deliver a product that functions correctly, delights the users, and solves the business problem, it must view its testing activities from several disparate perspectives.
When projected onto the Agile Testing Quadrants, developer tests cover the whole of the lower left quadrant, large parts of the upper left quadrant, and a fair share of the lower right quadrant.