Q
Problem solve Get help with specific problems with your technologies, process and projects.

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

Developing a test plan when crucial documentation is not present can be tricky. Expert Karen Johnson teaches how to assemble a test plan when documentation and necessary information is absent.

How do I develop a test approach when there is not much documentation?
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 last published in July 2010

Dig Deeper on Software Testing Methodologies

PRO+

Content

Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchMicroservices

TheServerSide.com

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

DevOpsAgenda

Close