Testing quadrants

When deciding on test varieties, many testers find great support in the testing quadrants. There are many different versions of testing quadrants. We have used the original version of Brian Marick [Marick 2003] and the adaptation of Lisa Crispin and Janet Gregory [Crispin 2008] to create our own version as shown in the figure below.

There are four testing quadrants that are the result of two axes. The vertical axis shows the technology perspective versus the business perspective. The horizontal axis is about guidance for the team during the creation of a product versus assessing the product after it is ready.

1. The first quadrant (bottom-left) is where the focus is on technology and where the testing activities guide the team in the creation of the product. This involves test-driven development (TDD) for the units and integration of the units. These test varieties should be automated.
2. The second quadrant (top-left) has a focus on the business and is also about guiding the team. This involves acceptance test driven development (ATDD), for example, where a business process is tested, preferably automated.
3. The third quadrant (top-right) has a business focus on assessing the product. These tests are mainly executed manually, either following prepared test scenarios or in an exploratory approach.
4. The fourth quadrant (bottom-right) focuses on technology and assesses the non-functional aspects of a product that can only be validated after the product is ready. The dynamic performance tests are a good example of this.
   
   

The first and second quadrants mainly focus on verifying if the test object complies with specifications and requirements, or: checking for the expected behavior. The third and fourth quadrants mainly focus on validating that the test object is fit for purpose and it is about looking for unexpected behavior.

DevOps teams have to make sure that tests for all four quadrants are organized and performed. This could be done all together or as another extreme in a wide range of separate tests. DevOps teams will often organize three test varieties:

• Automated tests for modules and the integration thereof, both from a technical and business perspective
• Automated tests for non-functional aspects
• Manual tests from a business perspective

On top of that, the DevOps teams may find that tests for the end-to-end business process are necessary, but they often cannot perform such a test without collaborating with other teams. For example, a special team will be charged with organizing and performing these end-to-end regression tests.