Even small projects can benefit from test plans, though the tests may be more informal than on large, cross-functional software projects. The templates and guidelines on this page can help you develop a test plan that makes sense. (See also our Know-How page on Testing Techniques.) But remember, you can't test-in quality. The guidelines, processes, and checklists here will help you develop an overall quality assurance and quality control plan for your project environment. You may want to check out our templates for design reviews and requirements management as well.
Release Decision Process Guidelines
Process that can be used near the end of a project to systematically review open issues and determine which ones must be corrected before release.
Software Bug Fix WBS
WBS for an efficient but reasoned bug-fix project, which can be expanded for a minor enhancement or re-engineering effort or used as a checklist for small clean up projects. The included Word file provides an overview and explanation of the MS Project WBS.
Review Checklists: Preliminary Design Review
Checklist for Preliminary Design Reviews (PDR), to allow the Project Leader and team to suggest alternatives in product performance, time-to-market, product and project cost, and risks.
Review Checklists: Detailed Design Review
A checklist for conducting a Detailed Design Review after a preliminary specification has been written, and sufficient detailed design work and/or simulation has occurred.
Phase Signoff Process
This guideline shows a team's process for getting meaningful executive signoffs at the end of key project phases, to approve transition to the next phase and expenditures.
Test Plans and Related Documents
Project Test Plan
Creating a formal test plan document gives the testing team a well thought out, proactive approach to the software quality control process. It provides a mechanism for ensuring appropriate coverage of the system's requirements. Testing without a plan leads to chaos in the test phase. This plan outline walks you through the process with detailed annotations.
Beta Test Plan
An annotated outline for a full beta test plan document, testing that is often critical for exercising the product, service, or system in a way that cannot be duplicated in the "lab"; and getting customer and end user reaction to the functions and features.
An outline for documenting how the hardware and/or software in a system will be integrated before system test. Great for making sure the integration steps have been thought through (rather than defining an amorphous block of time for integration then hoping everything comes out at the end!)
System Test Plan
An annotated document outline for a System Test Plan. Describes how the team will internally verify that the system as a whole functions as planned under a variety of use conditions, before performing any external customer beta or acceptance testing. Also includes System Test Report outline for documenting and communicating results.
Master Test List
A tabular format for listing the tests to be run during a testing cycle, such as Beta, System test, etc.
Project Overview Test Plan
Our Project Overview Test Plan shows how to document at a high level how a system will be tested in different ways during the project to ensure it meets its user requirements and technical specifications and functions properly.
Software Test Transfer Forms
Practical forms to accompany a software build when Development sends it Testing, to serve as a record of what is being transferred, testing instructions, and ultimately a record of what was tested and the results.
Software Release Life Cycle Phase 6: Integration
Covers documents and activities needed to get all the parts, projects, sub-projects, modules, libraries, packages, etc. that are part of the release working together for the first time as a cohesive system.
User Acceptance Test Plan (IT)
Annotated outline for testing to be executed by users of a system or application prior to the production-level build and deployment.
Tools and Equipment List
This template provides a format for thinking through and documenting the tools (e.g. hardware, software) and equipment needed during a project for testing, prototyping, etc.
Requirements Traceability Guideline
Tracing your requirements to tests, to code, or to other requirements, can be a complex and time-consuming effort. If you're contracted to a government project you may not have a choice. But is it worth it in the private sector? This guideline discusses traceability processes, requirements, and how to weigh the costs and benefits.
Change Control Form
A form for requesting and documenting changes to the project (e.g. adding new features) or to elements within the project (such as changing a major spec of a piece of a system, product, or other deliverable). Includes fields for impact of the proposed change on the project timeline, budget etc., and on the components of the project deliverables.