Test Plan Document

Test Plan (A Real Sample)

Training Project
QACLICKACADEMY.COM

23/10/2020
Prepared by: @KeepGrowing

Note: This is a sample test plan created on real time software

testing live projects by QACLICKACADEMY.

Version: 1.0
Created: 12/10/2020
Last Updated: 22/10/2020
Status: DRAFT

(The status would change to finalized post the BA, PM and dev team review and sign off)

Revision and Signoff Sheet:

Confidential
1
 Test Plan Document
Document History- To maintain a list of changes being made

Version Date Author Description of

Change
1.0 02/14/2020 ABC Draft
2.0 12/14/2020 XYZ Draft (Reviewed)

Approvers List- To track who has reviewed and signoff on the Test plan

S.No Approver Name Designation Remarks

1
2
3

Reference Documents-Clearly mark the document used as an input to create the

test plan

Version Date Author Document Name

1.0 Payment Module

Table of Contents
1. INTRODUCTION ........................................................................................................................ 4
1.1. Purpose ......................................................................................................................... 4
1.2. Project Overview .......................................................................................................... 4
1.3. Audience ....................................................................................................................... 4

Confidential
2
 Test Plan Document
2. TEST STRATEGY ........................................................................................................................ 5
2.1. Test Objectives ............................................................................................................. 5
2.2. Test Assumptions ......................................................................................................... 5
2.3. Test Principles............................................................................................................... 6
2.4. Data Approach .............................................................................................................. 6
2.5. Scope and Levels of Testing......................................................................................... 6
2.5.1. Exploratory ...................................................................................................... 6
2.5.2. Functional Test ................................................................................................ 7
TEST ACCEPTANCE CRITERIA ........................................................................... 7
TEST DELIVERABLES ........................................................................................... 7
MILESTONE LIST................................................................................................... 8
2.5.3. User Acceptance Test (UAT) ....................................................................... 8
TEST DELIVERABLES ............................................................................................ 8
2.6. Test Effort Estimate ...................................................................................................... 9
3. EXECUTION STRATEGY ............................................................................................................. 9
3.1. Entry and Exit Criteria ................................................................................................... 9
3.2. Test Cycles .................................................................................................................. 10
3.3. Validation and Defect Management ........................................................................ 10
3.4. Test Metrics ................................................................................................................ 11
3.5. Defect tracking & Reporting ....................................................................................... 12
4. TEST MANAGEMENT PROCESS .............................................................................................. 12
4.1. Test Management Tool .............................................................................................. 12
4.2. Test Design Process .................................................................................................... 13
4.3. Test Execution Process ............................................................................................... 14
4.4. Test Risks and Mitigation Factors .............................................................................. 14
4.5. Communications Plan and Team Roster ................................................................ 16
4.6. Role Expectations ....................................................................................................... 16

4.6.1. Project Management ..................................................................................... 16

4.6.2. Test Planning (Test Lead) ............................................................................ 16
4.6.3. Test Team ...................................................................................................... 17
4.6.4. Test Lead ....................................................................................................... 17
4.6.5. Development Team ....................................................................................... 17
5. TEST ENVIRONMENT .............................................................................................................. 17

1. INTRODUCTION

1.1. Purpose
This test plan describes the testing approach and overall framework that will
drive the testing of the Payment module Version 3.0 – My Info Module.com site.
The document introduces:

 Test Strategy: rules the test will be based on, including the givens of the
project (e.g.: start / end dates, objectives, assumptions); description of the
process to set up a valid test (e.g.: entry / exit criteria, creation of test
cases, specific tasks to perform, scheduling, data strategy).

Confidential
3
 Test Plan Document
 Execution Strategy: describes how the test will be performed and process
to identify and report defects, and to fix and implement fixes.

 Test Management: process to handle the logistics of the test and all the
events that come up during execution (e.g.: communications, escalation
procedures, risk and mitigation, team roster)

1.2. Project Overview

My Info Module is a powerful tool providing employees of the company with
the ability to view relevant information such as personal information and
updating personal information with an internet enabled PC without having to
involve the HR department.

The functionality of this module spans through the entire system, making
information available anywhere, anytime. All information is subject to
company’s defined security policy, where he/she can only view the
information he/she is authorized to. An ESS-User can only edit certain fields in
the ESS Module, maintaining the security and confidentiality of employee
information

1.3. Audience

 Project team members perform tasks specified in this document, and

provide input and recommendations on this document.

 Project Manager Plans for the testing activities in the overall project
