The Test Plan is the "Overall" description about how the 
testing department intends on handling the application 
testing phase.  The Test Strategy is a subset of the Test 
Plan explaining "how" the application will be tested.

 


[Company Logo]






Test Plan
Version 0.0

Description of Project












DOCUMENT NO:
VERSION: 

CONTACT:  	[Name]
EMAIL: 	  	

DATE: 	  	3/31/2009 








Distribution is subject to copyright.
 

Disclaimers
The information contained in this document is the 
proprietary and exclusive property of [Company Name] except 
as otherwise indicated.  No part of this document, in whole 
or in part, may be reproduced, stored, transmitted, or used 
for design purposes without the prior written permission of 
[Company Name]. 
The information contained in this document is subject to 
change without notice.
The information in this document is provided for 
informational purposes only.  [Company Name] specifically 
disclaims all warranties, express or limited, including, 
but not limited, to the implied warranties of 
merchantability and fitness for a particular purpose, 
except as provided for in a separate software license 
agreement.
Privacy Information
This document may contain information of a sensitive 
nature.  This information should not be given to persons 
other than those who are involved in the Project Name 
project or who will become involved during the lifecycle
Trademarks
[Trademarks are added here]
Version History


REVISION CHART
Version	Author(s)	Description of Version	Date 
Completed
			
			
			
			
			
			
			

 
Document Owner

The primary contact for questions regarding this document 
is:
Author: 	
Project Name 
Phone:  	
Email:
Document Approval 

Document Name:	
Publication Date:	
Contract Number:	
Project Number:
Prepared by:

Approval:		__________________________
Name and Organization

Concurrence:	_________________________
Name and Organization

Table of Contents
1	Introduction	6
1.1	Objectives	6
1.2	Document Overview	6
1.3	Testing Strategy	6
1.4	Scope	7
1.5	Reference Material	7
1.6	Relationship to Other Plans	7
1.7	Key Stakeholders	7
1.8	Points of Contact	8
1.9	Methodology, Tools, and Techniques	8
1.10	Policies, Directives and Procedures	8
2	Test Items	9
2.1	Program Modules	9
2.2	Documentation Testing Procedures	9
2.3	Application Testing Procedures	9
2.4	Features Within Scope	9
2.5	Features Outside of Scope	10
3	Test Entrance Criteria	11
3.1	Documentation	11
4	Test Planning	12
4.1	Unit Testing	12
4.2	Integration Testing	12
4.3	Conversion Testing	12
4.4	Interface Testing	12
4.5	Security Testing	12
4.6	Recovery Testing	13
4.7	Performance Testing	13
4.8	Regression Testing	13
4.9	Acceptance Testing	13
4.10	Beta Testing	13
5	Pass / Fail Criteria	14
5.1	Testing Error Levels	14
5.2	Suspension Criteria	15
5.3	Resumption Criteria	15
6	Test Exit Criteria	16
6.1	Sample Software Release Form	16
7	Project Management	17
7.1	Test Deliverables	17
7.2	Testing Tasks	17
7.3	Risk Assessment	18
7.4	Constraints	18
7.5	Issues	18
7.6	Assumptions	19
7.7	Dependencies	19
8	Project Team	20
8.1	Roles and Responsibilities	20
8.2	Responsibilities	20
8.3	Resources	20
8.4	Training	20
9	Environmental Requirements	21
9.1	Hardware	21
9.2	Software	21
9.3	Security	22
9.4	Tools	22
9.5	Documentation	22
10	Plan Approvals	23
10.1	Sign-Off Criteria	23
11	Appendices	24
11.1	Glossary of Terms	24
11.2	Acronyms and Abbreviations	24
12	Appendix B — Sample Test Case	25

 
Index of Tables

Table 1 — Schedule	17
Table 2 — Testing Tasks	17
Table 3 — Risk Assessment	18
Table 4 — Constraints	18
Table 5 — Issues	18
Table 6 — Assumptions	19
Table 7 — Dependencies	19
Table 8 — Roles and Responsibilities	20
Table 9 — Hardware	21
Table 10 — Software	21
Table 11 — Tools, Techniques and Methodologies	22
Table 12 — Documentation	22
Table 13 — Sign-off Criteria	23
Table 14 — Glossary of Terms	24
Table 15 — Acronyms and Abbreviations	24
 
