Testing is awash with quadrants (and triangles) that try to explain the qualitative value for a range of theories, approaches and strategies. This was popularised in Agile Testing through Agile Quadrants by Lisa Crispin and Janet Gregory. This in itself was based on a earlier quadrant by Brian Marick. The aim was to explain where testing fitted in the agile world. This was critical as many felt that testing as a craft was being lost in a agile world created by developers, who didn’t fully understand testing which had been hidden by social and critical distance for many years. This was in part due to the wide adoption of Waterfall as a delivery model, which tended to black parts of the delivery, including testing. Dan North describes this well in his talk on “BDD is not about Testing”. This article gives a overview of the quadrants giving you the links to read further and form an opinion.
As far as quadrants go, the furthest back i can go and find relevance outside of testing is the Johari window which was published in 1955 by Joseph Luft and Harrington Ingham. This really does frame much of what comes later, initially in a very different context and although i can’t find it as a source for any of the subsequent testing posts it does frame the conversation we are having around self and worth. The Johari approach was for looking at yourself and how others might see you via adjectives.
Open, or Arena. Adjectives that both the subject and peers select go in this cell (or quadrant) of the grid. These are traits that subject and peers perceive.
Hidden, or Façade. Adjectives selected by the subject, but not by any of their peers, go in this quadrant. These are things the peers are either unaware of, or that are untrue but for the subject’s claim.
Blind Spot. Adjectives not selected by subjects, but only by their peers go here. These represent what others perceive but the subject does not.
Unknown. Adjectives that neither subject nor peers selected go here. They represent subject’s behaviors or motives that no one participating recognizes — either because they do not apply or because of collective ignorance of these traits.
It would be interesting to run this as a perception exercise of both testers and developers in a non-agile and agile context. You could also replace Adjectives with types of testing, or purpose of discovery. In this context this really is the first quadrant which reflects the conversation going forwards.
Brian Marick in 2003 started to describe the focus for testing within an agile context. Much of the initial focus of agile is how do developers have better interactions with their customers, pairing them together helps them better understand what the customer wants. This reduces the need to redesign the system based on the realisation, through lack of conversation they had misinterpreted what had been written down by someone else. This direct pairing in it’s purest sense removes other conversations that are equally valid.
Marick tries to address this through describing the different focuses for testing. If you only read the first post that Marick writes then you can it only touches the surface of his argument. I think this is why then Lisa Crispin and Janet Gregory try to pull the information in his subsequent posts and populate the quadrants with additional information for greater context.
The “Agile Testing Quadrants” is really a beginners guide to testing within a agile context. It doesn’t describe the why and the craft behind it. It does detail the what and the how. Framing the types of testing that should be considered by the team as they test. It also gives a element of the How through describing where automation and tooling may play a part. There continues to be a lack of information in the quadrants themselves on why you are doing something.
The success in framing testing using these quadrants has also led to debate within the testing industry and a growing presence of the continued importance of testing as a craft. Subsequent attempts at redefining the testing quadrants seem to have focused more on the why and the purpose of testing. The first of these views seems to come from Elisabeth Hendrick in a 2012 CAST keynote speech, where she relooks at the quadrants applying the need for different skills and behaviour between checking/confirming and investigating/exploring the risks of a product.
This is much more focused on the why and the need for a Critical thinking when investigating both the technical and business facing elements of a feature/product. Identifying risk is a key part of product lifecycle and without exploring those risks early they become issues later in the process and become more costly to address (although agile practice reduces this risk through ability to quickly iterate). Markus Gartner provides his own thoughts on this in a 2014 article called “New names for the quadrants”.
Gojko Adzic in “Let’s break the agile testing quadrants” has a different take on the quadrants arguing they are outdated in the context of a continuous delivery landscape where technology enables a further “shift left” in the quadrants for some activities. I think actually he is arguing quadrants are detremental as actually it is a sliding scale. The Agile testing quadrants presented by Lisa and Janet actually led to people thinking they were fixed phases of activity even though they do describe them as non-sequential, the boxes are seen as contained activites to be done as a block. In the end though he pulls away from this and ends with moving around a number of types of testing within the quadrants and rebadging the “Support the team” and “Critique the Product” with a a description more akin to that of Elizabeth Hendrick’s take.
Coming back to the why we are undertaking testing, James Bach and Michael Bolton have their own take on quadrants, dating back to at least 2014 but likely earlier, which continues to describe the need for “testers”, their craft and use critical thinking concepts around Social and Critical distance as a way of describing the value that testers bring. They also suggest that quadrants are cyclical in nature relating it to agile principles around iterative delivery and continued learning. This tries to move away from quadrants being static and once done then you are done. I think this also suggests as you build the product you gain greater context and awareness. This is dangerous to both the builder and the customer in that they can get too close to the product and the building of, not the critique of. They have continued to evolve their quadrants over time.
The closing thought i have within all of this is that all of these quadrants are valid arguments and when taken as a whole provide a very deep understanding of the what, how and why testing is still important and relevant in an agile environment. My own experience is that in years gone by we were the doers, we defined what needed to be tested, we undertook that testing and said when we felt we’d done enough. It was it’s own self contained black box which wasn’t understood. In a agile context it is now much more about educating people and teams on the what, the how and the why we are testing. We still undertake testing activities and support the team in understanding how to critique and explore product risks. At the same time we are learning more skills around the development craft, the analysis craft and get a better understanding of both the operational and business risks through exposure. Although we did this previously, not all good testers did and failed to appreciate risk, undertook shallow testing and didn’t develop their craft, devaluing what testing is really about. Agile is a real opportunity to demonstrate those skills.