Status: draft
Agile Testing Quadrants are a tool that should help team to plan their testing (activities).
The original idea comes from this Brian Marick post, subsequently revisited and re-proposed by several people with little changes in wording
Quandrants are deeply described in Agile Testing and More Agile Testing books from Crispin/Gregory.
Long story short: "testing" activities should help team to collect info about "doneness" of a working unit (for instance an user story), quadrants helps to understand which testing activity is more suited to:
- guide and confirm the implementation of business value
- guide and confirm the implementation of actual code
- critique and discover the product from a business value point of view
- critique and discover the product from a technology implementation point of view
Here is the latest (2019) version from Crispin/Gregory
Example: we are working on an user story that involves create and add a brand new breadcrumb element in some web pages, aiming to help end users to better navigate the website (and reduce bounce, increase visit time, and so on)
Quadrants may help us to understand that we:
- could need some "e2e" automated test to confirm the element is present in page, can be clicked, and points to desired pages inside actual website
- could need some "unit" or "component" test to confirm internal code used to build a generic breadcrumb doesn't fail on corner case
- could need some "usability" test to discover if end users will understand how it works
- could need some "performace" test to discover if we'll increase database response time due new extra info to collect in order to build the breadcrumb
You can also flip the point of view and use the quadrants to understand if a testing activity is worth. For example, you can ask yourself: as developer, am I using unit tests to understand what the code needs to do? or component tests to consolidate design of a deployable part of the system?