HSBC Technology and Services

Testing Process
Q&PG
Date: 6th January 2010
Version: 8.3

About HSBC Technology and Services

HSBC Technology and Service (HTS) is a pivotal part of the Group and seamlessly integrate
technology platforms and operations with an aim to re-define customer experience and drive
down unit cost of production. Its solutions connect people, devices and networks across the
globe and combine domain expertise, process skills and technology to deliver unparalleled
business value, thereby enabling HSBC to stay ahead of competition by addressing market
changes quickly and developing profitable customer relationships.

Restricted for company use only. © Copyright HTS 2010. | HSBC INTERNAL DOCUMENT
Testing Process | Version: 8.3

Revision History
Version Date Author Reasons for Change Section(s) Affected
0.1 24 Dec 02 SEPG New process introduced as All
standard process for coding in
IDC
0.2 08 Apr 03 SEPG Process reviewed and All
reworked
0.3 15 May 03 SEPG Changed the measurements 3.2.5
section and elaborated on the
analysis of defects
0.4 01 Aug 03 SEPG Revised the process to make 3.1.1
Independent Unit Testing a
mandatory step in testing
0.5 12 Aug 03 SEPG Changed the reference of 3.3
Testing Review Checklist to
Review Checklist
0.6 17 Sep 03 SEPG Changed the reference to 3.2.4
SDP_QP_CMP to Project Plan
to reflect the change in the
name of the document
0.7 24 Sep 03 SEPG Changed workplace references 3.1.1
to reflect change in the name of
documents like Peer review
report
0.8 08 Oct 03 SEPG Removed the reference of 6.0
PPCR from Workplace
Reference since it is not being
referred to in the process
1.0 12 Jan 04 SEPG Completely revised the testing All
process to simplify it and make
it more relevant to projects that
are being executed in IDC
1.1 27 Feb 04 SEPG Baselined the process, All
replaced IDC with GLT and
changed the formatting of the
document
1.2 13 Sep 04 SEPG Process revised, included All
section on UAT
2.0 16 Sep 04 SEPG Baselined after PCCB approval All
2.1 06 Jun 05 SEPG Process revised to provide 4.0
clarity in the manner in which
testing will be carried out and
results recorded.
3.0 08 Jun 05 SEPG Baselined after PCCB approval All
3.1 07 Oct 05 SEPG Revised the process to include 3.1, 4.0
Quality Center as a defect
management tool
4.0 19 Oct 05 SEPG Baselined after PCCB approval All

HSBC Technology and Services | HSBC INTERNAL DOCUMENT Page 2 of 16

Testing Process | Version: 8.3

4.1 27 Dec 05 SEPG Updated to include User 4.4

Acceptance Testing in sec 4.4
5.0 28 Dec 05 SEPG Baselined after GLTi PCCB All
approval
5.1 18 Aug 06 SEPG Updated copyright information Title page – copyright
information
5.2 22 Aug 06 SEPG Updated to reflect the phase 3.1, 4.2.1, 4.2.2, 4.2.3,
out of Defect Tracking 4.4
Application (DTA) as per PER
367
6.0 30 Aug 07 SEPG Updated to include new 4.1, 4.2, 4.3.2, 4.5
sections on Test Environment,
Entry and Exit Criteria and
removed the reference of
functional testing. Sections
updated – Work place
reference and Measurements,
Added section for Test
completion
6.1 19 Dec 07 SEPG Test completion section has 4.5
been updated for Test Activity
Completion Certificate and
review of Test Activity
Completion Certificate
7.0 05 Mar 08 SEPG Approved by PCCB All
8.0 19 Mar 09 Q&PG Separated the Unit testing part All
from this process
Inclusion of the comments from
Product Services team &
Testing characterization
analysis.
New template as per the
Optimus Simplification initiative.
8.1 02 Apr 09 Q&PG Production data masking Section 2.4.1, 2.4.10
related information has been
updated, Unit test case related
addition information has been
updated, Test plan/ Test
Strategy has been renamed to
Test plan_Test Strategy
8.2 18 May 09 Q&PG - Changed Link Testing to All
Integration Testing
- Updated measurement name
from Test Efficiency to Defect
Removal Efficiency
- Section on Applicability
updated to include Testing
projects
8.3 6 Jan 10 Q&PG Format updated as per the 2.5
current process template
Test case related process exit

HSBC Technology and Services | HSBC INTERNAL DOCUMENT Page 3 of 16

Testing Process | Version: 8.3

criteria have been added.

HSBC Technology and Services | HSBC INTERNAL DOCUMENT Page 4 of 16

Testing Process | Version: 8.3

Table of Contents

1.0 Testing Process Policy............................................................................................... 6

1.1 Purpose ................................................................................................................................ 6

1.2 Applicability .......................................................................................................................... 6
1.3 Definitions and Acronyms.................................................................................................. 6
2.0 Process ........................................................................................................................ 7

2.1 Process Workflow ............................................................................................................... 7

2.2 Process Responsibility Matrix ........................................................................................... 8
2.3 Process Entry Criteria ........................................................................................................ 8
2.4 Process Steps ..................................................................................................................... 8
2.4.1 Test Planning....................................................................................................................... 8
2.4.2 Integration Test Planning................................................................................................... 9
2.4.3 System Test Planning ........................................................................................................ 9
2.4.4 User Acceptance Test Planning ....................................................................................... 9
2.4.5 Test Environment.............................................................................................................. 10
2.4.6 Test Execution and Reporting......................................................................................... 10
2.4.7 Test Completion ................................................................................................................ 10
2.4.8 Defect Fixing...................................................................................................................... 11
2.4.9 Defect Tracking and Analysis ......................................................................................... 12
2.4.10 Review Process ............................................................................................................ 12
2.4.11 Configuration Management Process ......................................................................... 13
2.4.12 Change Management Process................................................................................... 13
2.4.13 Release Management Process .................................................................................. 13
2.4.14 Defect Prevention Process.......................................................................................... 14
2.5 Process Exit Criteria ......................................................................................................... 14
3.0 Process Performance Measurement ....................................................................... 15

4.0 Process References.................................................................................................. 16

HSBC Technology and Services | HSBC INTERNAL DOCUMENT Page 5 of 16

Testing Process | Version: 8.3

1.0 Testing Process Policy

This process will assist in ensuring that the product, as provided (or as it will be provided), will
fulfil its intended use in the intended environment. Validation will be done in various phases of
testing and shall involve Prototyping, Signoff, Acceptance Testing, inspection, demonstration,
or simulation as appropriate. The end users and other relevant stakeholders would be
involved in the validation activities.

1.1 Purpose

The Testing process ensures that for a project:

 To ensure that the software developed/tested at the GLT meets user requirements in
terms of functionality, performance, usability, security etc.
 To detect, report and eliminate maximum number of defects before delivering the
software to the client.

1.2 Applicability
This process is applicable for all Product Engineering projects where GLT is involved in the
Testing Phase and for Testing Projects.

For details on the Testing Process Applicability please refer to Process Applicability matrix.

For details on the Testing Process tailoring, refer Process Tailoring Guidelines.

1.3 Definitions and Acronyms

Acronym / Abbreviation Description

PM Project Manager
APM Associate Project Manager
QC Quality Center
UAT User Acceptance Testing

HSBC Technology and Services | HSBC INTERNAL DOCUMENT Page 6 of 16

Testing Process | Version: 8.3

2.0 Process
The following sections describe the testing process in detail.

2.1 Process Workflow

The workflow for Testing Process is,

Testing Process

Customer Project Management Team Testing Team Process documents

Start
Requirements
Specification, Use
Case, EDR, Query log,
Requirement Customer supplied
document documents, Change
Tracking Sheet

Analyze technical/non-technical Resource estimation, estimation

requirements of the customer review, preparation of test plan
and all planning documents Estimation document,
review Test Plan, Test
Strategy document

Yes
Review
comments?

No Test Case template/

Preparation of Test Scenarios QC, Peer Review
and Test Cases, Mapping of records (Peer Review
Report template/QC),
Test Cases with the
Mapping document
Requirements, Test Scenarios (Traceability Matrix/
and Test Cases review QC)

Execute Test Cases Test Activity Summary

Report

Log the defects in QC/Client

recommended tool

Test Activity
Prepare and review Test Completion Certificate,
Activity Completion Test Activity
Certificate completion review
records

Analyse testing defects and Yes

prepare action plan after Review
No
considering rejected/peer review comments?
defects

Deliver the work products to the Defect prevention

client report and action plan

Get the Sign-off from the

customer based on
acceptance criteria
Sign-off received from
defined
Client, Phase/Project
Closure Report, Test
End Activity Completion
Certificate, Test
Summary Report

HSBC Technology and Services | HSBC INTERNAL DOCUMENT Page 7 of 16

Testing Process | Version: 8.3

2.2 Process Responsibility Matrix

The roles and responsibilities as applicable to the Testing process are,

Role Responsibilities
Project  Overall Testing activity planning, monitoring, tracking, controlling and status
Management reporting
Team
 Determine the testing strategies that will be used in the project
Testing Team  Ensure that the test plan_test strategy and test cases are designed,
documented and are reviewed to ensure sufficient coverage and
completeness
 Ensure that the software is tested as per the plan and test reports are
documented
 Ensure that all the defects found in testing are logged in the Quality
Center/Client Recommended Tool, analysed and tracked to closure
 Take corrective actions based on the defect analysis results
Q&PG  Collect defect data from projects at the closure of phase/project and
analyse it for inclusion in organizational software baselines

2.3 Process Entry Criteria

The entry criteria to be fulfilled before initiating the Testing process are:

1. Availability of signed-off and baselined requirement documents.

2. Developed/Unit tested Software product/component from Client/development team.
3. If GLT is involved in earlier phases all review findings and audit findings of all
previous phases are closed.
4. Availability of necessary tools required to satisfy the process. (E.g. QC, Load runner.)

2.4 Process Steps

2.4.1 Test Planning

Input Functional / Requirement Specification ,Test cases template, Developed

Component
Output Test plan_Test Strategy.

 Based on the project scope, different testing strategies will be taken into consideration and
testing activities will be planned accordingly. If the project scope involves other testing phases,
other than Unit testing, separate Test plan_Test Strategy should be created.
 Test cases should be reviewed and review comments to be maintained where test case
preparation is in the scope. Traceability should be maintained.
 Production data received from customer for conducting testing should be changed / masked in
such a fashion that the sensitive customer info. Such as actual name, address, Social Security
Number, transaction details is not shared with the testing team. if not done should be raised as
issue/risk.

HSBC Technology and Services | HSBC INTERNAL DOCUMENT Page 8 of 16

Testing Process | Version: 8.3

2.4.2 Integration Test Planning

Input Requirement Specifications, Design Document, Unit Tested Product

Output Test plan_Test Strategy, Test Cases in QC

 Depending on the project scope, PM/APM shall decide if Integration testing will be done in the
project.
 Integration testing shall be done after unit testing to ensure that the panels/screens when
linked together give the expected output.
 Integration Test Cases shall be prepared as per the Test Case template.
 Integration Test cases shall cover all possible navigation and interfaces between the
panels/screens that are related by some functionality.

2.4.3 System Test Planning

Input Requirement Specification, Design Document, Integration Tested

Product/Customer Provided Product
Output Test plan_Test Strategy Document, Test cases in QC

 For all projects that involve System Testing, Test plan_Test Strategy document will be
prepared, which will include scope, responsibilities, schedule, deliverables, test coverage,
entry and exit criteria for testing and test cases. The Test plan_Test Strategy will include
details for following types of system testing as applicable to the project:
 Functionality Testing
 Recovery Testing
 Security Testing
 Stress Testing
 Performance Testing
 The Test Cases documents for different types of system testing applicable to the project will be
prepared. Test Cases are updated in QC

2.4.4 User Acceptance Test Planning

Input Requirement Specification, System Tested Product

Output Test plan_Test Strategy, Test Cases in QC

 For projects that involve User Acceptance Testing carried out at the GLT, a UAT plan will be
prepared, including the scope, objectives, responsibilities, schedules, deliverables, test
coverage, entry and exit criteria for testing, test cases etc. UAT plan shall be documented in
Test Plan_Test Strategy Document.
 The following kinds of testing may be considered:
 Functionality Testing
 Security Testing
 Performance/Stress Testing
 Recovery Testing
 For projects where the UAT is to be carried out at a remote location by client/business users,
the GLT will provide requisite support based on the scope of the engagement.

HSBC Technology and Services | HSBC INTERNAL DOCUMENT Page 9 of 16

Testing Process | Version: 8.3

2.4.5 Test Environment

 Overview of the test environment required for the various stages of testing will be documented
in the Test Plan_Test Strategy

2.4.6 Test Execution and Reporting

Input Test plan_Test Strategy, Test cases, Test data

Output Test Cases updated and Defects logged in QC/Customer Recommended
Tool, Traceability Matrix in QC or Optimus Template

 Integration Test Execution and Reporting:

Integration testing will be done after unit testing and before system testing. Integration testing
will be done using the Integration Test Cases and record of Integration test execution will be
documented as Pass/Fail Status. Defects will be entered in the Quality Center/client
recommended tool.
 System Test Execution and Reporting:
System Test Execution will start as per the Entry Criteria identified for the particular level of
testing in the Test plan_Test Strategy. The record of system test execution will be documented
as Pass/Fail Status. Where applicable, reports for the iterations of test execution and for
different types of testing such as recovery, security, stress, performance testing will be
maintained by the project team. Defects will be entered in the Quality Center/client
recommended tool.
 User Acceptance Test Execution and Reporting:
UAT will be carried out as per the scope of the project and client requirements. Defects found
will be collected, consolidated and actioned upon as appropriate.

2.4.7 Test Completion

Input Complete Tested and defect free code ready for the delivery to
customer
Output Signed off mail from customer

 Project team shall prepare the Test completion report using Test Activity Completion Certificate
and Test summary report as mentioned in the Test plan_Test Strategy.
 Test Activity Completion Certificate to be reviewed internally before sending it to the customer for
the Sign off.
 Sign off taken from the customer will be considered as test completion.

HSBC Technology and Services | HSBC INTERNAL DOCUMENT Page 10 of 16

Testing Process | Version: 8.3

2.4.8 Defect Fixing

Input Test plan_Test Strategy & Test Cases

Output Test Case results and Defects logging in QC

Following steps will be followed while fixing the defects found in different types and cycles of
system testing:
 The Pass/Fail status will be recorded.
 The tester will log all the failed test cases as defects in the Quality Center/client recommended
tool. While logging, detailed information like action for simulation, defect summary and defect
description will be recorded.
 The TL or defect analyzer in the project will analyze these defects and assign them to team
members. The analyzer will also identify the root cause, severity and phase of origin of the
defect.
 The analyzer may reject the defect if it cannot be simulated or is not a valid defect.
 In case of valid defects, the team members will identify the changes required in different
software component in order to fix the defect.
 All the components that need to change will be checked-out from the project’s repository.
 Changes will be made in the components and these changes will be reviewed.
 The analyzer verifies that the defect is fixed and releases it to the initiator. The initiator executes
the test case again and on successful execution, closes the defect. In case the defect is not
fixed, the defect is re-assigned to the fixer.
 The changed components will be checked-in to the repository.
 The defect status will be changed to ‘Released’.
 The updated components will be released.

HSBC Technology and Services | HSBC INTERNAL DOCUMENT Page 11 of 16

Testing Process | Version: 8.3

2.4.9 Defect Tracking and Analysis

Input QC/Customer specified Tool

Output PSR, Defect Prevention Report

 Any defects found during testing will be tracked to closure using the Quality Center/client
recommended tool. These should include the defects found during Integration Testing, System
Testing, User Acceptance Testing, Volume Testing, Performance Testing, Stress Testing and
any other defects reported by customer or found internally after the delivery of the software.
 Root Causes and Origin Phase for the defects recorded will be identified and root cause
analysis of the defects will be done at the end of each phase/tranche/iteration/project.
 The defect data will be reported on a monthly basis in the Project Status Report of the project.
 Q&PG will use data for various projects from the Quality Center/the client recommended tool for
forming/revising the organizational baselines for Defect Density and Defect Leakage. Defect
Removal Efficiency is also an important indicator of test effectiveness.
 Process Consultants will help the PM/APM to decide on taking any corrective action on the
project’s defect data.

2.4.10 Review Process

Technical Specifications, Test plan_Test Strategy, Test Cases, Process

Input
Review checklist
Output Test Case Review defects in QC or Peer Review Report

 Review the artefacts ( Technical Specification, Test plan_Test Strategy, Test Cases) to ensure
 The Test Cases meets the requirements.
 Identification of Testing related constraints and risks associated with it.
 Verify the traceability of the Test cases with requirement
 that Testing guidelines and best practices are followed wherever applicable.
 that the functional and technical requirements are satisfied.
 Testing Process Review Checklist shall be referred for conducting the Testing review.
 Record all findings in QC or Review Report as internal review defects with defect classification,
responsibilities, target closure date etc as applicable.
 If required provide additional information on the defects.
 Conduct verification of findings closure and mark the findings as closed in QC or Review
Report.
 Post release, record all defects raised by customer as external review defects.

HSBC Technology and Services | HSBC INTERNAL DOCUMENT Page 12 of 16

Testing Process | Version: 8.3

