Back in 2003, Brian Marick wrote an excellent article series about agile testing. There he described the concept of the Testing Quadrant. To my recollection this used to be a well-know model that most software developers were familiar with. Although still very much relevant today, I’ve noticed over the years that the knowledge about the different types of testing as described by the Testing Quadrant somewhat got lost.
The four quadrants as shown in the diagram above each match a specific perspective of testing. These are:
- At the bottom left: Developer tests. This is the quadrant where the test pyramid lives. These tests are typically automated.
- At the top left: Functional tests. These are customer story tests as described by Behaviour-Driven Development (BDD) or Acceptance Test-Driven Development (ATDD). These tests are usually automated.
- At the top right: Exploratory tests and usability tests. By definition these are manual tests.
- At the bottom right: Performance tests, load tests, security tests, … etc. These tests are mostly semi-automated, semi-manual.
Now that we’ve named the four quadrants, let's have a look at their vertical and horizontal position in the quadrant.
The top two quadrants are concerned with tests that are obvious to business stakeholders. These tests should indicate whether the system actually provides a solution to a business problem. The bottom two quadrants on the other hand are meaningful for technical people.
“ We will write tests before we code, minute by minute. We will preserve these tests forever, and run them all together frequently. We will also derive tests from the customer’s perspective.
— Kent Beck - Extreme Programming Explained (1st Edition - Chapter 18)
The left two quadrants are focused on preventing defects before and during the coding process. This matches the quote from the opening paragraph of chapter 18 in Kent Beck’s excellent book Extreme Programming Explained (1st Edition). In essence, by writing tests before writing the code, we build in a certain quality into the system right from the start. These kinds of tests therefore prevent defects instead of merely finding them.
The right two quadrants are focused on evaluating for defects or finding missing features. Note that this kind of inspection is still necessary. These two quadrants merely reflect whether we have a low or high quality system.
Most software systems will involve tests from across all four quadrants. Also, testing shouldn’t be a single person’s
responsibility. The quality of a software system is in fact a team effort. Every team member should be involved in these activities related to the four quadrants. Please note that the Testing Quadrant doesn’t prescribe any order of tests, nor the importance of certain quadrants and definitely not the amount of tests for each quadrant.
“ All models are wrong, but some are useful.
— George Box
The Testing Quadrant is a useful model to help software teams plan their testing efforts, while also creating awareness that it’s generally a good idea to cover all four bases.
Top comments (0)