schedule, reviews the document, tracks the performance of the test
according to the task herein specified, approves the document and is
accountable for the results.

 The stakeholders’ representatives and participants (individuals as

identified by the PMO Leads) may take part in the UAT test to ensure the
business is aligned with the results of the test.

 Technical Team ensures that the test plan and deliverables are in line with
the design, provides the environment for testing and follows the
procedures related to the fixes of defects.

 Business analysts will provide their inputs on functional changes.

2. TEST STRATEGY

2.1. Test Objectives

Confidential
4
 Test Plan Document
o The objective of the test is to verify that the functionality of Payment
Module works according to the specifications.

o The test will execute and verify the test scripts, identify, fix and retest all
high and medium severity defects per the entrance criteria, prioritize lower
severity defects for future fixing via CR.

The final product of the test is twofold:

 A production-ready software;
 A set of stable test scripts that can be reused for Functional and UAT test
execution.

2.2. Test Assumptions

Key Assumptions

 Production like data required and be available in the system prior to

start of Functional Testing
 In each testing phase, Cycle 3 will be initiated if the defect rate is high
in Cycle 2.

General Assumptions

 Exploratory Testing would be carried out once the build is ready for
testing
 Performance testing is not considered for this estimation.
 All the defects would come along witha snapshot JPEG format
 The Test Team will be provided with access to Test environment via VPN
connectivity
 The Test Team assumes all necessary inputs required during Test
design and execution will be supported by Development/BUSINESS
ANALYSTs appropriately.
 Test case design activities will be performed by QA Group
 Test environment and preparation activities will be owned by Dev Team
 Dev team will provide Defect fix plans based on the Defect meetings
during each cycle to plan.
 The same will be informed to Test team prior to start of Defect fix cycles
 BUSINESS ANALYST will review and sign-off all Test cases prepared by
Test Team prior to start of Test execution

Confidential
5
 Test Plan Document
 The defects will be tracked through HP ALM only. Any defect fixes
planned will be shared with Test Team prior to applying the fixes on the
Test environment
 Project Manager/BUSINESS ANALYST will review and sign-off all test
deliverables
 The project will provide test planning, test design and test execution
support
 Test team will manage the testing effort with close coordination with
Project
 PM/BUSINESS ANALYST
 Project team has the knowledge and experience necessary, or has
received adequate Training in the system, the project and the testing
processes.
 There is no environment downtime during test due to outages or defect
fixes.
 The system will be treated as a black box; if the information shows
correctly online and in the reports, it will be assumed that the database
is working properly.
 Cycle 3 will be initiated if there are more defects in Cycle 2.

Functional Testing

 During Functional testing, testing team will use preloaded data

which is available on the system at the time of execution
 The Test Team will be perform Functional testing only on
QACLICKACADEMY VERSION 3.0 – MY INFO MODULE

UAT

 UAT test execution will be performed by end users (L1, L2and L3)
and QA Group will provide their support on creating UAT script.

2.3. Test Principles

 Testing will be focused on meeting the business objectives, cost

efficiency, and quality.
 There will be common, consistent procedures for all teams supporting
testing activities.
 Testing processes will be well defined, yet flexible, with the ability to
change as needed.

Confidential
6
 Test Plan Document
 Testing activities will build upon previous stages to avoid redundancy or
duplication of effort.
 Testing environment and data will emulate a production environment as
much as possible.
 Testing will be a repeatable, quantifiable, and measurable activity.
 Testing will be divided into distinct phases, each with clearly defined
objectives and goals.
 There will be entrance and exit criteria.

2.4. Data Approach

In functional testing, QACLICKACADEMY VERSION 3.0 – MY INFO MODULE will
contain pre-loaded test data and which is used for testing activities.

2.5. Scope and Levels of Testing

2.5.1. Exploratory
PURPOSE: the purpose of this test is to make sure critical defects are
removed before the next levels of testing can start.

SCOPE: First level navigation, dealer and admin modules

TESTERS: Testing team.

METHOD: this exploratory testing is carried out in the application without

any test scripts and documentation

2.5.2. Functional Test

PURPOSE: Functional testing will be performed to check the functions of
application. The functional testing is carried out by feeding the input
and validates the output from the application.

SCOPE: The below excel sheet details about the scope of Functional
test. Note: The scope is high level due to changes in the requirement.

Confidential
7
 Test Plan Document
To keep the document easily fragmented and categorized, the scope
has been embedded as separate document. If you prefer you can
insert a table here itself. The scope is created based on the Test
scenarios that were identified in the previous article.

TESTERS: Testing Team.

METHOD: The test will be performed according to Functional scripts,

which are stored in HP ALM.

TIMING: after Exploratory test is completed

TEST ACCEPTANCE CRITERIA

1. Approved Functional Specification document, Use case documents must

