Controlled copy

<Enter Project Name>

Test Plan
1.0

Reviewed /
Document Prepared By Approved By
Approved By

Name

Role

Signature

Date
 Controlled copy

Table of Contents
1.0 Overview 3
1.1 Purpose 3
1.2 System Description 3
1.3 Test Requirements 3
1.3.1 Testing Requirements 3
1.3.2 Types of Testing 3
1.3.3 Rounds of Testing 3
1.3.4 Testing Tools 4
1.4 Testing Scope 4
1.5 Items NOT TO BE tested 4
2.0 Test Planning 4
2.1 Schedule 4
2.2 Test Environment 4
2.3 Test Data 4
2.4 Test Cases 5
3.0 Resources Planning 5
3.1.1 Hardware 5
3.1.2 Software 5
3.1.3 Personnel 5
3.1.4 Resource matrix 5
4.0 Test Report 6
5.0 Assumptions, Dependencies and Constraints 6
6.0 Glossary & References 7
6.1 Glossary 7
6.2 Reference 8
7.0 Change Log 8
 Controlled copy

1.0 Overview

1.1 Purpose
The purpose of the Test plan is to plan the approach for any type of testing to be executed
for the software. The types of testing that will be performed for this application are listed
here.

The scope of this test plan includes the following:

1) Test Requirements (if not defined upfront in the project)

2) Plan resources (human, software, hardware)

3) Schedule for Testing

4) Plan for environment, Test Data

5) Any other pre-requisites

1.2 System Description

1.3 Test Requirements
1.3.1 Testing Requirements
The following Testing requirements will be in scope:

1.3.2 Types of Testing

The following Testing types will be in scope:

1.3.3 Rounds of Testing

As tests are executed and defects are identified, sufficient time and effort must be
built into the plan to handle the resolution and retesting of these defects. Additionally,
some of the early critical defects will block further test execution from occurring. A
multi-cycle strategy ensures these factors are accounted for during test planning.
Where multiple test cycles are warranted, the overall test phase will be considered as
the combination of each of the test cycles, rather than having each cycle stand on its
own. When a new environment is constructed or has experienced considerable
change, an optional “Cycle 0” or “smoke test” may be executed to prove out the test
environment, using a small subset of scripts.
Cycle 1 – Discovery: Execute the test cycle, finding as many defects as possible
and ensuring that these are logged and assigned to the fix team. It is not essential
that the entire cycle be completed if major defects are discovered.
Cycle 2 – Discovery and Quality: Re-execute the entire test cycle, emphasizing
testing the defects fixed from cycle 1 (if required) and determining if changes applied
to the system have caused new defects.

Project: <Project Name> Test Plan Ver: 1.0

 Controlled copy

1.3.4 Testing Tools

Tools Purpose

JIRA Defect Management

WorkFront Project Management

Microsoft Excel Test Case, Test Script management

SharePoint Document Repository, Requirements management

1.4 Testing Scope

Scope Inclusions:
<Scope list for the project to be inserted here>

Scope Exclusions:
<Out of scope list for the project to be inserted here>

1.5 Items NOT TO BE tested

<List of items “NOT TO BE Tested” to be inserted here. This could be some specific
reports that don’t need testing, while others do. This could also be areas of the application
that are not going to be available to the tester, etc.>

2.0 Test Planning

2.1 Schedule
<Project Schedule to be inserted here. Please Link to Workfront Project for real-
time access to schedule. This should include complete project timeline along with QA
Testing, UAT Testing, etc.>

2.2 Test Environment

<Information on Test Environment to be inserted here. Preferably, a specific
environment for QA would be available that is stable for testing. A stable environment is
required during Test Execution; therefore, it may be an environment other than QA, but you
have defined a period of time without access to anyone other than QA. Be aware of any
risks associated with shared environments, databases, etc.>

2.3 Test Data

<Information on Test Data to be inserted here. Determine what type of test data will
be available for testing. Copy of Production, Scrubbed version of Production, Copy of ACC
environment, etc. For some projects, the data is critical. Understanding what is available for

Project: <Project Name> Test Plan Ver: 1.0

 Controlled copy

testing will impact test results.>

2.4 Test Cases

Test cases will be developed that describe the test to be conducted. Test cases are the
specifications of test inputs, execution conditions, and expected results required to test a
particular aspect of the system. A template for writing test cases will be provided.

