Until a few years ago, I vividly remember a separate phase in the software test life cycle that used to be dedicated to the development of a master test plan or the so called holy test strategy which served as the guiding document outlining the software testing process specific to the product under test. It was usually drafted by the test director or the test manager and was representative of the test team’s intelligence in helping them making the product sign off call. Such was the importance of this document; it also served as a reusable artifact often carried across releases, products and teams. Given the relative stability in the development environment such cross sharing and reusability were feasible.
However, over the last 5-6 years given how agile the product development environment has become de-emphasizing documentation and focusing more on dynamic planning and execution on the go, the usefulness of an artifact like test strategy has become questionable. In my experience, having worked on both the traditional and agile projects, I can certainly vouch for the importance of a test strategy and the value it provides to not just the test team but the product team at large in building a product of exceptional quality. It has vital elements such as testable points, team allocations and mapping with the rest of the product team, defect management guidelines, project risks and mitigation strategies, project exit criteria which are very important pieces that guide the test team overall.
One thing to keep in mind is that like any other evolving trend, a test strategy should also be altered to fit the changing needs without losing the underlying essence of what it has to offer to the team. One needs to understand the current scenario, the characteristics of an agile delivery model, and their project constraints in determining what needs to be retained and what can be compromised in building a strategy that is truly usable. For example, elements such as team allocations and mapping with the rest of the product team are not going to be as relevant as they used to, because this is a very dynamic piece in the current day development world. Instead this can become a living document retaining other relevant pieces such as project exit criteria, defect management guidelines and incorporate newer pieces such as team retrospective meetings, learnings specific to the current release that are key to incorporate moving forward.
In certain teams, I have seen them merge the test strategy and the test plan to create a single guiding document or a group of test plans retaining the important and relevant pieces of a test strategy but just doing away with the need to maintain a separate document. There are clear benefits of this model too, because you are incorporating the pieces you need into a document that is going to be used more often. Whatever it takes to understand and use the pieces of a strategy that will help you build and ship quality software is what really matters, at the end of the day.
In some ways, such a test strategy in an agile environment is more current, relevant and used than a traditional test strategy which was at times created with a lot of vigor and later forgotten. The current scenario provides the test management team an opportunity to revisit the strategy every few weeks, especially in a Sprint retrospective meeting, to gauge if the practices laid down really align with building a product of great quality or if any tweaks are needed.
This is where, I continue to believe that a test manager plays an important role in helping the test team adapt itself effectively to the changing product and market dynamics yet retain the original sanctity of the test effort. When such an open mindset is adopted, the team really understands strategy in its true value rather than treating it as a mere document that involves additional overhead in the creation and maintenance process.