be available prior to start of Test design phase.

2. Test cases approved and signed-off prior to start of Test execution

3. Development completed, unit tested with pass status and results shared
to Testing team to avoid duplicate defects

4. Test environment with application installed, configured and ready to use

state

Confidential
8
S.No.
1
2
3
4
5
()
.x
b
k
P
y
&
R
T
s
U
m
lD
ta
c
u
F
d
e
v
r
p
fA
o
-
n
ig
STest Plan Document

TEST DELIVERABLES

Deliverable Name
Test Plan
Functional Test Cases
Logging Defects in HP ALM
Daily/weekly status report
Test Closure report

MILESTONE LIST
Author
Test Lead
Test Team
Test Team
Test Team/ Test Lead
Test Lead
Reviewer
Project Manager/ Business Analyst
Business Analyst’s Sign off
Test Lead/ Programming Lead
Test Lead/ Project Manager
Project Manager

The milestone list is tentative and may change due to below reasons

a) Any issues in the System environment readiness

Confidential
9
 Test Plan Document
b) Any change in scope/addition in scope
c) Any other dependency that impacts efforts and timelines

Testing generally is not carried out in one cycle. Based on the testing scope,
we can estimate how much time it takes and establish the time lines as you
can see in the below embedded excel sheet.

2.5.3. User Acceptance Test (UAT)

PURPOSE: this test focuses on validating the business logic. It allows
the end users to complete one final review of the system prior to
deployment.

TESTERS: the UAT is performed by the end users (L1, L2 and L3).

METHOD: Since the business users are the most indicated to provide
input around business needs and how the system adapts to them, it
may happen that the users do some validation not contained in the
scripts. Test team write the UAT test cases based on the inputs from
End user (L1,L2 and L3 users) and Business Analyst’s.

TIMING: After all other levels of testing (Exploratory and Functional) are
done. Only after this test is completed the product can be released to
production.

TEST DELIVERABLES

S.No. Deliverable Name Author Reviewer

1. UAT Test Cases Test Team Business Analyst’s Sign off

2.6. Test Effort Estimate

This document lists out all the activities that have to be performed by
the QA team and estimates how many man-hours each activity is going
to take.

Note: this estimate is for the TCOE team only Testing Schedule

Confidential
10
 Test Plan Document

4. EXECUTION STRATEGY

4.1. Entry and Exit Criteria

 The entry criteria refer to the desirable conditions in order to start test
execution; only the migration of the code and fixes need to be assessed at
the end of each cycle.
 The exit criteria are the desirable conditions that need to be met in order
proceed with the implementation.
 Entry and exit criteria are flexible benchmarks. If they are not met, the test
team will assess the risk, identify mitigation actions and provide a
recommendation. All this is input to the project manager for a final “go-no
go” decision.
 Entry criteria to start the execution phase of the test: the activities listed in
the Test Planning section of the schedule are 100% completed.
 Entry criteria to start each cycle: the activities listed in the Test Execution
section of the schedule are 100% completed at each cycle.

Exit Criteria Test Technical Notes

Team Team
100% Test Scripts executed
95% pass rate of Test Scripts

Confidential
11
 Test Plan Document
No open Critical and High severity defects
95% of Medium severity defects have been
closed
All remaining defects are either cancelled or
documented as Change Requests for a future
release
All expected and actual results are captured
and documented with the test script
All test metrics collected based on reports from
HP ALM
All defects logged in HP ALM
Test Closure Memo completed and signed off
Test environment cleanup completed and a new
back up of the environment

4.2. Test Cycles

 There will be two cycles for functional testing. Each cycle will execute all
the scripts.
 The objective of the first cycle is to identify any blocking, critical defects, and
most of the high defects. It is expected to use some work-around in order to
get to all the scripts.
 The objective of the second cycle is to identify remaining high and medium
defects, remove the work-around from the first cycle, correct gaps in the
scripts and obtain performance results.
 UAT test will consist of one cycle.

4.3. Validation and Defect Management

 It is expected that the testers execute all the scripts in each of the cycles
described above.However it is recognized that the testers could also do
additional testing if they identify a possible gap in the scripts. This is
especially relevant in the second cycle, when the Business analyst’s join
the TCOE in the execution of the test, since the BUSINESS ANALYSTs have a
deeper knowledge of the business processes. If a gap is identified, the
scripts and traceability matrix will be updated and then a defect logged
against the scripts.
 The defects will be tracked through HP ALM only. The technical team will
gather information on a daily basis from HP ALM, and request additional
details from the Defect Coordinator. The technical team will work on fixes.
 It is the responsibility of the tester to open the defects, link them to the
