The Testing QuadrantJune 15, 2022
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.
If you and your team want to learn more about how to write maintainable unit tests and get the most out of TDD practices, make sure to have look at our trainings and workshops or check out the books section. Feel free to reach out at firstname.lastname@example.org.
Jan Van Ryswyck
Thank you for visiting my blog. I’m a professional software developer since Y2K. A blogger since Y2K+5. Provider of training and coaching in XP practices. Curator of the Awesome Talks list. Past organizer of the European Virtual ALT.NET meetings. Thinking and learning about all kinds of technologies since forever.
Watch The Videos
June 15, 2022
February 2, 2022
December 15, 2021
October 7, 2021
June 22, 2021
- Behavior-Driven Development
- Concurrent Programming
- Continuous Integration
- Core Skills
- Design Patterns
- Domain-Driven Design
- Event Sourcing
- Fluent Interfaces
- Functional Programming
- Object-Relational Mapping
- Open Source
- Software Design
- Test-Driven Development
- Visual Studio
The opinions expressed on this blog are my own personal opinions. These do NOT represent anyone else’s view on the world in any way whatsoever.
Thank you for visiting my website. I’m a professional software developer since Y2K. A blogger since Y2K+5. Author of Writing Maintainable Unit Tests. Provider of training and coaching in XP practices. Curator of the Awesome Talks list. Thinking and learning about all kinds of technologies since forever.