Dissecting The Testing Quadrants – Rectangles

This is the first post attempting to document some of the conversation James Bach & I had whilst trying to determine what my understanding  of the Agile test quadrants actually was.

This post is a WIP as I’m sure I’ll be updating it as I walk through each of the quadrants & work with some of the different ideas & terminology we discussed.

The conversation started by trying to work out what the quadrants are actually for.

I was under the impression the quadrants were a model for defining & communicating a test strategy to the whole team – Programmers, Testers, Business Analysts & Business Stakeholders. At one level that is true, but there is more to the model than that.

When James challenged me to dig deeper into the model I struggled. I couldn’t concisely describe what each of the quadrants was for. This demonstrated my shallow understanding of the model.

After some back & forth, we came to the agreement that the quadrants help instill trust between all stakeholders developing a software product.

Initially we both felt that using the term “facing” might give out the wrong message about who in the organisation might be interested in the activities in each quadrant. We’ve gone for the term “scope”.

The first obvious divide for discussion was between the top & bottom halves of the quadrants; “Business Scope” & “Technology Scope”.

We both agreed with the term “Business scope” – the products, feature & change requests from Business stakeholders which can be sold to customers.

“Technology Scope” proved a talking point for us.

As a term, “Technology scope” seems to be too tight a focus. This bottom rectangle comprises so much more than just the technology of the system. It seems to ignore the human activities that go with this rectangle.

We opted for the term “Craft Scope”. For us, the activities that go on in this rectangle focus on things like improvement of team members skills, quality of the code & team processes:


Business stakeholders may not be directly interested in the bottom rectangle, but this rectangle underpins the teams ability to deliver the stuff & activities in the top rectangle.

Basically, the bottom rectangle is about members of development teams being craftsmen & being able to improve their craft.

One thing we discussed was that the rectangles could be different heights. For example, an organisation which pays little attention to craft with idea that the team should only be focused on delivering products, features or change requests would have a smaller bottom rectangle.

Conversely,  imagine an organisation where the top rectangle was smaller than the bottom rectangle. What would that organisation look like.

If the size of the rectangles is not balanced for the organisation, building trust between the development team & Business stakeholders is will prove difficult.

In the following posts, we’ll split the rectangles in half & walk through each of the quadrants.

What are your thoughts on the  “Business Scope” & “Craft Scope” rectangles?


Next posts:

Post 3: Columns

Post 4: Different Representations of the Model

Post 5: Example usage of the matrix

Post 6: Wrap Up

Previous posts:

Post 1: Intro