Test Strategy documents make nice blue fire - By André Vondran

Most organizations assume that test strategy should be defined by test managers, tech leads or executives. Perhaps because anything involving the word ’strategy’ is open to interpretation giving it a mystique-laden abstract quality, therefore it is erroneously offered up to the intellectual elite (said tongue-in-cheek) i.e. upper management as a job function.
The chairman of Greyhound once said: ‘a strategist’s job is to see the company not as it is but as it can become’ (JW Teets)

The truth is, most of the test strategy documents produced by said upper management, tech leads and the like are really just templated after-thoughts that regurgitate and rubber-stamp the currently accepted development process (hereinafter referred to as the status quo). They’re written to appease some organizational bureaucrat or to give the illusion of productivity from an administrative role but ultimately they are neither read, nor referred to nor in any way applied to the organization in a manner that justifies the half-day management salary it cost to format the headings and line up the dots in the table of contents. Clearly these types of ‘test strategy’ documents miss the whole point of the game.
So what type of test strategy would openly defy the institutional silver-back templates and provide real value in a fast-paced, roller-coaster web application agile environment? I’m not talking fifty page tome with boldfaced fonts and anchored sub-sections. I’m talking dog-eared worn-from-use concept that’s carried around lovingly by team members and incorporated into the tasks of daily development life.

What can this organization become and how can we get there?

If you think about it, the idea of a strategy is really pretty simple. It’s taught to us from the time we’re old enough to play checkers and we implement it every day whether we’re consciously aware of it or not. What makes a strategy seem complicated are the multiple levels of engagement. To make it less complicated, I break it down into three basic angles of approach:

1. Identify risks and form a response
2. Make efficient use of resources
3. Affect change or realize goals

When it comes to a software development environment the test strategy should be an ongoing endeavor. It redefines itself iteratively throughout the life of the project. No wonder no one reads those test strategy documents that PMO’s mandate. They’re useless in the real world because the idea of regenerating a 4 page table of contents and reformatting all those headings in Word every time you iteratively change your strategy is not scalable if your strategy changes every day.
HINT: your strategy changes every day.

Think about it. In my little model above, the first approach to strategy is to identify and respond to risks (which incidentally is the only reason a testing role exists in any organization). Newsflash: risks don’t line up passively at the beginning of a project and wait around for you to pick them up, hug them and adopt them for your very own. They’re risks because they contain an element of the unknown. You can only identify them as they become visible. In other words, they change over the course of the project and they are about as predictable as a pit viper.

In case you weren’t paying attention to my first paragraph, what I’m getting at here is that any thinking person can formulate strategy. The problem with creating an over-arching test strategy is that there is an assumption that the strategic part of testing is taken care of and no further thought is given. There is no way a single document can encompass the dynamic nature of strategy. Nor is there any way a single person can control the shifting aspects of strategy for everyone in the organization. The best strategies arise from a shared vision and are implemented and challenged collaboratively by each member of the team.

I believe test strategy should be an organic coordinated effort that is produced by the testers themselves in concert with developers and designers. Managers obviously strategize too. Part of that strategy should be to give the team members the tools they need to strategize effectively in their daily tasks. This might involve a way to communicate risks to the team, a daily evaluation of resources and a willingness to respond to changing landscapes. Unfortunately there are so many large organizations out there where a testing function is divided into hierarchical levels where you have the strategizers who do nothing but write tests cases and PMO documents and you have test lackeys who go through and check off tasks given to them by the strategizers and they are never to deviate from the given set. Not only is this inefficient but, man, that test lackey job totally sucks.

Testers are generally intelligent creative people, and it’s a total waste of resources not to give them the creative freedom and the business knowledge to take a well-thought out strategic approach to their work on a daily basis.

My advice if you’re a victim of test strategy documents: steal it and burn it.