A Test Strategy – or whatever you want to call it

I’m in the middle of little project for work (one of many things I have going on these days), and I was reminded of the fact that we don’t have anything close to a consistent language in testing. It’s nothing new – I blogged about this subject before, but I still don’t have a reasonable solution. I sometimes convince myself that one advantage of certification is building a base of common terminology, but I never convince myself that certification is the right answer.

So, the project I’m working on is sort of a “test strategy” – but I’m pretty sure my definition of test strategy is different than yours. Matt Heusser, for example, recently blogged about test strategy – but in my world of definitions, what Matt is describing is test design – but to be fair, he does call it “designing a test strategy”. Also – to be ultimately clear, there’s nothing wrong with what Matt says, we just have different interpretations of what a test strategy is – no big deal.

For me, a test strategy is a description of the general approach a team will take to testing over a product cycle. It describes a set of approaches and techniques a team will use, why those approaches are appropriate, and how they will benefit the team and product. I (in my definition) avoid details of implementation, and instead, use the strategy message to align a test team and get everyone on the same page with values, approaches, and areas of growth. I like to think of it as an explanation of  “why” and “what” rather than “how”. I prefer to think of “how” as a minor implementation detail – we have smart people on the team, and they’ll figure out the “how” when it’s necessary. I’ve approached test strategy this way for some time, and taught test strategy to a few hundred testers at Microsoft (in which I also emphasize that they are free to adapt to their own definition and context). I should also stress that while I’m writing a document outlining our team strategy (or at least my thoughts on team strategy), that a document isn’t required. An email, whiteboard, or even word of mouth may suffice depending on the situation.

When thinking of a testing strategy, I consider improvements to both the product and the team to be critical. The testing needs to have enough meat and breadth to help build a quality product, but the strategy also needs to consider growth opportunities for the team (perhaps I should call my definition a team testing strategy?). To meet these goals, a strategy basically has a bunch of testing ideas (ideas include everything from approaches to processes to tools)  – some are challenging, but all definitely achievable. Some ideas are part of the day-to-day workflow of the team, but the team doesn’t address every single idea every day. Instead, the team bounces around between ideas as appropriate to the context of the product cycle, feedback, etc.Sometimes, owners are assigned to own ideas (or pieces of the strategy) throughout the product cycle, while other ideas cycle between team members. Over the product cycle, some ideas may be dropped, others will certainly be added, and if the strategy is successful, both the test team and product quality improve over time. This has worked for me in the past, and the approach has resonated with a lot of testers I’ve talked to over the past several years, so I think it has legs. We’ll have to wait and see how it works in my team’s next product cycle – but I’m bound to keep you posted.