What are the main points that should be included in a test strategy document for a particular project? I'm not looking at details but more from a high level overview.

I would like to make it a brief as possible to encourage as many people as possible in the organisation to read it and more importantly remember it.

5 Answers 5

  1. Introduction (This should be brief, something like why we test our applications and why it's important)
  2. Scope and limitations of our Test platform
  3. Resources (Software ex Selenium, Test Scenarios, Links for tutorials)
  4. Procedures (How to register a bug or tests priority)

But in general the documentation changes according to whom it is intended for, example a person in the Accounting dept. does not care about the testing so you should only present him the procedures chapter and even that should be very brief.


I found this document based on IEEE-829 and have used it for rough guidance, but remove categories that seem like overkill for my team or merge categories that seem similar. Since I started doing this, I've received many compliments on the clarity of my test plans. I use a wiki for documentation, which makes it easy for users to jump to the sections they care about.

UPDATED: Previous link no longer exists, so switched to a similar resource.

  • -1 for not including any of the content of the link. The page now returns a 404. Jun 18, 2017 at 13:23
  • Hi Mark, thanks for letting me know that the link was broken! The content was a fairly long list of recommended sections for a test plan. Including the content, beyond to say that it was based on the IEEE-829 seemed like overkill; if the link went bad, I figured the information in the summary would be enough to Google an alternative (and, at least for me, it was). I've updated the link, and the search terms I used to find this article were "agile IEEE-829 test plan template" in case it also goes stale. Jun 20, 2017 at 0:40

I would say why only create a document. You can create a mind map or a any other visual representation of what are you trying to convey. Its a nice way to get your message across and won't cost you any words at all. I have used test strategy to communicate in essence, only the following things

What you plan to do ? How you are going to do it ?

If I am able to answer these questions, atleast in my head I am clear what needs to be done. To communicate it to others should not be that hard once you have figured it out. Create just enough documentation to avoid any waste and so that you can keep it updated. Test startegy will evolve over time like your AUT and creating comprehensive documentation could be a overkill.


I have moved my team completely away from test strategy documents. We are using mindmaps instead as they paint a great picture of what you are trying to test and allow for quick conversations with development and analysts. You can then continue to flesh them out and move to test ideas. Excellent blog about this - http://www.bettertesting.co.uk/content/?p=956

  • +1 for the blog post. I switched to mind mapping for large agile projects as well and I'm pleased with the results. Much easier for others to read. Xmind is great b/c its easy to use, great looking, and free. Mar 2, 2012 at 15:27

It's interesting that you mention it's important for as many people as possible in the organization to read and remember your test strategy. I infer that by default, people will not read or remember your test strategy. That tells me you want a document that is both instructive and persuasive. If you want someone to read all the way to the end, you ought to start by telling them why they need read and remember it, i.e. why they should care. If you're a powerful writer, it is possible that you can take something as -- let's be honest -- dry and uninspiring as a test strategy document and convince people it's important. On the other hand, if you write on par with the rest of us, perhaps a leader in your organization needs to impress upon the team why the test strategy matters.

Persuasion aside, I think you should cover the goals that the test strategy seeks to reach, the technology you intend to use, and the schedule you need to follow.

  • 2
    I feel that people skim rather than read if they are presented with a large document on a dry subject.
    – stuartf
    Jun 8, 2011 at 22:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.