Recently i have posted a couple of replys on the Microsoft Software Test forum – http://msdn2.microsoft.com/en-us/testing/default.aspx – click the link entitled Software Testing Discussion Forum.
There are a couple of posts on Test Strategy and Test Plans and what they are. Quite often the two terms are interchangeable and used indiscriminately. A Test Strategy (according to ISTQB) is the document that describes the methods of testing or the how. Whether this document is pitched at an enterprise level or a project level is open to discussion but essentially the Strategy is projecting ideas over a longer period of time.
The Oxford Dictionary defines Strategy as “… a plan designed to achieve a particular long-term aim” and as such looks at the ‘bigger’ picture.
A Test Plan describes the ‘How’ at a lower level. IEEE 829 (on which there is much debate on the revision currently being voted on) introduces the structure of should be incorporated in the plan. It is comparable to tactics which again according the Oxford Dictionary is “…an action or strategy planned to achieve a specific end.”
Whether you use either or both terms or documents is up to you. As testers we sometimes become involved in paper wars and become document heavy at the expense of efficiency and effectiveness. Whatever process you follow the key for any test document is effective communication.
Bj Rollison – a Test Architect at Microsoft (http://blogs.msdn.com/imtesty/about.aspx) sums up what happens if we stop thinking about how and what we use these documents for…”The only testers who stop thinking critically about tools and the application of tools we can use in the appropriate context are testers who have a limited understanding of the overall responsibility of testing, and know even less about the tools they are tyring to use.”
Great quote – i totally agree. Whether its a Test Strategy or Test Plan, it is a tool whose purpose is to serve us and guide us in our testing activities.
If you are responsible for producing said documents, please be critcial in your thinking and look at the best way to communicate to all those involved in your sphere!
The 2006 NBA season the Phoenix Suns Strategy vs. the LA Lakers was “…Phoenix’s strategy against the Lakers this season has been to contain everyone besides Kobe Bryant, and it’s worked. Bryant had 39 points in the first meeting and 37 in the second, but no other Lakers player scored more than 17 in the two games and the Suns simply outscored Los Angeles, averaging 114 points.” – Yahoo Sports.
There is your Strategy, the plan is how each Sun player played defense against their man.
Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat.– Sun Tzu
Brian Osman 
$columns[4]
———————–
3 Principal Test Documents
———————–
1. Test Policy (Organisation Level)
– Very High Level Document
– What “Testing” means for organisation
– How organisation measures test success
– Relatively static document (Changes when organisation’s focus changes)
– Developed by IT department
2. Test Strategy (Programme Level)
– Applicable for a Programme/System which covers multiple projects
– Objective/Scope of Testing
– In scope/Out of scope Items for testing
– Test Levels (Unit/Module/System/Integration)
– Test Types ( Functional/Non-Functional)
– Entry/Exit/Stop/Resumption Criteria for testing (for different Levels/Phases)
– Risks to be addressed
– Test Environment
– Test case design methodology (Specification driven/BVA/EQ Partition)
– Test methodology ( Top-down/bottom-up/risk based)
– Test Automation Approach
– Test Tools to be used
– Defect Management approach
– Defect classification
– Retesting & regression approach
3. Test Plan (Project Level)
– All above points specific for this project
– Test Estimation & Test schedule
– Test Organisation/roles/responsibilities
– Test deliverables
– Test reporting
Which of course is very ISTQB/IEEE 829 and there is nothing wrong with documents in the relevant context.
However we must be aware that reliance on a template without thought produces zombies (http://www.amazon.com/Adrenaline-Junkies-Template-Zombies-Understanding/dp/0932633676) that produce worthless plans. WIthout the thought and context, the plan is merely a product that may not have any noticable benefit other than to have a document. I have seen too many copy and paste “test plans”.
General Esienhower once said “In preparing for battle, i have found the plan to be worthless…but the planning has been indispensible.”
Don’t hung up on the document itself but understand your context, organisation and the valuable thought process directed towards your testing project.
Thanks for the post 🙂
This is an excellent document and summarises nicely the division of opinion on the separation between a strategy and a plan. Another description I have come across is ‘a plan represents the implemenation of the strategy’, which implies that a strategy is a separate, company level document.
As your article points out, regardless of the terminology used (although it is helpful if everybody uses and understands the terms used in the same way), the information these two documents provide should be represented in some form or other. If they are not two documents, then all you have got is a plan.
Rick Briggs.
Thank you for posting “Test Strategy vs. Test
Plan Brian Osman”. I reallymay definitely wind up being
back again for alot more reading and commenting here shortly.
Many thanks, Randolph
The fresh idea is here). I’ve read the post with great satisfaction and
also could know something new that I will use for
my additional requirements. The article is bright and clear, with no additional useless facts or else, it
reminded me https://edwardtimpsonmp.com/how-to-write-a-hook/. The speech is both brilliant and
vivid, so the more I read, the more I do enjoy it! Besides, the information is
rather cutting edge, so just like it.