corresponding script, assign an initial severity and status, retest and close
the defect; it is the responsibility of the Defect Manager to review the
severity of the defects and facilitate with the technical team the fix

Confidential
12
 Test Plan Document
 and its implementation, communicate with testers when the test can
continue or should be halt, request the tester to retest, and modify status
as the defect progresses through the cycle; it is the responsibility of the
technical team to review HP ALM on a daily basis, ask for details if
necessary, fix the defect, communicate to the Defect Manager the fix is
done, implement the solution per the Defect Manager request.
 Defects found during the Testing will be categorized according to the bug-
reporting tool “Mercury HP ALM” and the categories are:

Severity Impact
1 (Critical)  This bug is critical enough to crash the system, cause
file corruption, or cause potential data loss
 It causes an abnormal return to the operating system
(crash or a system failure message appears).
 It causes the application to hang and requires re-booting
the system.
2 (High) It causes a lack of vital program functionality with workarou
3 (Medium)  This Bug will degrade the quality of the System. However
there is an intelligent workaround for achieving the
desired functionality – for example through another
screen.
 This bug prevents other areas of the product from being
tested. However other areas can be independently
tested.
4 (Low) There is an insufficient or unclear error message, which has
minimum impact on product use.
5(Cosmetic) There is an insufficient or unclear error message that has no
impact on product use.

4.4. Test Metrics

Test metrics to measure the progress and level of success of the test
will be developed and shared with the project manager for approval.
The below are some of the metrics.

Confidential
13
 Test Plan Document

4.5. Defect tracking & Reporting

Following flowchart depicts Defect Tracking Process:

Confidential
14
 Test Plan Document

5. TEST MANAGEMENT PROCESS

5.1. Test Management Tool

HP Application Lifecycle Management is the tool used for Test Management. All
testing artifacts such as Test cases, test results are updated in the HP
Application Lifecycle Management (ALM) tool.
Confidential
15
 Test Plan Document
 Project specific folder structure will be created in HP ALM to manage the
status of this DFRT project.
 Each resource in the Testing team will be provided with Read/Write
access to add/modify Test cases in HP ALM.
 During the Test Design phase, all test cases are written directly into HP
ALM. Any change to the test case will be directly updated in the HP ALM.
 Each Tester will directly access their respective assigned test cases
and update the status of each executed step in HP ALM directly.
 Any defect encountered will be raised in HP ALM linking to the particular
Test case/test step.
 During Defect fix testing, defects are re-assigned back to the tester to
verify the defect fix.
 The tester verifies the defect fix and updates the status directly in HP
ALM.
 Various reports can be generated from HP ALM to provide status of Test
execution. For example, Status report of Test cases executed, Passed,
Failed, No. of open defects, Severity
 wise defects etc.

5.2 Test Design Process

 The tester will understand each requirement and prepare corresponding

test case to ensure all requirements are covered.
 Each Test case will be mapped to Use cases to Requirements as part of
Traceability matrix.
 Each of the Test cases will undergo review by the BUSINESS ANALYST and
the review defects are captured and shared to the Test team. The testers
will rework on the review defects and finally obtain approval and sign-off.
 During the preparation phase, tester will use the prototype, use case and
functional specification to write step by step test cases.

Confidential
16
 Test Plan Document
 Testers will maintain a clarification Tracker sheet and same will be shared
periodically with the Requirements team and accordingly the test case will
be updated. The clarifications may sometimes lead to Change Requests or
not in scope or detailing implicit requirements.
 Sign-off for the test cases would be communicates through mail by
Business Analyst’s.
 Any subsequent changes to the test case if any will be directly updated in
HP ALM.

5.3 Test Design Process

 Once all Test cases are approved and the test environment is ready for
testing, tester will start a exploratory test of the application to ensure the
application is stable for testing.
 Each Tester is assigned Test cases directly in HP ALM.
 Testers to ensure necessary access to the testing environment, HP ALM
for updating test status and raise defects. If any issues, will be escalated
to the Test Lead and in turn to the Project Manager as escalation.
 If any showstopper during exploratory testing will be escalated to the
respective development SPOCs for fixes.
 Each tester performs step by step execution and updates the executions
status. The tester enters Pass or Fail Status for each of the step directly in
HP ALM.
 Tester will prepare a Run chart with day-wise execution details
 If any failures, defect will be raised as per severity guidelines in HP ALM
tool detailing steps to simulate along with screenshots if appropriate.
 Daily Test execution status as well as Defect status will be reported to all
stakeholders.
 Testing team will participate in defect triage meetings in order to ensure all
test cases are executed with either pass/fail category.
 If there are any defects that are not part of steps but could be outside the
