Is it possible to create a generic Test Strategy? Henrik Emilsson
The short answer goes:
No, of course you can’t!
Once upon a time, I got the possibility to read a test strategy document written by a business colleague of mine. The strategy was a 47 pages document that tried to cover all aspects of testing that I guess would apply to all projects; because in the beginning of the document, it was stated that the strategy is “… generic in nature and should apply to any I.T. project.”
If you try to interpret the statement above, it means that the strategy is non-specific and there is no project that this strategy would not be applicable for.
How is that possible? And why would it even be interesting to use such strategy? And for whom is this strategy?
Would you trust your national army if they had a generic strategy that should apply for all wars? Could it be so that combat situations, terrains, opponents, stakes, etc could differ?
Would you feel confident in your company’s marketing department if they had a generic strategy that should apply for all future marketing engagements?What if you had a generic strategy for playing chess and not adapt to your opponent moves? A strategy that would treat each game same as the others.
What if you had a generic strategy for raising and fostering your children? Or what if you had a generic strategy for how to interact with your colleagues? What if these two strategies were the same, since they are generic and would apply to any human social interaction?
Is there a chance that other people might think that you are strange if you had one generic social interaction strategy?
The context differs between different projects; and the context often changes during a project.
We would be doing all project stakeholders and members a favour if we designed a test strategy that was driven by the current project context; a test strategy that would be updated whenever the context changes. That is, a test strategy that is specific to this project and is therefore only applicable to this project.
The short answer must be: Yes, you can!
And yes; it will be worthless!
I’ve written a general test strategy, but it is specific for the type of projects that we do at my company.
I’ve written a test policy as a presentation for management and for personel who are lack knowledge about what testing and quality implies. I focused on talking about costs, definitions and roles.
Next thing I did was the test strategy talking about different levels in testing, who in the organisation what is supposed to do what, also mentioning a various selection of testing techniques such as exploratory testing, rapid testing, scripted testing, automated testing etc. Basically mentioning that there is a huge tool box to be used.
The test plans then states a bit about some techniques that we intend to focus on in the project.
I’d say that in some context I agree fully with the two of you, but in other contexts like my own a general strategy helps. Still, it does not help the testers any but it helps for other personel understand. So, who are the test policy and test strategy written for? I’d say for the company and all its personel. The test plan has smaller focus group though.
It might be easy to say that what I’ve written is not a strategy and that I should call it something else. If that is the case, then I agree with you fully.
Rikard,
I agree! 🙂
Martin,
It might just be wordings (as so often in this business), but as I see it, the test strategy specifies the relationship between the test project and the test mission. So the strategy deals with how we will test; i.e. how the test missioned is going to be carried out.
If this strategy is general (or generic), the test mission and test project would be very similar. And if they were very similar, it looks to me like a remake of a project. And if a project is remade, it might be a good idea to change whatever went wrong the first time. Something caused the remake! 🙂
In my original post I described that a test policy is generic for all projects and specify the guidelines and policy that matter on a company level. I deleted that part because I do not really believe that it is true all the times. In fact, I think it should be different in many cases.
E.g., the things that matters on a company level might very well differ between projects and products in the company portfolio.
– The company might have different objectives for their cash cow versus the new experimental product that is about to hit a new market.
– Their third product that has a specific type of customers might also have a specific set of objectives.
Shouldn’t these objectives in some way drive the testing; shouldn’t these objectives be considered when thinking of your test project context; and wouldn’t this influence your test mission?
So maybe the test policy would be so full of “unless otherwise stated”-clauses that you might wonder if the company test policy should be destroyed, and only use project-specific test policies, test strategies, test plans, etc.
A generic advice: In general, be more specific!
I think the error I and prolly many more do is trying to explain testing the same time as trying to advocate a policy and various strategies.
If I instead split these things appart I think I’d agreed with ya 100%.
/M
Good point Martin!
In practice, I am making too much of that mix-up myself.
Actually, this subject would be worth a separate post (or several).
/Henrik