3.0 Resources Planning

This sub-section estimates all the resources required to implement the tasks identified
including special requirements. The information can be presented in the form of tables for
the different phases of Testing. Identifying resources while planning a project, will help
align them for project integrity.

3.1.1 Hardware

Name Quantity Required Quantity Available

3.1.2 Software

Name Copies Required Copies Available

Cisco VPN 5.0 1 1

3.1.3 Personnel

<Year>
Skillset Role Location
<Month 1> <Month 2> <Month 3>

Total

3.1.4 Resource matrix

Name Team Role Participation Type

Project: <Project Name> Test Plan Ver: 1.0

 Controlled copy

Project Test Test Test

Plan Plan Cases Execution

Proj
A C C I
Name

Resource
QA I A I I
Name

Resource
QA I R C A
Name

QA I R A R

QA I I R R

LEGEND

R Responsible - Person or role who does work (There can be multiple)

Accountable - Person or role accountable for the completion of the deliverable (There can only
A
be one)

Consulted - Person or role whose subject matter expertise is required in order to complete the
C
deliverable

Informed - Person or role who "need to know" the outcome, but don't need to be engaged in the
I
process

4.0 Test Report

Please see sample reports below:

 Daily Status Report

Attach Excel Regression Test

 Test Summary Report

5.0 Assumptions, Dependencies and Constraints

a. Deliverables as agreed between Gallo Project Manager and QA team will be signed-
off by Gallo within 3 business days after submission by QA team. Flexibility will be

Project: <Project Name> Test Plan Ver: 1.0

 Controlled copy

discussed and agreed upon by Gallo’s QA Manager

b. Gallo will provide requisite access to the relevant servers, applications, licensing
needs, requirement documents and all related testing artifacts to QA team

c. Gallo will provide workspace/workstation – desktop / laptop to Cognizant onsite team

at Gallo’s location

d. Based on the changes in scope and schedule Vendor <or QA Manager> and Gallo
<or IS Project Manager> will discuss on changes to the capacity required. <This
statement can change as appropriate if this is an outsourced or internally sourced QA
project.>

6.0 Glossary & References

6.1 Glossary
Test Plan is a document describing the scope, approach, resources, milestones and
schedule of intended test activities. It identifies the test criteria, the features to be tested,
test data, test environment, testing tools to be used and the test deliverables
Test Scenarios Test scenarios detail the positive and negative validation points needed
to ensure that the requirements of the projects are met. This is a deliverable produced
during test design phase.
Test Case(s) is a detailed elucidation of the test scenarios. They are a set of test
conditions (explained in steps and expected results) that will determine whether features
/ functionalities of the application are working as per the requirements of the project. This
deliverable is produced during test design phase.
Requirements Traceability Matrix (RTM) is a deliverable produced during the test
design phase. This maps the requirements to the test scenarios. The objective of this
deliverable is to ensure test coverage - that all the requirements have at least one test
scenario.
Functional testing (user interface validation) is performed with the purpose of finding
bugs in functionalities of the application under test
Web service testing is validating the web services part of the application under test
System integration testing tests the interactions between two or more systems
Regression testing involves systematic retesting for defects in existing systems after
changes or enhancements have been made
Mobile testing involves functional testing of mobile handheld devices
Role based testing involves user credential validation of security groups & roles
Test automation Test execution performed by utilizing test automation tools
Performance testing involves load/performance to measure impacts on system
Security testing is restricted to user role based access validation
Reports Testing Validation on reports generated from the application under test
Browser compatibility testing is ensuring that the application functionality is consistent
across different browsers
Data migration testing involves validation of the migrated data from one database to
another
User acceptance testing involves validation by business users post the validation of the
Vendor QA Team

Project: <Project Name> Test Plan Ver: 1.0

 Controlled copy

6.2 Reference
The below chart lists any standards or other reference material used in the creation of this
Test Plan.

Version
# Documents
Number

7.0 Change Log

Version Changes made
Number

V1.0

V1.1 <If the change details are not explicitly documented in the table below,
reference should be provided here>

Page Changed Effective Changes effected

no by date

V1.2 <If the change details are not explicitly documented in the table below,
reference should be provided here>

Page Changed Effective Changes effected

no by date

Project: <Project Name> Test Plan Ver: 1.0