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.

4 Comments

  1. Posted September 19, 2010 at 11:41 am | Permalink

    You’re not the only one to rail against a common jargon or nomeclature for our profession. The only people I’ve met who don’t seem concerned about it are the ones who don’t believe there’s a problem due to their adherence to a particular dogma.

    Here’s what Webster’s has to say about a strategy, “The art of devising or employing plans or stratagems toward a goal.” A plan on the other hand is defined as “a detailed formulation of a program of action.” So a strategy is a plan of plans to simplify it to the point of inaccuracy.

    The smell test comes in when you sense you’ve moved from strategizing how you will approach something and are now involved in planning activities. A good rule of thumb I use is to look at the size of the document. Anything more than four pages is likely a plan.

    • Posted September 19, 2010 at 11:49 am | Permalink

      Fantastic (and quick) comment. Another thing I consider is that even at 4 pages, you are pushing the limits of what people are willing to read – the ratio of strategy documents to read strategy docs is pretty horrid.

  2. Adam Geras
    Posted September 19, 2010 at 11:54 am | Permalink

    I share your description of test strategy; helps me get the point across that it is not fixed like a plan might be interpreted to be fixed. Also I like the freedom from a template. I can focus on what needs to be communicated, not conforming.

  3. Jared
    Posted October 12, 2010 at 3:51 pm | Permalink

    I’ve had strategy documents that are around seven pages, but I tend to use a lot of pictures and diagrams. I’m also compensating for poor or non-existent product vision documents, so I think it’s OK.

    My approach –

    http://www.software-testing.com.au/blog/2009/07/21/thinking-about-test-strategy-a-mnemonic-device/

One Trackback

Leave some words for the weasel

%d bloggers like this: