Gathering the Information to Build a Test Strategy
One of the most difficult aspects of writing a test strategy is in the timing. The strategy is needed early, but often all the information needed to write a good strategy isn’t available yet. But if you wait until you know everything about a project, you’ll miss out on planning. The answer is to start planning early, but be flexible. This is why writing a draft of the test strategy is important: The reader can tell that you recognize the fact that elements of the project will shift, and with those changes your strategy will change. You’re committing to what you’ve written, but you cannot plan for what you don’t know. Write your test strategy with the best information you can gather at the time, and expect change.
As you learn more about both the project and the product, you can draft the more detailed work of test plans, test cases, or test charters. If high-level changes take place, it’s appropriate and important to update the test strategy and to communicate those changes to the project team. If directional information changes, capture the changes. If the changes are low-level details, those changes can be reflected in status reporting or perhaps other documentation or communication throughout the project. If something strategic changes, however, it’s time to update the test strategy.
As constant informal conversations move projects along, the point isn’t having documentation that’s written perfectly. Documentation doesn’t save projects. Constant steering correction is the key—shifting as needed to accommodate the project and its testing needs as the work continues to unfold. (See principle 4 of the seven basic principles of the context-driven school.)
Building a test strategy takes legwork, likely involving multiple conversations with various team members and stakeholders. Strategic thinking is iterative, which is why working on a strategy early is important—to start digging and asking questions. Learning other people’s testing expectations is a worthwhile activity, and in some situations a political necessity. Talking through testing with other people on the team can help to determine what’s realistic and feasible. I often collect ideas from people both individually and in groups, because the information often differs in those two settings. Finding and closing such "expectation gaps" is best accomplished during development of the test strategy.