I see a lot of testers — and their managers — misuse the phrase “test strategy.” I say they misuse it not because they don’t agree with some definition I have but rather because I rarely see a good distinction made between test logistics and test strategy. I often see a test strategy equated with a test plan. I hear some testers say that having a test plan is part of your test strategy. I hear others say that it’s the job of the test plan to indicate the test strategy.

So let’s talk about test strategy a bit.

When you come up with a test strategy, what you’re really doing is coming up with activities that are based on a set of choices that you have available to you. These activities are how you will test. A test strategy is more than just a list of test techniques. A test strategy is also less than what most people think of as a full-blown test plan. A test approach is not a bad synonym for a test strategy. This approach is really a little story about how testing is going to be done. A good approach/strategy tells a compelling story — as a set of ideas — that explains and justifies the testing you believe needs to be executed.

So I’m saying that a test strategy is a set of choices and a set of ideas. The choices and ideas define the activities that you’ll undertake as you test. But there are some key points that I like to keep in mind.

1. Those activities should address risks that matter enough to spend time on.
2. Those activities should serve somebody’s interest.

The test strategy is the connection between your testing activities and the purpose (or charter) of your testing function.

Just to put some conceptual meat around the abstract bone, I think it makes sense to think of a strategy as what you do in a given situation to accomplish the purpose of the testing. Some people call this a “test mission” and I suppose that works if you think of the mission as being the essential purpose served by the strategy. But, in that case, why not just call it the test purpose? (Plus some people, like me, cringe when they hear the word “mission.”)

In fact, let me digress a bit here. I do believe there should be an overall “purpose to testing” that is stated. Relative to a testing function, I think it’s important to realize that each individual project may provide its own test purpose. For example, here are some possible purpose statements for a given project:

• “Find important bugs fast.”
• “Produce an accurate assessment of quality.”
• “Make sure Functionality A for Important Client B is working.”
• “Ascertain any critical performance degradations between Release C and Release B.”

Now, in most cases, those project-specific purpose statements should line up with your core values. What and where are those? Well, that’s a bit more complicated but this really speaks to the statements that you would apply on any project. The point of making a distinction in the first place is that a purpose can be fluid: while it may not change its contents, it may certainly change the order of the contents. Or perhaps it will make a slight change to the contents to account for some market-driven or business-driven realities, such as changing the emphasis of certain elements under certain conditions.

The core values speak to your non-project-specific purpose. This purpose should definitely identify the core problems that you own because this gives a road map for what you should be doing. (This idea of what you own is why quality may be everyone’s responsibility, but not necessarily equally.) This kind of purpose — which is sort of a “charter” for testing overall — refers to the problems you must solve in order to be seen as successful by your client (whether external or internal). Some examples of statements that might make up a charter:

• “Help predict and control the costs of support.”
• “Educate everyone about testing and how to work with testers.”
• “Help clients improve quality and testability.”
• “Certify that products meet a particular standard.”

Okay, that was my digression. Now back to strategy. I said a few things above that I treat as important:

• A test strategy is the connection between your testing activities and the purpose of the testing function.
• A test strategy is what you do in a given situation to accomplish the purpose of the testing.

Your test strategy should be a guide to your test design.

The design part is important here because your strategy is about more than just the tests themselves.

• The strategy is your reasoning about why those tests are effective and efficient for the project at hand.
• The strategy partly answers why you feel these tests (and not others) are adequate for fulfilling not just the purpose of the project but your charter overall.

The tests you use were presumably produced via techniques and via motivations. Your strategy should indicate that. Putting that another way, all of your tests should allow you to test in accordance with your strategy. With that being said, your tests should not be the thing that dictates what your strategy is. At one level, your tests are an output, not an input.

I’ve focused a bit here on how the test strategy relates to testing but there’s also a component of the strategy that relates to values. You can say that a strategy at least gives an outline of what it’s possible to plan and maybe some ideas of how to plan it. That’s all well and good. But strategies, if they are effective, take into account change. A successful strategy is really your guide through change and provides a firm foundation for ongoing evolution and improvement of your tactics. Unlike a plan, which can be obsolete from the very moment of creation, a strategy should reflect the values of a company (or group) and, by doing so, remain current and useful. I don’t know about anyone else but I think that’s a really important point.

When a company tests its products or its tools, it tries to compare them against its expectations and values.

By its nature, testing introduces change as problems are identified and resolved. A test strategy is necessary to allow these two impulses to work together. I’d also maintain that testing can never be said to be “complete” in some categorical sense and a core skill in testing is the justified management of conflicting demands. Yet, without a strategy these judgments will be inconsistent to the point of failure.

So what I’ve just said here is a long way of saying that product development and software engineering are creative processes. I believe a test strategy is a vital enabler to this process, by keeping a focus on core values and consistent decision-making to help achieve desired goals with best use of resources. It’s my belief that a flexible and adaptive strategy, with proactive and reactive components, stands as a clear counter to proactively rigid but ultimately counter-productive monolithic test plans, most of which are never read any way and are rarely referenced again even if they are read.

One final point here involves how a strategy is documented. A test strategy is not a document. A test strategy is not even a section of a document.

A test strategy is a framework for making decisions about value.

To that extent, a strategy should have strong links to the unique values of the company. The strategy is itself part of the creative process.