I started writing a test strategy document (introduction and purpose of the new feature, pre-requisites to enable the feature and high-level test cases), but at the end it looked like an acceptance test plan. I'm confused about test strategy documents compared with acceptance test plans. What should a test strategy document contain?
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
I recently saw fellow SearchSoftwareQuality.com expert Karen N. Johnson give a talk on the topic of creating a test strategy at the Pacific Northwest Software Quality Conference in Portland, Ore.
During the talk she had a fantastic quote: "The great thing about a test strategy is that if you don't write one, one will write itself." Karen continued, pointing out that a test strategy is not actually written by you, but by all the assumptions people have about what they think you're going to be testing. Only later will you find that you probably would have saved yourself a lot of time and energy by writing something down up front.
That's what a test strategy is all about. It's your way of telling the rest of the project team what you will and won't be testing and how you plan to do that testing. It's a high-level communication that conveys intent. Another idea that came out of Karen's talk is that you can also view the test strategy as a testing "bill of goods" or "statement of work." It's your way of telling people what you plan to deliver.
A test plan on the other hand is more about the specifics of your testing. It's logistics, test cases/scenarios, and resources, and it contains all the dependencies and risks that you need to focus on while testing. SearchSoftwareQuality.com expert Scott Barber talks a little more about the differences in his piece on test plans, strategies, and logistics. Karen Johnson and I also wrote an article that outlines some of the differences between test strategies and test plans. As both of those references illustrate, it's the document that's used to direct and guide the testing effort.
One of the problems that you may be struggling with is that in smaller projects, the strategy and plan sometimes morph into one document. It's OK if that happens. What's important is that you get the mileage out of the document that you need. Is it helpful to you and others in understanding what you'll be doing? Does it represent your testing bill of goods? If so, it's a strategy. If the document can also be used to guide the actual testing project and deals with some of the logistics, resources, and scenarios, then perhaps it's also your plan.
I also wrote a fun article in December 2004 about a project where our team drafted the basic test strategy on a whiteboard. And Karen has an excellent article that explains more about building a software test strategy.
| A test strategy is your way of telling the rest of the project team what you will and won't be testing and how you plan to do that testing. |
That's what a test strategy is all about. It's your way of telling the rest of the project team what you will and won't be testing and how you plan to do that testing. It's a high-level communication that conveys intent. Another idea that came out of Karen's talk is that you can also view the test strategy as a testing "bill of goods" or "statement of work." It's your way of telling people what you plan to deliver.
A test plan on the other hand is more about the specifics of your testing. It's logistics, test cases/scenarios, and resources, and it contains all the dependencies and risks that you need to focus on while testing. SearchSoftwareQuality.com expert Scott Barber talks a little more about the differences in his piece on test plans, strategies, and logistics. Karen Johnson and I also wrote an article that outlines some of the differences between test strategies and test plans. As both of those references illustrate, it's the document that's used to direct and guide the testing effort.
One of the problems that you may be struggling with is that in smaller projects, the strategy and plan sometimes morph into one document. It's OK if that happens. What's important is that you get the mileage out of the document that you need. Is it helpful to you and others in understanding what you'll be doing? Does it represent your testing bill of goods? If so, it's a strategy. If the document can also be used to guide the actual testing project and deals with some of the logistics, resources, and scenarios, then perhaps it's also your plan.
I also wrote a fun article in December 2004 about a project where our team drafted the basic test strategy on a whiteboard. And Karen has an excellent article that explains more about building a software test strategy.
This was first published in November 2008