<<<Logo>>> <<<Project Name >>>

(Company Logo)

Test Plan

Revised: 11/28/2024 Page 1 of 21

<<<Project Name>>>
Test Plan

Created By
 Test Plan Document

Document Change History:

Date Version Changes Made

___________________________________________________________________________________________________________________
<<project name>>_Test_Plan Confidential Information. 2 of 23
 Test Plan Document

TABLE OF CONTENTS

1 Introduction_______________________________________________________________________5
1.1 Purpose_____________________________________________________________________________5
1.2 Objectives___________________________________________________________________________5
1.3 Project Overview_____________________________________________________________________5
1.4 Test Phases_________________________________________________________________________5
1.5 Assumptions_________________________________________________________________________5
1.6 Risk Factors_________________________________________________________________________5
1.7 Documentation Matrix________________________________________________________________5
2 Scope____________________________________________________________________________7
2.1 In Scope_____________________________________________________________________________7
2.2 Out of Scope_________________________________________________________________________7
2.3 System______________________________________________________________________________7
3 Testing Strategy___________________________________________________________________8
3.1 Test Approach_______________________________________________________________________8
3.2 Test Cases___________________________________________________________________________9
3.3 Test Scripts and Scenarios_____________________________________________________________9
3.4 Testing Process Overview_____________________________________________________________10
3.5 Unit Testing________________________________________________________________________11
3.6 Build and Regression Testing__________________________________________________________11
3.7 System Testing______________________________________________________________________11
3.8 Enterprise Integration Testing_________________________________________________________12
3.9 User Acceptance Testing (UAT)________________________________________________________13
4 Test Environment_________________________________________________________________14
4.1 Testing Environment_________________________________________________________________14
4.2 Test Management____________________________________________________________________14
4.3 Testing Tools_______________________________________________________________________14
5 Defect Management_______________________________________________________________15
5.1 Defect Tracking States_______________________________________________________________15
5.2 Defect Type Category________________________________________________________________15
5.3 Defect Type_________________________________________________________________________16

___________________________________________________________________________________________________________________
<<project name>>_Test_Plan Confidential Information. 3 of 23
 Test Plan Document

5.4 Defect Process Diagram______________________________________________________________17

5.5 Severity Levels______________________________________________________________________18
5.6 Defect Tracking & Turn Around_______________________________________________________18
6 Staffing – Roles and Responsibilities__________________________________________________19
7 Testing Schedules_________________________________________________________________20
7.1 Build/Regression & System Testing by QA_______________________________________________20
7.2 Enterprise Integration & User Acceptance Testing________________________________________20
8 Approvals________________________________________________________________________21

___________________________________________________________________________________________________________________
<<project name>>_Test_Plan Confidential Information. 4 of 23
 Test Plan Document

1 Introduction
1.1 Purpose
<<This section contains the purpose of this document, like what it defines>>
(For example: The purpose of this document is to define the test approach, guidelines and details to ensure
that the solution developed for <Project Name> meets all defined user, business, and technical
requirements and functions as expected.)

1.2 Objectives
<<This section provides the objective>>
(For example: The number of test phases, test framework, functionalities to verify according to the FS
documents, Test Scripts generation and Test execution etc.)

1.3 Project Overview

<<This section provides the project overview>>
(For example: Base product used for the implementation, how this project meets the companies growing
business demands etc.)

1.4 Test Phases

Sub
Test Type Owner Goal
Type

<<This section provides the different test phases>>

(For example: Unit, System, Integration, UAT etc.)

1.5 Assumptions
<<This section provides the different assumptions made at the project signoff>>
(For example: Like environments to be used at different test phases, inputs for the test scripts generation,
do’s and don’ts, tools to be utilized etc.)

1.6 Risk Factors

<<This section provides the different risks involved and to be expecting in the project execution>>
(For example: Resources availability\leaves\knowledge, unexpected holidays, Requirements not stable etc.)

1.7 Documentation Matrix

<<This section provides the reference of different documents required for the QA. Please provide only that
documentation which will be created for the project. >>

___________________________________________________________________________________________________________________
<<project name>>_Test_Plan Confidential Information. 5 of 23
 Test Plan Document

