Most teams think about testing stories and possibly integrations when they think about testing. And that is a great start, but eventually they will need to expand that to include Security testing and potentially Load Testing. This is where the Testing Quadrants can help you.
The Testing Quadrants explained
Below is an image of the Testing Quadrants. At the top you have business facing tests and technology facing tests at the bottom. To the left we have tests that support the team and on the right we have tests that critique the product.
If you consider the left hand side of the diagram you will notice this is the place where tests can be specified in advance of the code being written (TDD, BDD, ATDD). Tests on this side of the diagram generally help prevent defects if they are done before the code. Tests on the other side usually require the product to exist before you can critique it and as a result, tests on the right hand side tend to be more focused on finding defects.
When do you use the Testing Quadrants?
We like to introduce the Testing Quadrants to teams and then encourage them to talk about it in Refinement sessions. This is a great way to be reminded of the testing you need to do and also agree what you don’t need to do. Then you can bring relevant testing tasks into the the sprint. The testing quadrants are a great way to ensure your testing approach is balanced and considers different aspects of testing. If you have no tests in one of the quadrants above, it might indicate a potential quality gap that you haven’t considered.
Do you need to do all these tests?
Not every product needs every type of test. So its important to go through each quadrant and decide which tests are worthwhile for your product. You also need to talk about when is the right time to do these tests. We suggest listing all the tests you want to do, as well as when and scratching out those you are not going to do. For example let’s say Load testing is not important for your product. Add load testing into the bottom right quadrant and put a line through it. This way in the future you will remember talking about not needing this type of test, rather than wondering if you just never thought of it.
Is this all the tests?
Whilst we have given you quite a few test types as examples, this is by no means a full list! Please add in all the test types you are aware of and keep your testing quadrant updated as technology changes. If you have any good categories of tests we haven’t included, please post them in the comments.
How agile is your testing?
Take our quiz to find out…