Dissecting The Testing Quadrants - Columns

Posted By Duncs ~ 11th April 2014

This is the 3rd in a series of posts where I dig into the Agile Testing Quadrants after a coaching session I had with James Bach. This post focuses on the left & right sides of the matrix; the columns.

There are some interesting discussions about the name of the activities & their artefacts for each side of the quadrant. Here’s a quick breakdown of some of the different labels for each column that I have come across:

Left Column	Right Column	Author
Support Programming (preparing & reassuring)	Critique Product (uncovering prior mistakes and omissions)	Marick, B
Supporting the Team	Critique Product	Crispin, L. Gregory, J
Defect Prevention	Defect Detection	Gregory, J (originator?)
Checking	Testing	Charrett, A-M
Confirm	Investigate	Hendrickson, E
Check for expected	Analyse unexpected / undefined / unknown	Adzic, G
Test to Specification	Test to Failure	Poppendieck, M & T
Written before code	Written after code

I was originally introduced to the Agile quadrants in Lisa & Janet’s Agile Testing book. It was from here I discovered Marick’s Matrix. I was interested by the change in terminology between the 2 models, so it was great to dig deeper into both models to get the answers to some of my questions.

My initial confusion was with the shift from “Support Programming” label proposed by Marick to “Supporting the Team” label stated in Lisa & Janet’s book. After some deeper reading, I found a possible reason in one of the subsequent posts from Marick where he recognises the scope (of the top left quadrant) is wider than he first thought, so he changed the name. I should check-in with Lisa & Janet to see if that post was actually the reason. (I prefer the label “whole team” in this instance, but that term itself opens up a whole other discussion).

Another discovery for me was that the Agile Quadrants don’t clearly identify the 2 different roles of the artefacts in the left column - as Marick states:

“We can split that idea [programmer supporting] in two. There are new examples that guide decisions about what to do next. And there are automated examples that serve as change detectors to see whether what you just did was what you expected to do”

An example which is written to help guide what code to write next later becomes the change detector to alert if some business logic has inadvertently been broken. How much “later” depends on the size of your feedback cycle.

James & I discussed the idea that throughout the development of a feature, examples can flow from the left column where they are being used to guide coding to the right column; from proving that the feature “Can Work” to demonstrating that it “Will Work” under different scenarios.

In the right column, we expect the number of examples to increase as the product / system is explored. It is important to remember that examples can be executed through automation or manually in any of the quadrants.

Subsequently, when we are “finished” testing, a selection of the examples (key examples perhaps?) which will flag if core business logic is impacted by further code changes are kept & maintained to serve as change detectors - effectively moving them from the right column back to the left column.

You can see in this model that there is a shift in what kinds of tests & checks get created & executed in each quadrant. It appears our model quite closely resembles the ideas behind Gojko’s thinking:

“Dividing tests into those that support the team and those that evaluate the product is not really helping to facilitate useful discussions any more…”

Rather than focussing on what gets run in either side of the matrix, we’re focussing on the movement between the columns.

In later posts I’ll be giving some examples of how the updated model could be used.

Post 4: Different Representations of the Model

Post 5: Example usage of the matrix

Post 6: Wrap Up

Post 1: Intro

Post 2: Rectangles