The Quality Assurance planning and design activities require the completion and availability of specific
documentation.

All QA related documentation located on -> specify the Path where the documents are placed
All project related documentation located on -> specify the Path where the documents are placed

Document Created or Received or Author or Required by Notes

(and version) Available Reviewed Resource (time frame)
(Yes/No) (Yes/No)

Requirements Bus. Partner, Prior to Master

Specification/ Bus. Analyst Test Plan
Business
Requirements
(BRD) Doc.

Output Samples Bus. Partner, Prior to Test

(Receipts ,Franking Bus. Analyst Cases
slip, Deposit slip) Development

Technical Developers Prior to Test

(Programming) Cases
Specifications Development
(SRS) Doc.

Data Model/Flow Developers Prior to Test Included in FSD

Cases
Development

Error Message Developers Prior to Test Included in FSD

Listing Cases
Development

Master Test Plan Sr. QA Analyst Prior to Test

Cases
Development

Unit/Integration Developers Turnover

Test Plan and
Results

List of Known Developers Turnover

Anomalies

Test Cases QA Team Prior to Test Company specific

Execution testing tool

___________________________________________________________________________________________________________________
<<project name>>_Test_Plan Confidential Information. 6 of 23
 Test Plan Document

2 Scope
2.1 In Scope
<<This section provides the activities\items that are in scope for this project>>
(For example: The modules, Third party or external integrations, functionalities\features to be tested etc.)

2.2 Out of Scope

<<This section provides the activities\items that are out of scope for this project>>
(For example: The modules, Third party or external integrations, functionalities\features to be tested etc.)

2.3 System

System Architecture Diagram

<<This section provides the typical project architecture diagram which is considered to be as base for
setting up the test environment >>

System Definition
<<This section lists and provides the description of typical systems involved in the project architecture
diagram which needs to be considered for setting up the test environment >>

# System Description
1 Cybersource This system is used for credit card authorization.

2 Vertex This system is used for calculating tax. Veretex

provides and API which are called in the website code
for calculating tax.

___________________________________________________________________________________________________________________
<<project name>>_Test_Plan Confidential Information. 7 of 23
 Test Plan Document

3 Testing Strategy
3.1 Test Approach
<<This section provides the information of the STLC followed at SkillNet for this project and the different
phases in it>>
(For example: Please check the below information as an example.)

The System Testing in SkillNet Solutions consists of a five-phase Software Test Life Cycle:

# Phase Description Deliverables

1 Test Planning Master Test Plan

2 Test Design and Test Cases

Development
All Test Cases will be developed from the completed
FSD and conversations with the Business &
Development teams.
Quality Center\Test Plan

3 Test Execution and Validation Test Case results, Test Coverage Metric
Quality Center\Test Lab

4 Test Evaluation QA Completion Report

Quality Center\Test Lab\Actual Results - Pass/Failed.

5 Defect Tracking and Analysis Defects logged in the Quality Center

Quality Center\Defect

___________________________________________________________________________________________________________________
<<project name>>_Test_Plan Confidential Information. 8 of 23
 Test Plan Document

Test Approach diagram

Prepare / Review Test

Approach and Schedule

Create
Test Cases/Test Scripts

Run System Tests

Weekly Progress
Reports

Report Defects

Carry Out Code

Changes

System Test Sign Off

3.2 Test Cases

A test case is used for manual testing. It lists the requirements and functionality for each area and the methods that
will be used to exercise a module or multiple modules of code. The test case includes fields for input, expected
output, and actual output. Test cases will be captured for unit and system testing.
SkillNet is responsible for identifying and creating all test cases from approved Functional Specification document.
All test cases will be entered into HP Quality Center.

3.3 Test Scripts and Scenarios

The purpose of the test script/scenario is to verify that all designed functionality is present in the system, works
properly and the business process flow is supported by the system. A test script is a combination of test cases
which automated,. The scenario runs from start to finish. A test script contains fields for input actions, input steps,
expected output, and actual output. Test scripts are more detailed than test cases and run through a predefined
path. Test scripts work well with time-consuming tests such as regression testing. Each test script/scenario will
cover a full end-to-end business scenario as defined in the business rules document, screen shots, and functionality
matrices. They will also include expected output details to validate back-end systems where necessary. Test scripts
and scenarios will be used for integration and user acceptance testing. Test scripts and scenarios will be entered
into Quality Center. Where applicable, test scenarios will be grouped into scripts to facilitate testing.

