Software Testing Help has a decent outline for a test plan template. Designing a test plan template is a relatively...
straightforward process, but it is helpful to have an experienced test manager build that template for you or, better yet, along with you. If you post to some of the testing-related user groups, you should be able to find someone willing to help you craft a template that fits your needs.
The goal of the test plan is to capture the strategy needed to sufficiently test the project at hand. It scopes your thoughts, leading you from one testing topic to another. It is NOT a place to store test cases, but rather a place to organize your thinking. For instance, a test template might call out a series of operating system and language combinations -- test cases would capture each of these combinations as a check list.
It's also a place to document dependencies -- especially dependencies on downstream groups such as database administrators or legacy applications. Raising dependencies here helps you, as the test manager, collaborate with other groups early in the project and prevent that last-minute fire drill.
Another purpose of the test plan is to document risk. When you call out a risk (for instance, testers only available part-time), it gives you a chance to think up a risk mitigation plan (how to prevent the risk from actually occurring) and a resolution plan (how to cope with the risk if it arises). It raises awareness to management, and helps them decide whether the risk is great enough that they should take steps now to prevent it.
Your test plan will organize and categorize the testing. You might be asked to calculate estimated testing costs, and some plans even include test schedules. This is where you begin to think about your testing staff and how to split the work up. I generally do not start any of the scheduling until my plan is complete and I've been able to estimate costs. Only then do I consider how to break this out and share it across my team.
Finally, a couple of critical elements of the test plan are 1) defect management and 2) the project's exit criteria. Defect management describes how defects will be documented as well as the process for moving defects through their lifecycle. This is where you gain consensus from business and customer partners for managing bugs. The exit criteria is a key part of your overall plan, because exit criteria describe how the team will know when the project has been completed. Defect status is a core element of exit criteria, as well as test pass status. Other elements depend on what the team wants and how the organization works.
To be quite honest, your best bet for building a test plan is to bring in outside help the first time or two that you do this. Find a testing consultant who is not interested in forcing their testing process on your organization, but is interested in helping you find the right plan for your style. You might find help online, or you might look locally or even internationally. If you live in an exotic location, you might find an experience test manager willing to come on-site to help, in exchange for travel and expenses. By bringing in experienced help the first time, your first project will be more successful. In addition, you'll be able to write future test plans to the same consistent level.
Dig Deeper on Software Testing and QA Fundamentals
Related Q&A from John Overbaugh
Learn what's behind AWS outages and how to fix failures before they happen. Continue Reading
Learn strategies for best security test strategies for SaaS cloud. Continue Reading
Expert John Overbaugh identifies the three top concerns of the test manager and offers advice on how to stay ahead of the curve when it comes to ... Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.