1	Introduction 
The Test Plan outlines the scope, approach, resources, and 
schedule of all testing activities. It identifies the items 
and features to be tested; types of testing; resource 
requirements; and an approach to project management.
1.1	Objectives 
Describe the high-level test plan objectives, e.g. products 
to be delivered, major activities, products, milestones, 
resources, and schedules.

1.2	Document Overview 
Outline the main sections in this document, for example:

•	Chapter 1 – Describe the contents of this chapter.
•	Chapter 2 – Describe the contents of this chapter.
•	Chapter 3 – Describe the contents of this chapter.
•	Chapter 4 – Describe the contents of this chapter.
•	Chapter 5 – Describe the contents of this chapter.

1.3	Testing Strategy 
For each level of testing, prepare a separate test plan 
with the following set of deliverables:
•	Features to be tested
•	Items to be tested
•	Management and technical approach
•	Milestones 
•	Pass / Fail criteria
•	Purpose for testing
•	Risks, assumptions, and constraints
•	Roles and responsibilities
•	Schedules
1.4	Scope 
Describe the scope (i.e. parameters) for the test plan(s).  
Also, list any areas specifically excluded from the plans.
Outline how scheduled and unscheduled updates to the 
Software Test Plan will be managed. 
	Separate Test plans must be developed for each 
level of product testing.

1.5	Reference Material
Identify all documents and sources referenced in the Test 
Plan. Cross-references to the following documents (where 
applicable) is required for the high-level test plan:
•	Configuration Management Plan
•	Company policies and procedures
•	Project authorization
•	Project Plan
•	Quality Assurance Plan
•	Standards

1.6	Relationship to Other Plans 
Describe this document’s relation to other plans, such as:
•	Program Management Plan
•	Configuration Management Plan
•	Software Quality Assurance Plan

1.7	Key Stakeholders
Outline the project’s key stakeholders, for example: 
•	John Q Public, the client’s representative 
•	Jane Q Public, Head of IT Dept.
•	James Q Public, Head of QA Dept.


1.8	Points of Contact
Outline the main points of contact for this plan, i.e. for 
troubleshooting purposes. 
Include the type of contact, contact name, department, 
telephone number, and e-mail address. 

1.9	Methodology, Tools, and Techniques 
Describe the software tools (or techniques) required for 
performing the respective tasks, e.g. software for managing 
changes requests.

1.10	Policies, Directives and Procedures
Outline the policies and procedures that apply to this 
document. Identify any external constraints or requirements 
placed on this document by policies, directives, or 
procedures. 



2	Test Items
Identify the test items that will be covered in this plan. 
Refer to the following documents where appropriate:
•	Design specification
•	Installation guide
•	Operations guide
•	Requirements specification
•	Users guide
•	Verification plans 

2.1	Program Modules 
Describe how each module will be tested. 

2.2	Documentation Testing Procedures 
Describe how the user documentation will be tested to 
ensure that it is correct, complete, and comprehensive.

2.3	Application Testing Procedures 
Describe how the application will be tested to ensure that 
it can run and supported in a production environment.

2.4	Features Within Scope
Identify all software features to be tested. Identify the 
design specifications associated with each feature.
	

2.5	Features Outside of Scope
Identify all features that will not be tested, along with 
the reasons for this decision, e.g. timelines, available 
resources etc.



3	Test Entrance Criteria
To produce software that meets client needs, certain items 
must be in place prior to the software entering the QA 
testing phase.  This document outlines the items that must 
be in place to promote software from the development group 
to Quality Assurance.


3.1	Documentation

The following articles of documentation should be developed 
and be available prior to testing:

•	Requirements specification
•	Design specification
•	Installation / Deployment guide
•	Operations guide
•	Users guide
•	QA Test Plan
•	Verification plans 
•	QA Test Cases

Describe how the user documentation will be tested to 
ensure that it is correct, complete, and comprehensive





The following articles of programming should be developed 
and be available prior to testing:

•	Front End Code
•	Back End Code
•	Operational Screens
•	Database Tables / Fields / Records
•	System Security
•	System Software and Hardware Requirements



Describe how the application will be tested to ensure that 
it can run and supported in a production environment


4	Test Planning
Identify the different types of testing and the methods and 
criteria for performing the test activities. For each level 
of testing, prepare a test plan and the appropriate set of 
deliverables. 

4.1	Unit Testing 
Describe how Unit Testing will be conducted to verify the 
implementation of each software element or collection of 
software elements. 
 
4.2	Integration Testing 
Describe how Integration Testing will be conducted on 
software and hardware elements, until the entire system has 
been integrated. 
This ensures that the design objectives are met and that 
the software complies with operational requirements. 
	Integration Testing is also known as System Testing.
		
4.3	Conversion Testing 
Describe how Conversion Testing will be conducted to ensure 
that all data elements (and historical data) are converted 
from the previous system format to the new system format. 

4.4	Interface Testing 
Describe how Interface Testing will be conducted to ensure 
that the application operates efficiently outside the 
application boundary.
	
4.5	Security Testing
Describe how Security Testing will be conducted so that the 
application systems control and auditability features are 
functional.

4.6	Recovery Testing
Describe how Recovery Testing will be conducted to ensure 
that the application’s restart, backup, and recovery 
facilities operate as designed.

4.7	Performance Testing
Describe how Performance Testing will be conducted to 
ensure that the application performs to customer 
expectations (e.g. response time).

4.8	Regression Testing
Describe how Regression Testing will be conducted to ensure 
that changes to the application have not adversely affected 
previously tested functionality.

4.9	Acceptance Testing
Describe how Acceptance Testing will be conducted to ensure 
that the system satisfies the acceptance criteria. 

4.10	Beta Testing
Describe how Beta Testing will be conducted to detect 
application faults, failures, and defects.








5	Pass / Fail Criteria
Identify the Pass/Fail criteria, i.e. whether an item has 
passed or failed its test.
5.1	Testing Error Levels

Error Severity  Level	Description
1	Highest Level 1 – 
Program aborts and cannot continue.
Testing must stop until the error has been corrected.
These errors are of the highest priority and should be 
corrected by the programmers as soon as possible.  
In some companies, these errors are reserved for problems 
that must be fixed within 24 hours.
2	Level 2 – 
A program module aborts and the module cannot continue to 
be tested. 
The rest of the program is operational and testing may 
continue on other modules while the error is being 
corrected.
In some companies, these errors are reserved for problems 
that must be fixed within 48 hours.
3	Level 3 –
A program module aborts however there is a work around.  
Testing can continue using the work around until the actual 
program error has been corrected.
In some companies, these errors are reserved for problems 
that must be fixed within 1 week.
4	Lowest Level 4 –
This is reserved for non-program functioning errors such as 
cosmetic items on the screen.  The program and it’s modules 
are functioning as designed however, items with this 
severity level may be items that are desired fixes and will 
be determined to be in the current release or reserved for 
later releases.
In some companies, these errors are reserved for problems 
that may be fixed in the current release or saved for 
correction in a future release.

5.2	Suspension Criteria
Identify the criteria used to suspend all (or a portion) of 
the testing activity.

If a Severity Level 1 problem occurs while in the testing 
phase, testing will cease until the problem has been 
corrected.

5.3	Resumption Criteria
Identify the conditions required to resume testing 
activities after suspension. 

To resume testing, the programmers will certify that the 
Severity Level 1 problem has been corrected and that the 
software is ready to reenter the testing phase.

6	Test Exit Criteria
Identify the conditions required to approve test results. 

To approve software for release to production it must 
comply with the following testing criteria:
The software cannot have any Severity Level 1 errors.
The software cannot have any Severity Level 2 errors.
The software may be released with Severity Level 3 or 4 
errors if the work around and the cosmetic errors are 
documented for the client, and if the software has been 
determined to be non-threatening to the client if installed 
into production.  
In all cases, all Severity Level problems will attempt to 
be fixed by developers prior to release of the software to 
any client. 
The ultimate decision on whether to release software to a 
production environment will be determined by the QA 
Department Manager and the Business Analyst.  Software will 
not be deployed to production without both individuals 
signing a release form that states that the software has 
met the testing release criteria and that the software can 
be deployed.


6.1	Sample Software Release Form

Date:

The following software:  
_______________________________________________ has been 
tested by the [Company Name] Quality Assurance Department 
and meets the criteria to be deployed into production.

A complete Test Exit Report is on file with the [Company 
Name] Quality Assurance Department and may be reviewed upon 
request.


------------------------------------------------------------
----------------        --------------------------
QA Department Manager Signature				Date


------------------------------------------------------------
----------------        --------------------------
Business Analyst Signature				
	Date
7	Project Management
7.1	Test Deliverables
Identify the deliverables from the test process, including 
report logs, incident reports, and summary reports.
Prepare a high-level schedule for each testing task. 
Identify the resources required for each activity and 
proposed contingencies should these individuals need to be 
replaced.

Deliverable	Role	Responsibility	Start Date	End 
Date
				
				
				
				
				
				
Table 1 — Schedule
7.2	Testing Tasks
Identify the tasks necessary to prepare testing activities, 
including inter-related tasks.

Ref	Task	Inter-related Tasks
1. 		
2.		
3		
Table 2 — Testing Tasks

7.3	Risk Assessment
Identify the risks associated with the test plan, including 
contingency strategies. 

Risk	Low	Med.	High	Contingency
				
				
				
Table 3 — Risk Assessment
7.4	Constraints
Identify any business or technology constraints that may 
impact the plan, e.g. resources, schedules, or budgetary 
issues.

Ref	Constraint	Action
1. 		
2.		
3		
Table 4 — Constraints

7.5	Issues
Identify issues that may affect the development and 
operation of the test plan, e.g. communications, security, 
training.

Ref	Issue	Action
1. 		
2.		
3		
Table 5 — Issues

7.6	Assumptions

Identify all assumptions regarding the test plan.

Ref	Assumption	Impact
1. 		
2.		
3		
Table 6 — Assumptions


7.7	Dependencies

Identify the main dependencies regarding the plan.

Ref	Dependency	Action
1. 		
2.		
3		
Table 7 — Dependencies
8	Project Team
8.1	Roles and Responsibilities
Describe each person(s) role and responsibility during the 
test plan.

Name	Role	Responsibility	% Committed
			
			
			
Table 8 — Roles and Responsibilities
8.2	Responsibilities
Identify the user groups responsible for all aspects of 
test plan(s) activities, such as developers, testers, 
technical writers, and end-users.

8.3	Resources
Identify the resources required for performing each testing 
tasks.

8.4	Training
Describe the training requirements for users, testers, and 
other personnel. Outline the content and scheduling of 
training courses for personnel.  

9	Environmental Requirements
Describe the test environment including the physical 
characteristics, communications, levels of security, and 
software testing tools. 

9.1	 Hardware
Identify the hardware and network requirements for testing 
activities.

Ref	Hardware	Purpose
1. 		
2.		
3		
Table 9 — Hardware
9.2	Software
Identify the software requirements for testing activities.

Ref	Software	Purpose
1. 		
2.		
3		
Table 10 — Software
 
9.3	Security
Identify the security and asset protection requirements for 
testing activities.

9.4	Tools
Identify software tools, techniques, and methodologies used 
in the testing efforts. Describe the purpose of each tool. 

Ref	Tool	Purpose
1. 		
2.		
3		
Table 11 — Tools, Techniques and Methodologies

9.5	Documentation
Identify any documentation required to support testing 
activities.

Ref	Documentation	Owner
1. 		
2.		
3		
Table 12 — Documentation

 


10	Plan Approvals
Identify the plan approvers, including name, signature and 
date of approval.

10.1	Sign-Off Criteria
Identify individuals authorized to sign off the plan. 

Name	Role	Signature	Date
			
			
			
Table 13 — Sign-off Criteria
11	Appendices
Attach any addition information that supplements the test 
plan.

11.1	Glossary of Terms
List and define all terms that establish meaning within the 
context of the plan. 

Term	Meaning
	
	
	
	
	
Table 14 — Glossary of Terms
11.2	Acronyms and Abbreviations
Provide a list of acronyms and abbreviations used in this 
document and the meaning of each.

Acronym	Meaning
	
	
	
Table 15 — Acronyms and Abbreviations



12	Appendix B — Sample Test Case
The following is a sample test case template. This table 
describes the content of the fields in the test case form

 
Test Case Template
Project Name		Test Date	
Test Case Description
		Test Scenario #	
		Version / Build #	
Module Under Test		Execution Retry #	
Test Requirement #		Case #	
Created by	
Test Environment	
Setup for Test
Pre-conditions	
Tested by	
Step	Action	Expected Results	Pass / Fail
	Failure Results
1				
2				
3				
4