___________________________________________________________________________________________________________________
<<project name>>_Test_Plan Confidential Information. 9 of 23
 Test Plan Document

3.4 Testing Process Overview

<<This section provides the testing process defines how software moves from development through the
various defined test phases before going to production as shown in the below business example>>

Fig: Test Process Diagram (<<<change this according to the project>>>)

___________________________________________________________________________________________________________________
<<project name>>_Test_Plan Confidential Information. 10 of 23
 Test Plan Document

3.5 Unit Testing

<<This section defines the unit testing process\approach for this project. Please add the description of the
process to be carried out>>

Unit Testing is a procedure used to validate that individual units of source code are working properly. Unit testing
helps to eliminate uncertainty in the units themselves and can be used in a bottom-up testing style approach. By
testing the parts of a program first and then testing the sum of its parts, integration testing becomes much easier.
Unit Testing of Interfaces will include manual creation of input, sending it to simulated or actual destination test
server and receiving the output. Unit Test Cases will be entered in TestDirector and will be executed manually
during construction/development phase by the developers for each corresponding application.

Unit Test Entrance Criteria

<<Add the list of entrance criteria>>

Unit Test Exit Criteria

<<Add the list of exit criteria>>

3.6 Build and Regression Testing

<<This section defines the Build and Regression testing process\approach for this project. Please add the
description of the process to be carried out>>
(Below example shows sample text. Change this as per the project)

Build and Regression Testing occurs after each code drop to verify the integrity of the drop by executing a very
basic set of test scripts.
Regression testing occurs whenever a change is made to the system (usually immediately before launch and after
launch as bugs are fixed, or as enhancements are added) to ensure that the change has been successfully
installed and that:
o No new problems are introduced
o The operational performance is not degraded
o The effects of the changes are transparent to other areas of the system and other systems that interface
with the system.
Regression testing can be either a full end-to-end pass through the code base and all functionality, or a selected
set of test scripts can be executed in the target area.

Build & Regression Test Entrance Criteria

<<Add the list of entrance criteria>>

Build & Regression Test Exit Criteria

<<Add the list of exit criteria>>

3.7 System Testing

<<This section defines the System testing process\approach for this project. >>
(Below example shows sample text. Please change this as per the project)

System Testing is a complete element that can be viewed as a stand-alone black box that either already exists in
the customer environment (SAN, CMA), is being created for eCommerce solution (Web Store, CMP) or is being
added to the customer environment (PkMS). It tests each system element as stand-alone black box by providing
inputs and examining the outputs.

___________________________________________________________________________________________________________________
<<project name>>_Test_Plan Confidential Information. 11 of 23
 Test Plan Document

System testing of backend or supporting systems will be carried out by the respective teams. The customer
eCommerce Testing team will write and execute test cases to test functionality for website, Kiosk and Scanner,
Contact Center, Content Management Portal, and Reports. As part of the testing, messages will be sent to
backend and supporting systems (e.g. SAN, CMA, Fulfillment etc.). There will be a return message from some
systems which can be validated against expected output to determine success/failure of the supporting system,
but there is no return message from certain systems, such as SAN. The testing of whether the message was
received correctly and processed correctly in such systems will be tested and validated by the individual
developers/testing teams of those systems.

System Test Entrance Criteria

<<Add the list of entrance criteria>>

System Test Exit Criteria

<<Add the list of exit criteria>>

3.8 Enterprise Integration Testing

<<This section defines the Enterprise Integration testing process\approach for this project. Please add the
description of the process to be carried out>>

