Do you know how to use Agile Testing Quardrants?

I believed some people knew the Agile Testing Quadrants before, but some people have misunderstood the purpose of the Quadrants. For example, they may see them as sequential activities instead of a taxonomy of testing types.

The above picture is we currently use to explain this model. Please notice that the quadrant numbering system does NOT imply any order. You don’t work through the quadrants from 1 to 4, in a sequential manner. I think one important strategy is to utilize the Agile Testing Quadrant, to guide our testing. Each side is a purpose, a focus behind the testing:

• Supporting the team – “actively checks the system works as expected, which is reassuring. These tests also find bugs, but that is a secondary purpose. ” Build team’s confidence in product, ensure teamwork are delivered.
• Critique product – “uncovering prior mistakes and omissions. The primary meaning is about bugs. …” Also checks for non-functional attributes.
• Ensure business needs met 
• Ensure technological needs met –  Falls into “programmer” domain and using technical terms and jargo.

So based on our testing strategy, we can plan our testing start from which quadrants:

• Q1: Technology-facing tests that support the team
• Q2: Business-facing tests that support the team
• Q3: Business-facing tests that critique the product
• Q4: Technology-facing tests that critique the product

Then during the Agile development, we can use the quadrants to guide our testing:

1. First, decide what’s our focus? our purposes? i.e. to satisfy business requirements? To critique our product, making it more robust?
2. Then, based on the quadrants, what methods should be more focused? Manual? Automated? Using tools?
3. Decide what are testing types? i.e. functional testing, exploratory testing, performance testing, security testing etc.

When discussing the Quadrants, you may realize there are necessary tests your team hasn’t considered or that you lack certain skills or resources to be able to do all the necessary testing. For example, a team realized that they were so focused on turning business-facing examples into Q2 tests that guide development that they were completely ignoring the need to do performance and security testing. They added in user stories to research what training and tools they would need and then budgeted time to do those Q4 tests.

<References: Using Models to Help Plan Tests in Agile Projects>