2.4.11 Configuration Management Process

Configuration Management Process, Project plan ( for project specific

processes and CIs), Configuration Management checklist, Statement of
Input
Intent Document, Requirement Specification, Test plan_Test Strategy,
Test Cases

Output Baselined documents

 All Configurable items (Requirement specs, Peer Review Reports, Test plan_Test Strategys,
Test cases) shall be passed on to the Software Configuration Manager (SCM) after closure of all
review defects.
 Baseline the document by creating or incrementing the version of the document and ensure that
the revision history of the artefact is updated.
 Check-in the artefact in the configuration management tool.

2.4.12 Change Management Process

Test plan_Test Strategy Document, Change request and affected

Input
documents

Output Updated documents, Baseline audit report document.

 Test plan_Test Strategy and Test Cases will be maintained as configuration items. Any changes
to these documents will be controlled as per the change and version management process
defined for the project.
 If any new test cases are identified while executing the tests, the Test Cases document will be
revised to add or modify the test cases.
 While making changes in requirements, design and code, the respective test cases will also be
revised. Traceability Matrix document will be updated to ensure correct mapping between
revised requirements, design, code and test cases..
 Conduct periodic baseline audit and maintain record of the baseline audit report in DOMDOC.

2.4.13 Release Management Process

Release audit checklist, Release Note template, All artefacts to be

Input
released as part of release package

Output Release Note, All artefacts to be released as part of release package.

 Ensure that all review defects are closed.

 Ensure that all the artefacts are properly versioned and base lined.
 Prepare the release note
 Get the release note reviewed and revise based on inputs if any.

HSBC Technology and Services | HSBC INTERNAL DOCUMENT Page 13 of 16

Testing Process | Version: 8.3

2.4.14 Defect Prevention Process

Input Project Plan, PSR, Defect prevention report template

Output Defect prevention report document.

 Analysis number of defects against the quality objectives.

 Conduct Causal Analysis for the common error causes and defects classification.
 Create action plan and track the same for closure.

2.5 Process Exit Criteria

Following exit criteria should be met for the closure of Testing phase,

1. All the test cases have been executed as per the Test Plan
2. All testing related defects are closed.
3. Necessary sign-offs are obtained and sign-off mails are archived.

HSBC Technology and Services | HSBC INTERNAL DOCUMENT Page 14 of 16

Testing Process | Version: 8.3

3.0 Process Performance Measurement

Sr. Measurement Purpose Measured Review

No. Through / Frequency
Reported
Through
1 Effort Variance To validate effort estimates & take Clarity / Periodic
necessary actions to control PSR review during
variance for the Testing activity at the Testing
different stages of Testing schedule.
schedule.
End of
Testing
phase.
2 Schedule Variance To validate effort estimates & take Clarity / Periodic
necessary actions to control PSR review during
variance for the Testing activity at the Testing
different stages of Testing schedule.
schedule.
End of
Testing
phase.
3 Test case Execution To ascertain the test execution QC or Periodic
Ratio effectiveness. Review review during
Report / the Testing
PSR phase.

End of
Testing
phase
4 Defect Detection To ascertain that adequate time is QC, PSR Periodic
Ratio spent in Testing activity to ensure review during
all defects are identified during the Testing
testing. schedule.

End of
Testing
Phase
5 Defect Rejection To validate the rejection rate and QC, PSR Periodic
Ratio to analyze the root causes for review during
rejection for checking any gap in the Testing
testing activity schedule.

6 Defect Removal To validate the efficiency of Quality End of

Efficiency
7 Defect Leakage Ratio
testing, prior sending deliverable Centre Testing
to customer so that Post Release (QC) Phase
Defects are minimized.
To analyze the number of defects QC, PSR
slipped out during System testing. End of
To analyse the reasons / root Testing
cause for common defects and phase
take necessary actions to prevent
those through Defect Prevention
activity. To analyse the defects
leakage to post release and take
necessary actions to prevent
those.

HSBC Technology and Services | HSBC INTERNAL DOCUMENT Page 15 of 16

Testing Process | Version: 8.3

4.0 Process References

S. No. Reference Name
1. Testing Guidelines
2. Test Case template
3. Test Plan_Test Strategy Template
4. Testing Traceability Matrix Template
5. Test Activity Summary Report (format)
6. Test Activity Completion Certificate form (format)
7. Defect Prevention Testing Template

HSBC Technology and Services | HSBC INTERNAL DOCUMENT Page 16 of 16