(Below example shows the various roles involved in the EIT. Please change this as per the project)
Participants
The following roles will be needed in the Integration Test process: /
Role Description of Roles Deliverables
Developer The developer will support the application architect in • Fixes to any
execution of the integration tests. He/she will also be problems found
responsible for fixing any problems with developed in integration test
applications that are found during integration test. • Create test data, as
necessary
Application The application architect will be the primary tester for • Test plan
Architect integration test. He/she will be responsible for •Verified test
planning the test, verifying correct setup of the test environment setup
environment, executing the tests, and documenting the • Test results
results. • Updated architecture
documentation
External For each side of an external interface a primary • External interface
Interface contact should be identified to coordinate testing test plan.
Contact efforts and resolve any issues
Business Point person for questions about correct business • Updated business
Analyst functionality as well as data integrity issues. design as
necessary
Data Architect Point person for questions about the data model. Also • Updated data model
responsible for DBA support during the testing effort. if necessary
System Responsible for setting up hardware and configuring • Fully functioning test
Administrator test environment. Also, responsible for on-going environment
support during the testing effort.
System Responsible for testing the solution with respect • Integration test
Administrator to each area of the business. result
validation

Integration Test Entrance Criteria

<<Add the list of entrance criteria>>

___________________________________________________________________________________________________________________
<<project name>>_Test_Plan Confidential Information. 12 of 23
 Test Plan Document

Integration Test Exit Criteria

<<Add the list of exit criteria>>

3.9 User Acceptance Testing (UAT)

<<This section defines the User Acceptance testing process\approach for this project. >>

(Below example shows the various roles involved in the UAT. Please change this as per the project)

Stakeholders and their proxies test the completed solution to ensure it meets their expectations. This may include
a sample set of actual customers using the new public screens. This is the final stage in the testing process before
the system is accepted for operational use.

The same defect tracking and regression testing procedures defined in the system test plan section will be used
for User Acceptance Test.

Participants
The following roles will be needed in the user Acceptance Testing process:
Role Name Description of Roles Deliverables
Developer The developer will support the application • Fixes to any
architect in execution of the integration tests. problems found
He/she will also be responsible for fixing any in integration test
problems with developed applications that are • Create test data, as
found during integration test. necessary
Application The application architect will be the primary tester • Test plan
Architect for integration test. He/she will be responsible for • Verified test
planning the test, verifying correct setup of the environment
test environment, executing the tests, and setup
documenting • Test results
the results. • Updated
architecture
documentation
External For each side of an external interface a primary • External interface
Interface contact should be identified to coordinate testing test plan.
Contact efforts and resolve any issues
Business Point person for questions about correct business • Updated business
Analyst functionality as well as data integrity issues. design as
necessary
Data Architect Point person for questions about the data model. • Updated data
Also responsible for DBA support during the model if
testing effort. necessary
System Responsible for setting up hardware and • Fully functioning
Administrator configuring test environment. Also, responsible test
for on-going support during the testing effort. environment
System Responsible for testing the solution with • User Acceptance
Administrator respect to each area of the business. Testing test results
Business Stakeholders, or their designees,
will execute User Acceptance Test Scripts in
the QA environment.

UAT Entrance Criteria

___________________________________________________________________________________________________________________
<<project name>>_Test_Plan Confidential Information. 13 of 23
 Test Plan Document

<<Add the list of entrance criteria>>

UAT Exit Criteria

<<Add the list of exit criteria>>

___________________________________________________________________________________________________________________
<<project name>>_Test_Plan Confidential Information. 14 of 23
 Test Plan Document

4 Test Environment
<<This section defines the testing environment for the whole project. Please add the description for all the
below components or the environments needed>>

4.1 Testing Environment

Hardware Components

Software components

Databases/Files

UserIDs/Security Access

Interfaces

4.2 Test Management

<<This section provides the information of the test management to be carried through out the project cycle
which explains the various test tools used at various phases>>

4.3 Testing Tools

<<This section provides the information of the test tools which will be used in the process of testing. It
should only discuss those tools which are going to be used for the project >>

The following table depicts how the different types of testing will be executed

Type of Testing Method of Execution/Tool

Unit Testing Manual/Quality Center
Build & Regression Testing Manual/Quality Center
System Testing Manual/Quality Center
Integration Testing Manual/Quality Center
User Acceptance testing Manual/Quality Center
Test Management Quality Center
Defect Tracking Quality Center

