Value descriptions like these provide the “why” for test strategy decisions. They may sound obvious, but stating project values up front gives stakeholders an opportunity to say whether you’ve based your strategy on the considerations that matter most to them.
Other strategy ideas will occur to you according to the risks, constraints, and opportunities you discover in exploring the project context. For example, would it make sense to use one or more high-level models, such as “financial year” or “customer experience lifecycle”? Will you use exploratory testing, pre-designed tests, or a mix? How might you sequence major test activities for optimum test value?
Communicating the Test Strategy
On most projects, negotiating agreement to your key decisions is essential for managing stakeholder expectations. Stakeholders need to know about barriers that could impede or prevent important testing, because they will have either to accept or remove them. Suppose you see no way to do year-end period testing on a financial system, or you find that company security rules prevent you running SQL queries on the central product database. If project timelines mean you can do only a superficial once-over feature confirmation on a complex application, say so up front and give stakeholders an opportunity to respond.
Rather than using a strategy document template to inform stakeholders, try to find a lightweight medium that will convey the central ideas clearly without the distraction of masses of detail. It could be the tool you’ve been using to work through your thinking. I have used one or some of: a mind map, sticky notes, a drawing on a board, a colorfully highlighted diagram, an outline document, or presentation slides. The choice depended on the organization I was working with and the nature of the test. Whatever medium you choose, it should work as a tool you can walk around with to talk to stakeholders, or use in meetings to promote discussion.
This isn’t to say that your existing template is useless, though it probably demands things you don’t need and ignores things you do need. You may be required to fill in its blanks for the final secure-it-in-the-vault artifact. But don’t start there. The template for a big document is a poor tool for promoting conversation and securing agreement to a strategy. I find it better not to constrain my thinking by starting with a template.
It’s About Thinking
The size and risk of what you have to deal with and how much is already known and acknowledged by the project will drive how much you do to outline your test strategy. (Don’t be surprised if you find yourself questioning some of what “everyone else” on the project believes.)
Whether it takes two days or forty, at the end of this process you will know your stakeholders and which values and principles are essential to your test. You will have defined the test’s high-level boundaries and approaches, and you will be in a position to draw stakeholders’ attention to any risks, issues or constraints that will impede testing within those boundaries, as well as any assumptions you feel able to make.
But don’t fall too heavily in love with your strategy, or create an expectation in your stakeholders that it’s fixed in stone. A test strategy can change substantially as the project changes and as you discover more about the product.
The key word here is “thinking.” Approach each test assignment as a new problem to solve, and recognize that you will be learning and solving problems to the end of the project. Even if you are testing a well-known product on a path you’ve traveled before, consider standing back and taking a fresh strategic look. It can stimulate new ideas that could improve your testing and save your project time and money.
Acknowledgements: Fiona thanks colleagues Anne-Marie Charrett, James Christie, Karen N. Johnson, James Lyndsay, John Owen Thomas, and Peter Welan for stimulating conversations and reviews that helped to inform this article.