How to develop a test plan when there isn't much documentation

How to develop a test plan when there isn't much documentation

How do I develop a test approach when there is not much documentation?

    Requires Free Membership to View

    Login

    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

    By submitting your registration information to SearchSoftwareQuality.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSoftwareQuality.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

Your question doesn't mention what documentation is not available or how the lack of documentation is a hindrance. It sounds like there is information you feel you need in order to plan testing, if that's the case then you might have to dig in and do some investigating to fill in the gaps of what you have versus what you need. Investigating might include:
  • Interviewing subject matter experts
  • Reviewing product design with other team members
  • Reviewing product release notes from past releases

Alternately, if you cannot gather the information you need, you might need to forge ahead and plan what you can and begin writing a plan - just the way you would if you had the information and include assumptions or constraints in your draft approach. I'm guessing your reference to a test approach is a document I typically refer to as a test strategy. A strategy identifies the game plan for testing a product and includes how you and your team will tactically go about testing the product.

Strategy documents can contain a whole array of subtopics as well - all based on the product and the context in which you're working. Here are some examples:

  • Test data
  • Test environment
  • Assumed resources
  • Dependencies
  • Release criteria

If you know the product, and I'm guessing that you have at least a big picture view of what the product is supposed to do, then you probably have ideas about how to approach the testing. This background and knowledge is hopefully a good start in drafting a strategy. You might find something I often find in writing - which is once you write and offer your document to other people - other people step forward with ideas and help fill in the gaps with the details you wish you had already. In other words, once you're a writer, the whole world seems to be an editor!

Another possible solution would be to draft as much as you can and host a review meeting to fill in what you don't have. Once other people on the team can see the holes in the information, they may step forward and provide or resolve those open questions. Consider whether you want to provide a draft in advance of the meeting or not.

And all this aside, I wonder if there is such a lack of documentation - then I find it curious that you are so concerned with the documentation you plan to write. Is there a reason that testing needs such a comprehensive written document when it does not sound as though the environment or the team is focused on documentation?

Whatever that reason is - politics, you trying to implement process, or you trying to implement documentation - be mindful of that reason because behind that reason is your primary objective of drafting your test approach so make sure to address this need.

This was first published in July 2010

Back to top