Basics Revisited: Test Strategy

[article]

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.

About the author

Fiona Charles's picture Fiona Charles

Fiona Charles is a Toronto-based test consultant and manager with thirty years of experience in software development and integration projects. Fiona is the editor of The Gift of Time, featuring essays by consultants and managers of various professions about what they've learned from Gerald M. Weinberg. Through her company, Quality Intelligence, Inc., Fiona works with clients in diverse industries to design and implement pragmatic test and test management practices that match their unique business challenges. Her experiential workshops facilitate tester learning by doing, either on the job or at conferences. Contact Fiona via her Web site at www.quality-intelligence.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!