Test Plan Template

The Test Plan describes the overall approach to development, integration, qualification, and acceptance testing. It describes plans for testing software systems; test environment to be used for the testing; identifies tests to be performed, and provides schedules for test activities.

The software Test Plan is used by IT Manager, Test Manager, Documentation Manager, System Administrator, Technical Architect, Development Manager, Project Manager.

The Test Plan is used to perform system testing, subsystem testing, assembly testing, subassembly testing, module testing, user acceptance testing. The Test Plan includes step by step instructions for the various types of testing that will occur during the project lifecycle; it also defines the required test equipment, calibration requirements, test facility requirements, and other key factors.

This is a sample of an outline for a test plan. It has been designed for medium to small test projects, and thus is fairly lightweight. It is by necessity general, because each enterprise, each development group, each testing group, and each development project is different. This outline should be used as a set of guidelines for creating your own standard template; add to it or subtract from it as you find appropriate.

This section contains the purpose and objectives of the test plan.


Items to be tested Refer to the functional requirements that specify the features and functions to be tested.


Items not to be Tested List the features and functions that will not be covered in this test plan. Identify briefly the reasons for leaving them out.

Testing is the process of analyzing a software item to detect the differences between existing and required conditions and to evaluate the features of the software item. This may appear as a specific document (such as a Test Specification), or it may be part of the organization's standard test approach. For each level of testing, there should be a test plan and an appropriate set of deliverables. The test strategy should be clearly defined and the Software Test Plan acts as the high-level test plan.


System Requirements :
This section should be filled out in detail for new projects. For existing maintenance tasks, a simple cross-reference to the document describing existing system requirements is fine.

Hardware/ software requirements :
This section contains the details of system/server required to install the application or perform the testing, specific s/w that needs to be installed on the system to get the application running or to connect to the database, connectivity related issues etc.

• Identify the estimated effort required to execute the test plan. Include a both a range and a confidence level. Identify the resources available to carry out the test plan.

• Identify time or resource constraints that will lead to a risk of the test project falling behind schedule, below expected scope, or below expected quality.

This section will explain the roles and responsibilites of the management team, testing team, Business team, testing support team and external support team.

This section contains various deliverables that are due to the client at various points of time. i.e. daily, weekly, start of project, end of project etc. these could include test plans, test procedures, test matrices, status reports, test scripts etc. templates for all these also be attached.

This is a particular risk clause to define under what circumstances testing would stop and restart If any defects are found which seriously impact the test progress, the QA manager may choose to Suspend testing. Criteria that will justify test suspension are:
Hardware/software is not available at the times indicated in the project schedule.
Source code contains one or more critical defects, which seriously prevents or limits testing progress.

Assigned test resources are not available when needed by the test team.
Define in advance what could go wrong with a plan and the measures that will be taken to deal with these problems
The event causing the risk.
The likelihood of the event happening.
The impact on the plan if the event occurs.

Apart from manual testing list the tools used for automating the unit testing, functional testing, performance testing and user interface testing.

This section contains the embedded documents or links to document which have been/will be used in the course of testing. E.g. Templates used for reports, test cases etc. reference documents can also be attached here.

This section contains the mutual agreement between the client and QA team with both leads/ managers signing off their agreement on the test plan. 

Contents of test plan:

• Introduction:
• Scope
• Test Strategy
• Environment Requirements
• Test Schedule
• Resources and Responsibilities
• Deliverables
• Suspension / Exit Criteria
• Risks
• Tools
• Documentation
• Approvals