Leadership In Testing: Defining A Test Strategy
Editor’s Note: Welcome to the Leadership In Test series from software testing guru & consultant Paul Gerrard. The series is designed to help testers with a few years of experience—especially those on agile teams—excel in their test lead and management roles.
This article takes its cue from the previous one where I defined what software testing is all about and introduced the main concept that will frame your thinking. Now we’ll look at how to create a testing strategy to inform the process you will use to achieve your testing goals.
Sign up to The QA Lead newsletter to get notified when new parts of the series go live. These posts are extracts from Paul’s Leadership In Test course which we highly recommend to get a deeper dive on this and other topics. If you do, use our exclusive coupon code QALEADOFFER to score $60 off the full course price!
In my previous article, “Leadership In Test: Introduction”, we explored the concept of testing with respect to its aims. Quick recap: no matter what type of test you’re talking about, my advice is to always ask the specific goal of the test. This is true even if it appears to be a commonly accepted term like a unit test or acceptance testing.
Here I’ll be explaining how to define a test strategy that will lay the groundwork for a robust, flexible testing process appropriate for whatever development methodology your team is using. I’ll be covering:
Let’s dive in.
What Is A Test Strategy?
Planning is everything. The Plan is nothing.
Dwight D. Eisenhower, of the D-Day preparations.
In this section, we’ll look at what a test strategy is and why it’s important to have one. If you look up strategy in the dictionary you tend to see a lot of definitions relating to military battles – which isn’t terribly useful. But there are some statements that we can make that set out a framework for how you define a test strategy specifically.
Firstly, your strategy is not a worthy document. Your strategy is a result of exploration, thinking, and collaboration. The strategy seeks to define the process you will use to achieve your testing goals.
It could be a brief set of guidelines that your team follows. It could be a document of 20 to 2,000 pages (for a very large program). The goal isn’t a document, it’s the thinking behind it.
Secondly, before you can plan a test, you usually need to have a lot of questions answered and decisions made. Some can be answered now, others will have to wait. Therefore, the strategy:
- Presents some decisions that can be made ahead of time i.e. now.
- Defines the process, method, or information that will allow decisions to be made (during the project).
- Sets out the principles (or process) to follow for uncertain situations or unplanned events.
The strategy attempts to answer as many questions as possible ahead of time. But why bother doing this, surely we can address the problems in testing as we encounter them?
Well, by raising these questions early, and getting people to think about the consequences, huge difficulties might be avoided, or at least mitigated, before they threaten the success of your project.
Related Read: CREATING A QUALITY STRATEGY
Test Strategy Framework
This article can’t provide you with a definitive and comprehensive set of questions to ask – there just isn’t space. But we can cover the most important starting points for your information-gathering.
In the test strategy framework I’ve split the questions across three topic areas, but you could ask more questions and/or structure them differently.
| Stakeholder Objectives | |
| Stakeholders | Who are the main stakeholders? What are their aims for testing? |
| Goal and risk management | How will risks be identified? Who assesses them? Who approves the test approach? |
| Decisions to be made and how | What decisions do stakeholders need to make? (e.g. transition between stages, deploy, go-live) |
| Confidence | How will test results/reporting give stakeholders confidence? |
| How to assess testing | How will the quality/ thoroughness of the testing be assessed? |
| Scope | How will scope be defined? |
| Design approach | |
| Sources of knowledge | What/who are the sources of knowledge to be used to scope and specify tests? |
| Sources of uncertainty | What causes uncertainty in our sources of knowledge? |
| Models to be used | How will test models be derived? How will they relate to stakeholders? |
| Prioritisation approach | Under time pressure, how will priorities be assigned to tests? |
| Delivery approach | |
| Test sequencing | How will the sequence of tests be decided? |
| Repeat test | What is the policy for re-testing and regression testing? |
| Environment requirements | Who provides environments? What compromises? How delivered/controlled/managed? |
| Information delivery approach | How will test execution deliver information to stakeholders? |
| Incident management approach | (How) will incidents be managed? |
| End-game approach | How will the test process end? (How) will outstanding bugs be fixed/re-tested? |
In the table above, there is no mention of the planning process. This could be defined in the strategy or not. At any rate, we’ll take a deep dive into the specifics of planning in a future article, so stay tuned!
Sign up to The QA Lead newsletter to get notified when new parts of the series go live. These posts are extracts from Paul’s Leadership In Test course which we highly recommend to get a deeper dive on this and other topics. If you do, use our exclusive coupon code QALEADOFFER to score $60 off the full course price!
Also Worth Checking Out:
