[name of project]

Test Plan

Purpose: [Insert purpose of doc here]

Revision History

Date	Version	Author	Description

Table of Contents

1. Overview	4

1.1. Purpose	4

1.2. Scope	4

2. Testing Summary	5

2.1. Scope of Testing	5

3. Analysis of Scope and Test Focus Areas	6

3.1. Release Content	6

3.2. Regression Testing	6

3.3. Platform Testing	6

4. Progression Test Objectives	7

5. Progression Test Objectives	8

6. Other Testing	9

6.1. Security	9

6.2. Stress & Volume Testing (S&V)	9

6.3. Connectivity Testing (CT)	9

6.4. Disaster Recovery/Back Up	9

6.5. Unit Testing	9

6.6. Integration Testing	9

7. Test Strategy	10

7.1. Test level responsibility	10

7.2. Test Type & Approach	10

7.3. Build strategy	10

7.4. Test Execution Schedule	10

7.5. Facility, data, and resource provision plan	11

7.6. Testing Tools	11

7.7. Testing Handover Procedure	12

7.8. Testing Metrics	12

8. Test Environment Plan	13

8.1. Test Environment Man	13

8.2. Test Environment Details	13

8.3. Establishing Environment	13

8.4. Environment Control	14

8.5. Environment Roles and Responsibilities	14

9. Assumptions and Dependencies	15

9.1. Assumptions	15

9.2. Dependencies	15

10. Entry and Exit Criteria	16

11. Administrative Plan	17

11.1. Approvals	17

11.2. Test Milestones and Schedule	17

11.3. Training	17

11.4. Defect Management	17

12. Definitions	18

13. References	19

14. Points of Contact	20

Overview

Purpose

Detail the purpose of this document. For example:

The purpose of this document is to define:

The test scope, focus areas and objectives

The test responsibilities

The test strategy for the levels and types of test for this release

The entry and exit criteria

The basis of the test estimates

Any risks, issues, assumptions and test dependencies

The test schedule and major milestones

The test deliverables

Scope

Detail the scope of this document. For example:

This document details the testing that will be performed by the project team for the <project name> project. It defines the overall testing requirements and provides an integrated view of the project test activities. Its purpose is to document:

What will be tested;

How testing will be performed;

What resources are needed, and when

Testing Summary

Scope of Testing

In scope

Detail what is in scope from a testing perspective for the project team. For example this may only include system integration testing and/or user acceptance testing

Out of scope

Detail what is out of scope from a testing perspective for the project team. Note: if usability testing is being performed by the users, or integration testing by the vendor, state this.

Analysis of Scope and Test Focus Areas

Release Content

Detail the content of the project release or refer to the relevant analysis documentation.

Regression Testing

Identify whether regression testing needs to be performed for any applications and detail the testing required. Regression testing is verification of system functionality that was previously working, or is not considered to have changed

Platform Testing

Detail what platform will be used for testing. For example:

for machine testing, specify the type of paper or adhesive to be used

for software testing, specify the operating system, hardware and software

Progression Test Objectives

This section details the progression test objectives that will be covered by the project team. Please note that this is at a high level. For large projects, a suite of test cases would be created which would reference directly back to this master.

This could be documented in bullet form or in a table similar to the one below, to assist with Requirements Traceability

Ref	Function	Test Objective	Evaluation Criteria	X-Ref	P
Function to be tested
Test reference	Name of the function or sub-function being tested	The objective the test is trying to demonstrate	The criteria that will be evaluated to demonstrate the test is successful	Any cross references. For example, a functional requirement, a design document etc	The priority of the test
Repet for each function
Ref	Function name	Objective	Evaluation criteria	x-Ref	P
Ref	Function name	Objective	Evaluation criteria	x-Ref	P

Progression Test Objectives

This section details the regression test objectives that will be covered by the project team. Please note that this is at a high level. For large projects, a suite of test cases would be created which would reference directly back to this master.

This could be documented in bullet form or in a table similar to the one below, to assist with Requirements Traceability

Ref	Function	Test Objective	Evaluation Criteria	X-Ref	P
Regression testing
Test reference	Name of the function or sub-function being regression tested	The objective the test is trying to demonstrate	The criteria that will be evaluated to demonstrate the test is successful	Any cross references. For example previous regression suite or requirement document	The priority of the test
Ref	Function name	Objective	Evaluation criteria	x-Ref	P
Ref	Function name	Objective	Evaluation criteria	x-Ref	P

Other Testing

Security

Detail what security testing will be performed and who will perform it.

Stress & Volume Testing (S&V)

Detail stress and volume testing to be performed for the project, how it will be performed, who will perform it and expected outcomes. (this is also referred to as Load Testing)

Connectivity Testing (CT)

Detail connectivity testing to be performed for the project, how it will be performed, who will perform it and expected outcomes.

Disaster Recovery/Back Up

Detail DR and Back Up testing to be performed for the project, how it will be performed, who will perform it and expected outcomes.

Unit Testing

Detail what unit testing will be performed – note Unit Testing is verification of individual modules or “units” of code

Integration Testing

Detail what integration testing will be performed

Test Strategy

Test level responsibility

Detail the testing levels expected to be applied and who has primary (P) and secondary (S) responsibility for performing this testing (example below).

Test Level	External Party	Proj Team	Business
Unit Testing	P
Integration Testing	P
Security Testing	P	S
Connectivity Testing	P
User Acceptance Testing	S	P
Production Verification Testing	S	P

Test Type & Approach

Detail the types of testing covered by the project team and their standard objectives (example below)

Test Type	Objectives
Progression Requirements	The objectives are to verify that the application: Meets the defined requirements; Performs and functions accurately; Correctly handles error conditions; Interfaces function correctly; Data load is successful. Functional testing will occur in an iterative and controlled manner, ensuring the solution matches the defined requirements.
Regression testing

Build strategy

Detail the build strategy if any (e.g. if it will be implemented in one install or broken into functional requirements).

Test Execution Schedule

Provide a test schedule for the project team in written format (e.g. using MS Word, MS Project or MS Excel) Detail each type of testing, the function and the priority.

Facility, data, and resource provision plan

Test environment

Detail the test environment required and availability dates. For large complex systems/releases, a separate test environment document should be produced that includes buy-in from each system owner.

Access to other applications

Detail any systems that are required to be accessed for the testing phase.

Testing Requirements

Detail the requirements for testing to commence.

For example;

Each person involved in testing will need the following access:

A web browser with access to the intranet

Access to the XYZ database, and relevant database SQL tool;

Access to Business Objects;

Access to Microsoft Excel to raise defects;

Data Requirements

Define data setup requirements to enable testing to start.

Resources & Skills

Define the types of resources required during the testing window. For example:

A resource with SQL skills;

A resource with .NET skills to resolve any defects;

A resource with internet technologies understanding.

Testing Tools

Detail the tools to be used for testing.

For example:

The following tools will be used for testing:

Process	Tool
Test case creation	Microsoft Word
Test case tracking	Microsoft Excel
Test case execution	Manual
Test case management	Microsoft Excel
Defect management	Microsoft Excel

Testing Handover Procedure

Detail any handover procedures to be implemented for handover from one level or team to another. For example, this may include a formal procedure to accept a system from Unit to System testing.

Testing Metrics

Detail the metrics to capture, the reasons for capture, and how you will capture them. For example, capture the number of defects raised, against a each particular module of the application. These might be captured in a defect tracking tool and they might provide input into the stability of that particular module and the re-work required for testing. This could then provide feedback to the developers, design documents and requirement documents to understand root cause, and potentially feed back lessons learned.

Test Environment Plan

Test Environment Man

Develop a Test Environment diagram.

Test Environment Details

Testers

Define the number of testers who will be involved in testing and their:

System access requirements

Hardware requirements

Hardware and Firmware

Define the hardware requirements for the test environment. This includes the name, asset numbers, communications equipment, the purpose and period of use. Identify how the hardware will be provided, who by and when.

Software

Define the software requirements of the test environment. This includes the software to be tested and any tools that will be used to assist in testing. This should include the software name, versions and item (eg operating system, database etc.). Identify who will supply them, when and how.

Interfaces

Define the interfaces to external applications. Identify who will establish the interface, when and how – refer to Interface Agreement if required.

Other Materials

Define any other requirements for the test environment. This might include manuals, software licensing, media, etc. Identify how they will be provided, who by and when.

Establishing Environment

Define the plan for establishing the testing environment, and responsibilities. This should include acquisition of each element, setup, installation and testing the environment.

Task	Requirements	Responsibility	Start Date	End Date

Environment Control

Define any control measures that will be placed on the environment. This might include:

Software release control,

Environment access

Environment monitoring and support

Environment Roles and Responsibilities

Define the roles and responsibilities of persons who will be responsible for, or interface with the environment

Role	Staff Member	Responsibilities
Release Manager	Bill Smith	Responsible for overall establishment, coordination and support of the test environment
Test Manager	Mary Jones	Responsible for advising release manager of environment requirements for planning, establishment and ongoing
Project Manager	Cathy Simons	Escalation point for environment issues.

Assumptions and Dependencies

Assumptions

Detail any assumptions made for testing.

For example, business analyst and development team members will be available to provide support, training and defect resolution to the test team members as required

Dependencies

Detail testing dependencies

For example, access to the system in the test environment, will be configured by the system administrator for all test team members identified prior to the commencement of testing

Entry and Exit Criteria

Detail the entry and exit criteria that are used to determine when a phase of testing (or level of testing) is able to commence and when testing is considered to be completed.

Administrative Plan

Approvals

Detail the responsibilities for testing signoff. For example, the following persons are responsible for the critical aspects of testing:

Task	Responsible Person	Escalation/ Approver
Systems Integration Signoff
User Acceptance Testing Signoff
Production Verification Testing Signoff

Test Milestones and Schedule

Detailed below are the high-level testing milestones.

Milestone	Planned End Date	Actual End Date	Resource

Training

The following training requirements have been identified to ensure testing can commence:

Training Requirement	Staff	Date

Defect Management

Detail how defects will be managed for this project. Detail what defect management tool will be used. Reference any defect process if required.

Definitions

The following acronyms and terms have been used through out this document

Term/Acronym	Definition

References

The following documents have been used to assist in creation of this document.

#	Document name	Version	Comments

Points of Contact

The following people can be contacted in reference to this document

Primary Contact
Name
Title/Organisation
Phone
Email
Secondary Contact
Name
Title/Organisation
Phone
Email