Once in a while it's difficult to hit the kill-button on the remote while show after show rolls over the screen. Occassionally something interesting comes along. This time it was an analysis and review of two famous marine assaults, their planning, strategy and outcome.
What struck me in particular was the strategy, which resembles very much what we do in software testing.
The strategy for the marine assaults was laid out to contain objective, intelligence, approach, assault, lodging and break-out.
Here's how that goes for software testing:
This is what we want to accomplish, in short our mission statement - the entire purpose of the operation. Usually we talk of it as a want of demonstrating the systems functionality, or that it will break, or figuring whether it is or isn't vulnarable to a certain threat or risk. But like an army we actually want to conquer and gain control. Marines deals with territory. Software testers deals with information and knowledge.
Once we put our eye to what we want to do, we need to start gathering intelligence, or information. We need to figure whether it's actually possible. No good landing on a beach full of quicksand, right ? Just as bad to base your test on getting data from an external system you can't reach in the test environment. In a way this represents our first test results, but it's just what is needed to sanity check our plan.
Sure if you're about to land an army at position X, you need to transport it there, without getting sunk, hit or devastated before you reach X.
Likewise in testing - we need to find a way to approach what we're searching for, in a way so we will have all the necessary power and initiatives ready for the actual assault. In other words, we need to prepare test data, user priviliges, test environment and so forth. If we've decided to try to print 1.000 tickets, then we should make sure that the system contains 1.000 tickets in a state where they are ready to be printed.
How do we do it ? Land the full force in one go ? Establish a single, narrow bridgehead, or spreadout for a simultanous attack on several weak spots at the same time ? It's different from approach, which we can plan ahead and even refine in detail. During the assault we must be agile, open, observant and ready to change direction, method and toolset. Until now we've only modelled the 'landscape', so when we set our foot there, surprises are to be expected. This is also what makes this very interesting.
We never really think of it, but of course we have to settle down in the newly won territory. We need to make ourselves safe and enable logistics. We need to transport data (troops and supplies) to the frontline. We need to examine the new ground we conquered. Isn't that what we do ? The first login is always a bit trembling. Soon we login and go much further without blinking. And while some testers will be operating on the frontline, others will have to take on the tasks of creating more test data, hooking up new equipment etc etc. Logistics necessary to keep the operation going.
This is the one that makes it all fit together - we can't stay on the beach forever. We can't live with a frontline three miles into the country. We need to 'break through' and finally accomplish our goal. Marines don't establish a bridgehead on a beach just to claim the beach. They do that in order to accomplish something more. Now we've invaded the system, we need to find the weak spots and/or the opportunities to carry on, to conquer the remaining part of the system, so to speak.
I think this is a brilliant way of putting together a strategy, also for software testing.
Don't you ?