___________________________________________________________________________________________________________________
<<project name>>_Test_Plan Confidential Information. 15 of 23
 Test Plan Document

5 Defect Management
<<This section provides the information of the defect management used/followed through out the testing life
cycle at different phases for reporting/tracking the defects>>

(Below are the examples that shows defect tracking states, category, types, severity levels, process
diagram etc. by taking Quality Center as example. Please change this as per the project)

5.1 Defect Tracking States

Defect State Description

New This is the initial state of a defect
5.2 Defect
Open Type Category
The test Coordinator will assign the defect to a specific person to
work
Type
Assigned The tester coordinator will assign the defect to respective developer
codes
In Progress When the individual Developer assigned to the defect is working
are
toward resolution, the defect is moved to the working state.
Retest The developer fixes the defect and assigns it back to the tester for
retest.
Closed Once the defect has been verified in regression test, it is moved to a
Closed state.
assigned to each Problem Report as they are opened and should be noted in Quality Center. The type code
is used for root cause analysis and in verifying exit criteria. Sample type codes are shown in the table
below:

Type Code Description

Environment This defect is the result of OAS/WebSphere errors, access problems,
and other errors relating to the computing environment.
Design Change This type of defect is the result of misunderstanding of requirements
resulting in modifications to the module design.
Code Defects This type of defect is a result of the code not meeting the
requirements or typing errors in the code.
Data This type of defect is a result of invalid data populated or migrated
into the tables.
Enhancement This type of defect is from a minor change in the requirements or a
new item is being implemented or misinformation is received from a
vendor, user, etc.
External Interface This type of defect is an issue with a third party system.

___________________________________________________________________________________________________________________
<<project name>>_Test_Plan Confidential Information. 16 of 23
 Test Plan Document

5.3 Defect Type

The following defect types have been set in Quality Center:

Defect Type Description

Working As Designed If a noted change request is how the system was designed , it
should be marked as ‘As
Designed’
Duplicate A change request that is entered into the system more than
once, multiple instances should be marked ‘Is Duplicate’

All Defects\issues will be logged into Quality Center tool under Defect tab.

___________________________________________________________________________________________________________________
<<project name>>_Test_Plan Confidential Information. 17 of 23
 Test Plan Document

5.4 Defect Process Diagram

Project (add the project name and update the diagram as per the project) Defect Tracking Process will be
adapted to this project.

Defect Flow Diagram

All Defects will be logged in the quality Center and communicated to the programming team lead by Test
Co-coordinator\Test lead as soon as they are discovered. Programming team should communicate through
Quality Center notes during Defect life cycle.

___________________________________________________________________________________________________________________
<<project name>>_Test_Plan Confidential Information. 18 of 23
 Test Plan Document

5.5 Severity Levels

Levels Severity Description

1 Showstopper Defect blocks development/testing for a specific function; also
indicates that the application would not be able to support deploying
to QA or Production. This defect should have the highest priority and
may affect testing timelines if not addressed quickly.
2 Critical Defect inhibits testing of a specific function; work around may exist
but major functionality can not be tested and will cause additional
test cycles. This also includes system crashes, loss of data,
corruption of data, and memory leaks and indicates that the
application would not be able to support deploying to QA or
Production.
3 Major Defect found introduces major loss of functionality and needs to be
resolved before deployment to QA or Production.
4 Minor Defect found introduces minor loss of functionality or other problem
where easy work around is present. Defect may not be resolved
before deploying to production, but should be reviewed by business
before go live.
5 Trivial Defect found is a cosmetic problem like misspelled words or
misaligned text

5.6 Defect Tracking & Turn Around

Priority Description Turnaround time(days)

1 - Urgent Installation of the Application failure and Loss of/bad Immediate
data in the database
2 - Very High Failure of critical functionality with no reasonable 1
workaround
3 - High Problem with critical functionality with a reasonable 2
workaround
4 - Medium Problem with minor functionality as defined in with a 5
reasonable
workaround
5 - Low Cosmetic error Not Applicable

QA Daily Status Reporting

<<This section provides the information of the templates used for the QA status reporting daily\weekly,
whom to report from client side and as well as from Skillnet side, any client specific reporting templates
etc.>>

