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
Very interesting topic. There have been quite a few articles about this lately. Your insights and thoughts are very interesting. Great article.
Also wrote a presentation on the topic recently
http://www.slideshare.net/JohanHoberg/hobergs-test-octagon
Best regards,
Johan Hoberg
This is an interesting expansion of possible types of testing. Alan, your other points are clear. Like confirmatory tests on the left hand side and data analysis required on the right hand side.
One question. Why are there many items towards Quality Product? Are we saying that it is difficult to include them under Quality Engineering? Are these items not understood so completely as to include them as confirmatory tests? Is this the reason why these items are performed infrequently or sometimes not at all in certain projects?
Just examples – number of items is purely random (although there may be more items in areas I’ve been thinking about more).