test steps,

Confidential
17
 Test Plan Document
 such defects need to be captured in HP ALM and map it against the test
case level or at
 the specific step that issue was encountered after confirming with Test
Lead.
 This process is repeated until all test cases are executed fully with
Pass/Fail status.
 During the subsequent cycle, any defects fixed applied will be tested and
results will be updated in HP ALM during the cycle.

As per Process, final sign-off or project completion process will be followed.

5.4 Test Risks and Mitigation Factors

Risk Prob. Impact Mitigation Plan

SCHEDULE High High The testing team can control the
Testing schedule is preparation tasks (in advance) and the
tight. If the start of the early communication
testing is delayed due with involved parties.
to design tasks, the
test cannot be Some buffer has been added to
extended beyond the the schedule for contingencies,
UAT scheduled start although not as much as best
date. practices advise.
RESOURCES Medium High Holidays and vacation have been
Not enough estimated and built into the
resources, resources schedule; deviations from the
on boarding too late estimation could derive in delays in
(process takes around the testing.
15 days.
DEFECTS Medium High Defect management plan is in place
Defects are found at a to ensure prompt communication
late stage of the cycle and fixing of issues.
or at a late cycle;
defects discovered
late are most likely be
due to unclear
specifications and
are time consuming to
resolve.
SCOPE Medium Medium Scope is well defined but the
Scope completely changes are in the functionality are
defined not yet finalized or keep on
Changing.
Natural disasters Low Medium Teams and responsibilities have
been spread to two different
Geographic areas. In a catastrophic
event in one of the areas, there will
resources in the other areas needed
to continue (although at a slower
pace) the testing activities.
Non-availability of Medium High Due to non availability of the
Confidential
18
 Test Plan Document
Independent Test environment, the schedule gets
environment and impacted and will lead to delayed
accessibility start of Test execution.
Delayed Testing Due Medium High During testing, there is a good
To new Issues chance that some “new” defects
may be identified and may become
an issue that will take time to
resolve.

There are defects that can be raised

during testing because of unclear
document specification. These
defects can yield to an issue that will
need time to be resolved.
If these issues become showstoppers,
it will greatly impact on the overall
project schedule.

If new defects are discovered, the

defect management and issue
management procedures are in
place to immediately provide a
Resolution.

5.5 Communications Plan and Team Roster

5.6 Role Expectations

The following list defines in general terms the expectations related to
the roles directly involved in the management, planning or execution of
the test for the project.

Confidential
19
 Test Plan Document

5.2.1. Project Management

 Project Manager: reviews the content of the Test Plan, Test Strategy and Test
Estimates signs off on it.

5.2.2. Test Planning (Test Lead)

 Ensure entrance criteria are used as input before start the execution.
 Develop test plan and the guidelines to create test conditions, test cases,
expected results and execution scripts.
 Provide guidelines on how to manage defects.
 Attend status meetings in person or via the conference call line.
 Communicate to the test team any changes that need to be made to the test
deliverables or application and when they will be completed.
 Provide on premise or telecommute support.
 Provide functional (Business Analysts) and technical team to test team
personnel (if needed).

5.2.3. Test Team

 Develop test conditions, test cases, expected results, and execution scripts.
Perform execution and validation.
 Identify, document and prioritize defects according to the guidance provided
by the Test lead.
Confidential
20
 Test Plan Document
 Re-test after software modifications have been made according to the
schedule.
 Prepare testing metrics and provide regular status.

5.2.4. Test Lead

 Acknowledge the completion of a section within a cycle.

 Give the OK to start next level of testing.
 Facilitate defect communications between testing team and technical /
development team.

5.2.5. Development Team

 Review testing deliverables (test plan, cases, scripts, expected results, etc.)
and provide timely feedback.
 Assist in the validation of results (if requested).
 Support the development and testing processes being used to support the
project.
 Certify correct components have been delivered to the test environment at
the points specified in the testing schedule.
 Keep project team and leadership informed of potential software delivery date
slips based on the current schedule.
 Define processes/tools to facilitate the initial and ongoing migration of
components.
 Conduct first line investigation into execution discrepancies and assist test
executors in creation of accurate defects.
 Implement fixes to defects according to schedule.

6 TEST ENVIRONMENT
QACLICKACADEMY– MODULE’s servers will be hosted at X company’s site and will be hosted on
two servers: One to host the actual website and (language) code, and the other to host the
(database name) database.
A windows environment with Internet Explorer 8, 9 and 10, and with Firefox 27.0, as well as
Google Chrome32.0 and later should be available to each tester.

7 APPROVALS

Confidential
21
Test Plan Document

Confidential
22