QA Completion Package
<<This section provides the QA Completion Package that will be delivered and consist of the following
components. The purpose of the completion package is to assemble a summary of the testing, QA test
plans, test results; all reported issues and their status and metrics into one deliverable package. The
package will be turned over to the Project Leader at the end of QA testing. This policy will ensure that the
QA process was completed correctly and the application, which was tested and evaluated, meets or
exceeds the expectations of the business community>>

___________________________________________________________________________________________________________________
<<project name>>_Test_Plan Confidential Information. 19 of 23
 Test Plan Document

 QA Summary Report
 QA test plans
 Test Case Results
 All reported Defects and their status.

___________________________________________________________________________________________________________________
<<project name>>_Test_Plan Confidential Information. 20 of 23
 Test Plan Document

6 Staffing – Roles and Responsibilities

<<This section provides staff details and roles involved in the entire project life cycle>>

(Below example shows the typical staffing plan of the various roles. Please change this as per the project)

The table below identifies the recommended and actual staffing and their main responsibilities.
Staffing Resources

Position and Identified Minimum Specific Responsibilities/Comments

Resources Resources
Recommended
(Number of
resources allocated
full-time)

Project Manager Day to Day Project Tracking,

Project Issues Tracking,
Change Management,
Client Communication

Project Lead Gather and analyze requirements

Create Functional Specifications
Provide guidance for System Testing & UAT
Provide guidance to Developers

QA Lead Primary contact and interface for testing.

Provide overall direction for test planning,
Generate test model, evaluate effectiveness of test effort.
Prepare Master Test Plan
Prepare Test cases
Review and approve test cases
Execute tets cases, investigate results, log defects, and
assist in bug analysis.

Test Team Develop Test cases,

Execute application test cases, investigate results
Log defects and assist in bug analysis.

___________________________________________________________________________________________________________________
<<project name>>_Test_Plan Confidential Information. 21 of 23
 Test Plan Document

7 Testing Schedules
<<This section provides the testing schedules for the entire project of various test phases>>

(Below example shows the typical plan of the various test schedules. Please change this as per the project)

7.1 Build/Regression & System Testing by QA

Project Testing Phase Application Req# Functions Build Test Build Test No. Days
Phases Start Date End Date
System System Testing ORPOS 12/01/2008 01/23/2009 8 Weeks
testing (First) (Base)
ORPOS 12/01/2008 01/23/2009 8 Weeks
ORPOS 12/01/2008 01/23/2009 8 Weeks
ORPOS 12/01/2008 01/23/2009 8 Weeks

System ORPOS 02/09/2009 02/13/2009 1 Week

Testing(Final)
ORPOS 02/09/2009 02/13/2009 1 Week
ORPOS 02/09/2009 02/13/2009 1 Week

Integrati EIT ORPOS 02/9/2009 02/13/2009 1 week

on
testing
ORPOS 02/9/2009 02/13/2009 1 week
ORPOS 02/9/2009 02/13/2009 1 week
ORPOS 02/9/2009 02/13/2009 1 week

UAT UAT (Alpha) ORPOS 02/16/2009 02/20/2009 1 week

ORPOS 02/23/2009 03/06/2009 2 weeks
ORPOS 02/23/2009 03/06/2009 2 weeks
ORPOS 02/23/2009 03/06/2009 2 weeks

UAT (Beta) ORPOS 03/16/2009 03/20/2009 1 week

ORPOS 03/16/2009 03/20/2009 1 week
ORPOS 03/16/2009 03/20/2009 1 week

7.2 Enterprise Integration & User Acceptance Testing

<<This section provides the teams responsible for the EIT\UAT testing phases both from client side and
Skillnet side>>

___________________________________________________________________________________________________________________
<<project name>>_Test_Plan Confidential Information. 22 of 23
 Test Plan Document

8 Approvals
<<This section provides the approvals required for this document Test plan to be approved and get
signoff>>

Signature:

Signature:

Signature:

Signature:

___________________________________________________________________________________________________________________
<<project name>>_Test_Plan Confidential Information. 23 of 23