I like to consider a strategy and tactics distinction when you have a test team that’s striving to operate within the sphere of quality assurance. When you have that situation, then operationally considering strategy and tactics (or logistics, if you prefer) becomes important. The emphasis needs to be on a gradual implementation of good testing practices that then filter up to a full quality assurance process. Since any such quality function, in my opinion, starts with good testing practices of some sort, I’ll mainly make my distinctions here in the context of the idea of testing.

The basis of all this is, to me, very simple: the logistics of testing are the what, who, where, and when of it. Logistics are about getting the right resources to the right place and time in order to fulfill whatever strategy you have devised as part of your effective and efficient testing function. The strategy question you have to ask is: what do you do once your resources are in place? Your strategy is the questions you ask yourself, the logic you employ, the reasoning you bring forth. Those questions, that logic, that reasoning will allow you to focus on specific problems that you’re dealing with at the moment and tailor your logistics to meet the context in a way that allows the test team to maintain a certain level of efficiency and effectiveness.

Those elements that a test team will initially have control over are: test strategy, test logistics, and test work products or deliverables. Taken together these make up the overall test function. It’s up to the team to design these elements to work well within not just one context that they find ourselves in (i.e., one project), but within any context they may find ourselves in (i.e., any project). Then this team can ask operational questions like:

• Do the logistics of the project support the test strategy?
• Are there any problems that block testing?
• Are the logistics and strategy adaptable in the face of foreseeable problems?

In an effort to put things in a readily understandable analogy, consider Sun Tzu. Whether or not a Chinese warrior by that name ever actually existed, the book attributed to him, The Art of War, is at least 2,400 years old. This book has guided Eastern military thought for centuries and has informed American and Chinese military theory for decades. Sun Tzu’s pronouncements on strategy and tactics were a distillation of the forces shaping any conflict, independent of politics and technology. Those strategic and tactical elements are as true today as when they were first written.

Now abstract your thinking here and apply what I just said above to what I’ve been saying about testing. I like to get a team to realize that they can come up with certain strategies and tactics that are a distillation of the “contextual forces” that shape any project in the company. Actual project details may differ: but the forces that drive the environment of the team are largely going to be the same. This is why I like to make sure that testers and quality practitioners think operationally (in a prescriptive, rather than a solely descriptive format) so that it becomes easier to craft an overall test strategy that is independent of a specific project or specific constraints while still allowing for test logistics (tactics) to vary based on the needs within a given project.

Work on having fluid logistics that work within the context of a solid strategy.

What having fluid logistics with a solid strategy does is allow you to recognize that external forces will have to direct some of your test effort (particularly in velocity situations), but that those external forces will not compromise the integrity of the test effort as a whole.

What this all speaks to is the test strategy. I’ve been talking about test strategy a lot lately. Here’s a distillation of some of my previous thoughts.

• The test strategy is the manner in which tests will be designed and executed to support an effective quality assessment.
• The test strategy is essentially the plan for what parts of the application will be covered by what tests.
• The test strategy is about what test techniques will be used to achieve that coverage and that will help make sure the testing itself is effective and efficient.

The important point is that the test strategy is distinct from the logistics of implementing the strategy.

So now consider the test project. This is the means by which the test strategy is implemented and test results are actually delivered to people who care about them. Each project is an entity unto itself and you can usually think of such a project as having a modular team attached to it.

When part of a test team, I try to get the people on the team to see that any test team has strategies and logistics. This may seem like it wouldn’t take too much to get across, but I’ve encountered many people where the distinction is hazy at best. A test team can have overarching strategies that will apply to any project the test staff is working on. Each project, based on its own particular constraints, will require the use of fluid logistics. Yet the logistics must be constrained to some extent by the overall strategy. I’ve pretty much already said that above so let’s consider some examples.

• Let’s say part of the overall strategy is to always demand entrance criteria. However, in each project the logistics of that particular project may mean that the specific entrance criteria are different. For example, full functional specification documentation may not always be required because it may not be practical. The overall demand, however, will be for some sort of testability criteria in written form. So the test team should not say that the entrance criteria must always be of Format X, but rather that there must be some sort of criteria that allows them to know what to test, what has been changed, what impacts the changes may have, what new features have been in place, etc. The criteria that gives the test team enough information to do our job effectively and efficiently is what needs to be sought, without always getting hung up on a specific format.)

• Let’s say that part of the overall strategy is always to provide a performance test summary after every project that has a performance test component. However, one project may only warrant giving out average response time summaries. Another project may require giving out full distribution and percentile graphs along with error statistics. Thus the test team (or performance engineer) does not necessarily say which report must always be given; only that there must be some sort of report. Which one is the most meaningful given the context of the project is the one to go with.

An effective practice is to establish a heuristic test model that fosters a set of patterns for designing a test strategy: it gives you ideas about what to think about when you are creating tests. What binds the strategic elements to the logistical elements are the heuristics that the team follows. The heuristics can be predicated off of the basic elements of what they do: operational terms/definitions, test techniques, test types, test deliverables, etc. Here’s a basic visual aid:

 project     project     project
  | |         | |         | |
  | |         | |         | |
  | |         | |         | |
   L           L           L

================================
           Heuristics
================================

\______________________________/
         Test Strategy

(Okay, so I never claimed to be an artist.)

The general idea here is that each project on which testing is being done will have one or more testers applied to it and that tester (or subset thereof) will be able to use situated reasoning to work on the project, based on the context, with the general framework of logistics (L) that have been established. That general framework is all based on the overall Test Strategy. What links the two — what links the strategy to the logistics — are the heuristics. Note that the intervening element of the heuristics is what allows you to be flexible in your interface with teams during a project and yet still adhere to a strategy that is more rigid in nature.

A key point of this, not obvious from the visual, is that the reason your strategy is a more solid is because it is made up of the core things that you believe must be done in order to be truly effective and efficient.

The strategy is composed of those elements that you do not believe can be compromised if any value is placed on testing at all.

However, there’s also the reality that you need to be flexible. But you don’t have to compromise your principles in order to be “agile” or “flexible.” Your heuristics allow your logistics to be flexible because they should be guiding you in what techniques to use given the resources and constraints that are currently placed upon you.

Think of the heuristics as a sort of prism that reflects the light of your strategy, but in different ways depending upon how it is being viewed.

This means the test team can change their strategy without worrying about totally affecting their interface with other teams. Likewise, the test team can improvise on their logistics without totally sacrificing their overall strategy. This makes the team’s process truly modular and allows them to be future-mobile: meaning, moving into the future with minimal dislocation due to environmental, technical or organizational changes. My contention is that when you have that kind of thinking in place, you then have more of a foundation for taking a test team into the realm of quality assurance. (Not necessarily a “Quality Assurance Team“, since I argue a bit against the automatic idea that quality assurance should be a “team.”)

I think that good operational distinctions between what’s part of a strategy and what are the logistics that speak to that strategy leads a test team to three concepts that should be seriously considered: Problem-Focused Process Development, Methodology Engineering, and Situated Reasoning. I won’t go into those topics here but I’m sure I’ll visit them in some future posts. Right now I’ll be perfectly content if I’ve done nothing other than make it clear why I harp on test strategy as an important concept, as distinct from test plans and test logistics.