Here’s a modification of Agile Testing Quadrants by Lisa Crispin & Janet Gregory (originally by Brian Marick). I’ve used this as a communication tool in our current project. As it might raise few eyebrows, let me explain couple things.
(Also want to mention that I’ve modified the Quadrants a bit from how they are actually on the project – i.e. what we are focusing on & what we are not focusing on)
Context & Background
I explained very briefly my current context on my previous blog post: Striving For Early Feedback
Besides that, I’ve had challenges with explaining what we (our test team of 2) is testing, with respect to all others on the overall system. Then I was listening Paul Gerrard’s talk (Agile Test Strategy) a while ago. There he mentioned Agile Testing Quadrants. Of course I knew them and had seen them several times before. I just couldn’t come up with the idea of them being useful in my current context.
I first used Crispin & Gregory Quadrants while describing our approach to one vendor. There was though many things that I didn’t personally see useful (e.g. Automated & Manual or ET being on Q3). Then I had a discussion with Jari Laakso on Twitter. After that discussion I realized – with the help of Jari – that I can modify the Quadrants in any way I want. And that I did.
Things I want to emphasize
With my modified Quadrants I want to emphasize basically 4 things:
- Our testing being a division between testing the expected vs. unexpected – Or in other words ‘Focusing on Expectations’ vs. ‘Focusing on Risks’
- We are intentionally not focusing on testing certain things (e.g. unit testing) – but are aware of how that’s being done by certain people
- All testing is based on exploration – in other words: Learning. We don’t test for the sake of testing, but to learn more about our product with every test
- Testing mentioned on the top is about People and not only about Business. It’s about people whose lives our product touches (Marc McNeill – according to Dan North)
What was challenging
Perhaps the biggest challenge with Quadrants is that it’s quite challenging to fit different forms of testing there. For example in performance testing we might be testing the expected (e.g. explicit documented requirements), but also regardless of those. That would mean that performance related testing goes to many places.
In the end I found that that particular challenge was something I can live with. Considering I can emphasize those other things with the model.
What next?
I don’t know yet if I will continue to modify and improve the model to make it more useful while describing our testing approach. Or if I will use this model later on the following projects or companies. I might. Or I might not. What matters now, is that it makes it a bit easier (from my perspective) to explain what our testing looks like.
Flow of Testing 