Riffing on the Quadrants

In 2003, Brian Marick introduced the concept of “Agile Quadrants” to describe the scope of testing[1] (later expanded on by Lisa Crispin and Janet Gregory[2]). Several people (including me) have expanded and elaborated on the quadrants to describe the scope and activities of testing.

Here’s a version of the testing quadrants.

One challenge I’ve seen called out before is that there are varying definitions of what a unit actually is. Many unit tests in existence today are actually functional tests, and some may even be better defined as acceptance tests.

I’ve noticed that we see the same behavior on the right side of the quadrant – items in Q4 sometimes slide up to Q3, and items in Q3 may slide down to Q4 depending on how the data (and definitions) are used. But note that while items may move up or down depending on definition or application, we don’t see activities move from right to left or left to right.

If we look a little closer, there’s a clear equivalence class between activities in Q1 and Q2 vs. activities in Q3 and Q4. The activities on the left are confirmatory tests, and the results (whether they’re pass fail, or an analysis failure) tell you exactly what to do – while the activities on the left require analysis or investigation. (noted indirectly here) Furthermore, almost everything on the right side is about (or can be about) data! As test organizations move towards more data analysis and investigation, this is important. Also note that in many contexts (especially, but not limited to web services), the activities in the right half of the quadrant can all be done in production.

Now, this is just a riff, so I’m not entirely sure where I’m going (or if there is a huge hole in my logic), but I’m beginning to see both a strong correlation between activities on the left side and on the right side of the quadrants, and a distinction in skill sets as well. Deep data analysis is quite a bit different from feature development, (and unit and functional testing skills as well).

I remain a fan and supporter of generalizing specialists, and I’m seeing a much bigger need for data specialists and people who can investigate through ambiguity to help build great teams (and yes, we’ll need people that can smoke jump into activities in any of these quadrants as well).

More riffing later as I continue to explore.

[1] http://www.exampler.com/old-blog/2003/08/21/#agile-testing-project-1

[2] http://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468