The agile testing quadrant

I want to share a way of looking at testing which I think is valuable. It is called the Agile Testing Quadrant. It provides a more comprehensive view of what your organization probably does for testing … although they may not necessarily have such a model in mind.



Two main reasons I find this graphic valuable:

1) Better model of engagement. In some cases the understanding of what is meant by “testing” in is overly simple. I think we suffer unnecessary harm and carry unwarranted risk as a consequence. This more comprehensive view gives us a framework which enables us to ask ourselves “who are the primary owners of Quadrant 4?”. “Do we have metrics coming out of Quadrant 2 yet?”. You may feel that’s more structure than we need – but if we are accountable for a massive enterprise system which simply MUST work … I think we benefit from it.

2) Team responsibility for testing. When the multiple facets of testing are presented in this way, it starts to make sense that testing be positioned as a responsibility for the team as a whole to assume. Unit and component testing is an important quadrant by itself which, due to its technology facing nature, engineers and developers need to own. Too often it becomes a half-hearted pursuit whose cracks will be papered over once QA gets involved. We should not allow that approach to prevail in enterprise systems.

Generally, it is healthy to remind ourselves that QA can’t be responsible for putting in quality. They can assess the state of the quality which is there – but expecting that quality to be added after the fact really makes no sense (and it never did). Building in quality from the beginning should be your strategy and it should be a collective, team responsibility.

Note: Brian Marick should be credited with first bringing this insightful approach to the industry. You can find his original posts here.

Question: According to the model, within which quadrant would automation be less of a promising option?
Show answer

Previous   Next