- 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
- 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.
Dig Deeper on Topics Archive
Related Q&A from Karen N. Johnson
User acceptance testing and system integration testing differ in one key way: the person who does the testing. Learn when to apply UAT vs. SIT. Continue Reading
There are so many resources out there about the ever-changing world of Web design and mobile testing, but to choose the most salient and insightful ... Continue Reading
In this expert response, consultant Karen Johnson describes strategies she uses for browser compatibility testing. Experience and knowledge of common... Continue Reading