How to find the right testing strategy with an easy framework
Testing happens throughout the whole product life cycle. But when should you test what? And how can you help your team if you don’t bring in some technical domain knowledge? This article will show you different testing areas and categories to find the right testing strategy for your team and product along the product life cycle. You can guide your team with this framework to commonly develop the right strategy for your purpose. This is the second article in the series “Agile Software Testing — insights for non-technical people, like me”.
As you might remember from my first article about the essential principles of agile software testing, a testing strategy describes, which tests you will run, when and for which level of detail. Now let’s bring some light into this to find out which tests could be the best for you.
Keeping the big picture in mind
To choose the right testing approaches on each detail level, it makes sense to have a look at different testing categories with your team, to get a feeling for the areas of testing you’ll benefit from. In “Agile Testing Condensed: A Brief Introduction”, Janet Gregory and Lisa Crispin introduced a framework by Brian Marick for this purpose, the agile testing quadrants. They gave some examples of tests that can (but don’t have to) be used in the different quadrants which are shown in the graphic below (complemented by me with the quadrant numbers (Q1–4) described in the book).
To find the right set of tests that suit the specific requirements of your product and team, you can fill in these quadrants with your team, customers, and business representatives. Make it your own and discuss where the focus should be depending on the individual requirements your product should fulfill for your customers. So let’s look into the four quadrants and the tests they comprise.
Guiding development (on the left) describes all tests that are being done before coding or throughout the coding process. These tests aim to prevent defects from happening.
Critique the product (on the right) refers to tests that are being done in production (after the release) to find out if the product meets the requirements that were set upfront and to detect any bugs (unexpected behavior of your product). These tests aim to detect defects that already happened.
Business facing describes all tests that ensure that the requirements the customer or business stakeholders have towards the product are defined and kept.
The technology facing tests aim to set the right quality standards for the code and to check if they were kept in the code in production. They also alert when a defect or unexpected behavior is detected.
The numbers of the quadrants don’t define, which tests should be done first or are more important than others. It simply helps to differentiate them.
Each team should think about its own mix of tests. When you, the team, or customer representatives find that the quality requirements are unclear or not being met, you can look at the quadrants together to see if there is an area that needs improvement.
Focus on the quality attributes that are of most importance for the customer. If reliability is the main aspect of the product, like it is the case for medical equipment, for example, the team should focus their capacities on tests that ensure the resilience and security of the product.
Now that you know different testing areas you have a compass for the application of tests throughout the product life cycle. In the next articles, I will give you insights along the quadrants about what happens in the different phases of the product.
References
- Key source for the article series: Agile Testing Condensed: A Brief Introduction by Janet Gregory and Lisa Crispin
- The agile testing quadrants
Articles of the series
- Article 1: A guide through the essentials of agile software testing that everyone can understand
- Article 2: How to find the right testing strategy with an easy framework
- Article 3: Your Superpower for Successful Testing: Creating a Shared Understanding
- Article 4: Everything you need to know about Unit and Integration Tests
- Article 5: A non-technical guide about bringing code to your customer
- Article 6: How to find out if your product really creates value
About the article series “Agile Software Testing — insights for non-technical people, like me”
During these isolated times I took the chance to learn more about software testing. This can be quite challenging without a technical background. Therefore I read the book “Agile Testing Condensed: A Brief Introduction” by Janet Gregory and Lisa Crispin and worked through the content they describe in the book. To make it easier for you to quickly get the most important insights, I summarized my learnings from the book and some further sources and want to share them here with you in a series of short read articles. They are structured along the product development phases and you can either read them piece by piece to get a holistic overview or pick the topics, you are interested in most. I believe this will help you, as it helped me to understand a bit more about the world of testing, without having a technical background.
