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.
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.
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
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.
