Project xxxx

TEST STRATEGY

DOCUMENT NAME & LOCATION:

DOCUMENT VERSION:

DATE:
READERSHIP:

SUMMARY:

Amendment History

Version Date Comment By Approved

V0.1

Associated Documents (This document should be read in conjunction with):

Version
Title of Document Date
No/File Name

Approval

Approver Name Date

Project Manager

Page 1 of 25
 CONTENTS

1. Introduction......................................................................................................................................... 3
1.1 Context....................................................................................................................................... 3
1.2 Purpose...................................................................................................................................... 3
1.3 Scope to be Tested.................................................................................................................... 3
1.4 Out of Scope (Not Tested).......................................................................................................... 3
2. Testing Approch.................................................................................................................................. 3
2.1 Purpose...................................................................................................................................... 3
2.2 Test Objectives........................................................................................................................... 3
2.3 Traditional Testing Approach...................................................................................................... 3
2.4 Overview of Test Phases............................................................................................................ 3
2.4.1 Component (unit) Testing................................................................................................... 3
2.4.2 System Functional Testing................................................................................................. 3
2.4.3 End to End (E2E) Testing.................................................................................................. 3
2.4.4 Technical (non-functional) Testing.....................................................................................3
2.4.5 User Acceptance Testing (UAT)........................................................................................3
2.4.6 Operational Acceptance Testing (OAT).............................................................................3
2.4.7 Regression Testing............................................................................................................ 3
2.5 Proposed Test Approach............................................................................................................ 3
2.5.1 Release Schedule.............................................................................................................. 3
2.5.2 Testing Schedule............................................................................................................... 3
2.6 Risk Approach............................................................................................................................ 3
3. Test Deliverables................................................................................................................................. 3
3.1 Testing Deliverables................................................................................................................... 3
3.2 Detailed Test Plans..................................................................................................................... 3
3.3 Test Scripts................................................................................................................................. 3
3.4 Test Progress Reporting............................................................................................................. 3
4. Test Management............................................................................................................................... 3
4.1 Resource Management.............................................................................................................. 3
4.2 Assumptions and Dependencies................................................................................................ 3
5. Defect Management............................................................................................................................ 3
5.1 Defect Management Approach................................................................................................... 3
5.2 Defect Status and Process......................................................................................................... 3
5.3 Defect Severity........................................................................................................................... 3
5.4 Defect Priority............................................................................................................................. 3
5.5 Test Progress Reporting Metrics................................................................................................ 3
6. Test Tools........................................................................................................................................... 3
6.1 Introduction................................................................................................................................. 3
6.2 Overview of Testing Tool............................................................................................................ 3
6.3 Test Tool Requirement and description......................................................................................3
APPENDIX A – Example Testing Risk Log.................................................................................................. 3
APPENDIX B – Example Detailed Test Phase Description.........................................................................3
APPENDIX C – Test Plan Contents............................................................................................................ 3
APPENDIX D – Testing Roles and Responsibilities..................................................................................3

Page 2 of 25
1. INTRODUCTION

1.1 Context
Project context

1.2 Purpose

This document sets the strategy for all testing within the scope of the project

This document describes:

 the test approach
 test phases
 principles governing testing activities

The delivery of the solution and the overall business strategy are excluded from the scope of this
document.

1.3 Scope to be Tested

The following key components (sub-systems) will be tested:



 All aspects of the non-functional requirements

1.4 Out of Scope (Not Tested)

The following features and attributes will NOT be tested:





2. TESTING APPROCH

2.1 Purpose
This subsection describes the testing approach that will be adopted by the project

Page 3 of 25
2.2 Test Objectives
The test objectives are:
- To demonstrate that the solution meets all requirements
- To identify Defects (faults and failures to meet the actual requirements) with an agreed rectification
plan
- To mitigate risk and demonstrate that the release is fit for purpose and meets user expectations.

2.3 Traditional Testing Approach

The traditional approach to testing uses the "V" model, which maps the types of test to each stage of
development as per the simplified diagram below:

User Requirements User Acceptance Testing

Functional Specification End to End Testing

System Design System Functional Testing

Component Design Component Testing

Component Build

It shows that for each requirement, specification or design documentation, there is an associated testing
phase (i.e. Component design is associated with Component testing

Where possible, testing should be carried out according to the V-Model approach using the Requirements
Traceability Matrix as a key input to Test design and planning

2.4 Overview of Test Phases

List here the key phases of testing, eg:

- Component (unit) Tests

- System Functional Tests
- End to End Process (E2E) Tests
- Technical (Non-Functional) Tests

Page 4 of 25
 - User Acceptance Tests
- Operational Acceptance Tests

Each Test Phase outlined below should be described, including the following details:

- Owner
- Objective of the phase
- Test Approach; execution, environments, data, resources & location
- Scope
- Exclusions
- Entry & Exit criteria
- Sign-off procedures
- Testing tools to be used

2.4.1 Component (unit) Testing

This is the testing that is carried out within the early stages of the development lifecycle:
Describe here the key components and the Owners (eg THE CLIENT team, Vendor etc) that is responsible
for testing the component

2.4.2 System Functional Testing

System Functional Testing is the testing of the core functional areas of the system against the agreed
requirements and technical documents.

All the System Functional Tests to be carried out should be documented in the Detailed System Functional
Test Plan to be produced before testing begins.

2.4.3 End to End (E2E) Testing

Once all the functional areas have been successfully tested, the next phase of testing will be the End to End
process testing. End to End (E2E) testing covers the testing of the full end-to-end processes - as defined in
the process-model
The key difference between the End to End Testing and the System Functional Testing is that in the E2E
Testing we are primarily validating the process with the appropriate functions and not just the discrete
functions
All the E2E processes to be tested will be documented in the E2E Detailed Test Plan.

2.4.4 Technical (non-functional) Testing

Technical (non-functional) testing will primarily cover Performance, Volume and Scalability of the solution.
The testing will be based on the requirements, technical and process documents.

Non-functional requirements should have been gathered in the Requirements Traceability Matrix.
A range of test volume scenarios will be specified in the Non-Functional Testing Detailed Test Plan.

Page 5 of 25
The scenarios will be comparable with the expected operational volumes. A set of exceptional volume Tests
will also be specified to demonstrate the robustness of the solution in exceptional volume conditions.
A subset of these tests will also be executed (i.e. re-run) as part of the Operational Acceptance Testing
(OAT)

2.4.5 User Acceptance Testing (UAT)

User Acceptance Testing (UAT) is the testing that is conducted by the End User Representatives to ensure
that the delivered system meets the user defined functional requirements.
It is expected that the User Representatives will select a subset of tests from the System Functional and
E2E test scripts.
These tests will be documented in the UAT Detailed Test Plan by the Test Analysts in advance of the
execution of the UAT. During the execution of UAT, the User Representatives will also be allowed an
opportunity to carry out un-documented tests.
Once the UAT tests are successfully completed, UAT can be signed off by the business team (and including
the SPA)

2.4.6 Operational Acceptance Testing (OAT)

Operational Acceptance Testing is the is the last major test phase and is executed on the final implemented
solution to confirm that it can be supported and meet operational support requirements as agreed in the
Support Model;

Once these tests are passed, the solution can be promoted to operational status.
If there are any unresolved priority 1 or priority 2 defects, the Application Manager may reserve the right not
to accept the system into operational support.

2.4.7 Regression Testing

Regression testing becomes necessary when:
- A new release or bug fix is delivered following the resolution of an Defect;
- Enhancements to the functionality are incorporated in the system; or
- The technical environment is altered.
Regression Testing is performed by re-running a selected set of the test scripts chosen according to the
nature of the change. All test scripts will be designed to be re-run as necessary.
( please note that regression testing tends to carried out as part of the above phases and is not a separate
testing phase on its own )

2.5 Proposed Test Approach

Outline here the likely sequence of testing:

2.5.1 Release Schedule

The following table outlines the delivery schedule of different code releases:

Page 6 of 25
2.5.2 Testing Schedule

Outline below the proposed high-level schedule for testing:

( a detailed test plan should be produced early in Execute)

2.6 Risk Approach

It is often impractical to perform a full exhaustive set of tests for a solution since this would be very costly in
terms of both money and time and because the vendors should have tested their products prior to release to
THE CLIENT.
The objective is to optimise the testing resources and reduce test time without compromising the quality of
the final solution.

Therefore, all test major test activities will carry risks, and an impact and likelihood analysis should be
carried out to validate the choices being made

List all key Testing risks below:





 .

Page 7 of 25
3. TEST DELIVERABLES

3.1 Testing Deliverables

This section details the type and structure of the test documentation that needs to be produced. The
following is a list of documents that will be delivered as part of the testing activities:
- Detailed Test Plans
- Test Scripts for all test phases
- Testing Progress reporting
The following sub-sections provide an overview of each of the key deliverables.

3.2 Detailed Test Plans

The core of each Detailed Test Plan is based on the requirements, design documentation and other
non-functional criteria.
The Detailed Test Plan will document the test method to be adopted for the testing of the Testing
phase.

The Detailed Test Plan should cover:

 System Functional Testing
 Technical (non-functional) Testing
 End to End Process Tests
 User Acceptance Testing
 Operational Acceptance Testing

Within the Detailed Test Plan, a full description of the following should be provided:
 the test environment
 all required test scripts
 test data
 interfaces (Integration) required.

Once the Detailed Test Plans have been approved, the test scripts can be documented.

3.3 Test Scripts

A test script describes in detail how the test is conducted and what results are expected.
A single test script may cover one or more requirements. However, typically a single requirement is
broken down into sub-requirements/test conditions. This allows the Testers to show exactly how

Page 8 of 25
requirements have been covered by the test scripts and enables the Testing team to track issues
related to specific test scripts.

Each test script will detail the following:

- Test Name – A unique reference number followed by the test name identifying the test
- Requirement cross reference - A reference to the requirement(s) and source documentation
- Revision History - with original, review and update details related to specific changes to the
test
- Prerequisites – reference to any scripts that need to be run before individual scripts can be
executed.
- Test Description - A summary description of the purpose of the test
- Test Data – The test data to be used
- Test Steps – The instructions for running the test, e.g. the actions that need to be performed
in order to exercise the piece of functionality being tested
- Expected Results – A definition of the test results that expect to be observed if the test is
successful. Enough information should be supplied to enable the tester to determine
unambiguously whether or not the test has been passed
- Actual Results – The Actual results that were observed and a reference to any test evidence.
As a rule the tester will store evidence of the test results where possible. This will include a
record of the build being tested, whether the test passed or failed and a list of any test
observations raised
- Pass / Fail - A record of whether the test was passed or failed.

Page 9 of 25
3.4 Test Progress Reporting
Progress reports will be produced at regular intervals (typically weekly).The report will show:
- Test Phase
- System Under Test
- Test environment
- No of total tests
- No of tests completed
- No of tests passed
- No of tests failed
Where appropriate, a detailed report highlighting all outstanding risks and potential business and/or
operational impacts will also be produced.

4. TEST MANAGEMENT

4.1 Resource Management

The following is a list of all the key testing roles and core responsibilities that are required during the
testing phase:
- Test Manager – responsible for all project testing
- End to End) Test Manager – responsible for the E2E Test activities
- Test Phase Team Lead – responsible for input into the test phases
- Test Analyst – responsible for documenting and executing the tests
- Technical Test Analyst – responsible for technical tests

Depending on the scale and nature of the system (i.e. provided by an external vendor), it may be
possible to combine all the roles so that combination of a Test Manager and Test Analysts should be
able to fulfil all the testing responsibilities.

List the key resources here:

Role Organisation / team Name

Page 10 of 25
4.2 Assumptions and Dependencies
Assumptions
List here any assumptions e.g.
- The vendors are responsible for fully testing their software before it is released to THE
CLIENT.
- Vendors are available to review any test results and defects that the team feel may be
associated with the product software
- It is expected that all users are on IE 7+.
- The project Business Analysts are available to input into the creation of the test cases.
- The test documentation will be created by the test analysts.

Dependencies

List any key dependencies e.g :

- Build and component testing delivered on time and to a reasonable quality. (I.e. all entry
criteria met and system is stable during the first week of test execution).
- Provisioning of the appropriate environments for each phase of testing.
- Utilisation and support of instances of the Test tool
- Service Level Agreements in place for performance testing.
- Service Level Agreements in place for the testing environments.

Page 11 of 25
5. DEFECT MANAGEMENT

5.1 Defect Management Approach

- Defect management requires the Testing team to document and track (i.e. with audit trail) all
defects that have been raised, resolved and that remain open.
- Provides transparency across the project and management on defect status and priorities

5.2 Defect Status and Process

The following table shows the statuses of a defect:

Status Description
Identified A new incident is identified.
Assigned An owner has been agreed and a fix is being created
Fixed Development (i.e. Vendor) has a fix for the defect.
Released For Retest When the fix is released (i.e. code drop by the
vendor) for the test team to re-test
Closed Fix has been successfully tested or it is agreed no
action is required.

All logged Defects should contain the following information:

- A unique identifier (defect number)
- Title for the defect
- Test Phase and test number that identified the defect
- System Area – functional area this defect impacts (best estimate)
- The severity classification of the defect
- Estimated Fix Time - an estimated timescale for resolution (determining the impact on
testing)
- A full description of the Defect and how to recreate the defect
- An indicator of the status of the Defect.
- Level of risk on Go-Live

Wherever possible, the description of the Defect will be written in non-technical terms or the impact of
the Defect will be described in non-technical terms.
Defects will be logged in the following situations:
- When the actual result does not match the expected result and the expected result is correct
- When an expected result does not match an actual result but the actual result is found to be
correct. In this case the action will be to correct the expected result and the Defect log will
provide an audit trail
- When there is an unexpected outcome to a test that is not covered by the expected result.
This may result in the creation of a new entry in the requirement catalogue
- When a Defect is raised to which no immediate acceptable response is available.

Page 12 of 25
Once the project enters the System Test execution phase, typically each morning during test
execution, the Testing Team will review all Defects raised since the previous meeting to determine
any conflicts or impacts across the various phases of test.

After each review session, the status of the defect will be updated and any re-testing of the defect fix
and regression testing will be carried out under the guidance of the Test Manager.

Page 13 of 25
The following flow chart provides an overview of the Defect management process.

Raise Defect

Assign
defect

Defect fixed

fail Fix applied

and re-tested

pass

Defect
Closed

Page 14 of 25
5.3 Defect Severity

The table below describes the levels of defect severity

Severity Description

Entire system or key business process is unusable or does not meet

the needs of the business, many users affected and no workaround is
available; or,
1 - Critical
Corruption or loss of data occurs that is not immediately
recoverable and prevents the business from continuing

Part of the system of key business process is unusable or does not

meet the needs of the business, few users affected but a workaround
is available; or,
2 - High
Corruption or loss of data occurs that is immediately
recoverable and allows the business to continue

A non-critical Defect occurs, typically affecting a single user. The

3 - Medium Defect affects the ability to provide the best service, but there is a
workaround

Cosmetic errors, documentation anomalies, requests for information

4 - Low or advice required

5.4 Defect Priority

This table describes the levels of defect priority

Priority Description of the Impact on the Testing Activity

Incident that prevents all testing from continuing. All testing is

suspended.
1 - Emergency
Target resolution: within 4 hours

Incident that severely impacts testing but testing is able to continue,

possibly with a work around. Testing of particular function(s) is
2 - High possibly suspended.

Target resolution: within 24 hours

Incident that inconveniences testing progress. Testing is able to

continue without much impact. Testing of a single function is possibly
suspended. A test script of procedure error that requires a fix.
3 - Medium
Target resolution: within 3 days

If this defect can’t be resolved in the specified period, the level of risk
on Go-Live will be assessed

Page 15 of 25
 Incident has little or no impact on testing progress.
4 - Low
Target resolution: as agreed.

5.5 Test Progress Reporting Metrics

The Key Performance Indicator that will be used to measure the success of testing is:
- Test Execution:
o Number of Planned Test Cases (total)
o Number of Planned Test Cases (Cum)
o Number of Passes Test Cases (Cum)
o Number of Failed Test Cases (Cum)
o Number of Test Cases in Progress (Cum)
- Defects
o Total defects raised (and by priority)
o Total defects fixed (and by priority)
o Total defects in progress (and by priority)
o Total defects closed (and by priority)
o Total defects by functional area
o Defect severity by Root cause
o Defect severity by application
o Defect severity by Defect Type
o Defect state by application

Page 16 of 25
6. TEST TOOLS

6.1 Introduction

This section describes the types of tools that are required to manage the testing activities contained
within this document.

6.2 Overview of Testing Tool

Describe here which tool is going to be used, and how it allows the user to organise and manage the
testing activities.

 allows the user to catalogue the requirements

 specifies tests to be executed to validate the requirement
 allows the logging of the test results.
 Provides a reporting function that provides management reports and metrics on the testing
progress.

6.3 Test Tool Requirement and description

The following table shows the test tool(s) that will be used to support the testing activities:

Page 17 of 25
APPENDIX A – EXAMPLE TESTING RISK LOG

Re Risk Prob Impac Owner Mitigation

f t
1. Test environment H H Test Ensure that Test Environments
availability for all Manager are documented and provisioned
required testing well in advance of the Test
execution phase for each of the
Projects in scope.
2. Resource constraints M H Project Management – plan resource
for test preparation Manager requirements for both Test
and execution preparation and Test execution
phases with sufficient time to
secure additional resource where
required.
3. Late changes in H M Project Advance notice of changes
scope Manager impacting on Any in-scope project
can feed into any required re-
prioritisation. Contingencies to be
considered for potential delays
4. Inter-dependencies H M Project Where applicable Test harness’
between projects Manager will be created and managed by
streams could hinder each distinct project but the
progress on a single harness should closely represent
deliverable required the source of target system.
for test preparation
or execution
5. External Inter- H M Project Ensure that a close relationship is
dependencies with Manager maintained with external
vendors with late dependency partners and make
delivery could provision for delays when
severely hinder encountered.
progress.
6. Test documentation, L H Test Testing Team to ensure that all
Detailed Test Plan’s Manager Test documentation is approved
not approved prior to prior to commencement as this is
the scheduled Test a key part of the Entry Criteria to
start date each Test phase.
7. Infrastructure M H Test The System Integration Test
components Tested Manager releases will clarify this point but
in isolation may not the sooner the solution
fully prove the components are Tested together
validity of the the better.
solution adopted

Page 18 of 25
APPENDIX B – EXAMPLE DETAILED TEST PHASE DESCRIPTION

System Functional Testing

Item Description
Accountability Test Manager
Responsibility Test Manager
Objectives The objective of System Testing is to:
 Verify that the whole system performs as described in the functional &
technical specification documents.
Approach Location:
The System testing will conducted …
Scope The Testing Team in conjunction with the users and Project team members
define the scope of System Functional Testing.
The following test types are in scope for this phase of the testing:
 Functional Testing

 Usability (User Interface)

 Security Testing

 Error handling

 Regression (if applicable)

 User performance (response time) Testing

Exclusions The following exclusions will apply:

 Some interfaces may not be available to test against

 Penetration testing

Entry Criteria The following entry criteria must be met before the commencement of System
testing:
 100% of agreed functionality has been delivered (subject to the
functionality contained in the release being tested)

 Vendors have fully tested their developments and are formally

delivering the software to THE CLIENT (this will include the
installation of the software )

 System Functional Test Plan has been reviewed and signed off by the
agreed reviewers and approvers. This will primarily be the Project
Team members

 System Functional Test Scripts completed and approved

 All components of the solution correctly configured in the System Test

environment by the vendors .

 Any test data either pre-loaded or available to load as required

 Version, Release, Configuration and Defect Management tools and

Page 19 of 25
Item Description
process defined and implemented

 System Configuration documented and approved.

Entry Criteria will be assessed in the prior to test execution. Variances will be
noted and documented by the Test Manager and System Test Team Lead in
a report along with a risk assessment and recommendation to proceed.
Where entry criteria have not been met the decision to proceed with test
execution is up to the discretion of the:
 IT&S Project Manager

Exit Criteria The System Functional Testing is completed when:

 100% of pre-agreed system test cases have been executed. All high
priority test cases have passed successfully.

 All defects found are recorded.

 All severity 1 & 2 defects are resolved, retested and closed.

 All severity 3 & 4 defects outstanding have documented workarounds

and an agreed (between business, development, testing teams and
vendors) schedule of when they will be corrected.

 A set of pre-defined regression tests have been re-run after fixes

applied and no new errors and/or Defects identified during regression
tests

 Component tested code, executables and s/w configuration under

version control

 Test Summary Report is completed and signed off

Sign-off Completion is achieved when the exit criteria have been met. E-mail sign-off
of the System Test, Test Summary Report (TSR) is performed by the
Approvers outlined in the Testing Strategy and System Test Plan.
Tools The Test Manager is responsible for monitoring progress of the System
Testing and ensuring all tests and results are documented.
Test cases will be entered into Test Director or Excel & then executed. Actual
results will be compared to expected results. Test Results (passed or failed)
are logged in Test Director or Excel along with any defects found. Status
reports will be prepared from Test Director or Excel.

Page 20 of 25
APPENDIX C – TEST PLAN CONTENTS

The Test Plan will have the following contents

Test Plan Identifier
 Unique identifier associated to this Test Plan document
Approvals
 Names and titles of all persons who must approve this Test Plan
Introduction
 Objective of this Test Plan
 Background (summary of the project)
 Scope of the Testing phase this Plan relates to
 References to source material i.e. Project Plan, Configuration Management Plan, Policies &
Standards
Test Items
 Identification of the Test Items, including version/revision levels
 References to all source documentation e.g. Requirements Specification, Design Specification,
Functional/Technical Specification, Technical Solution docs, User Guide, Operations Guide
Features to be tested
 Identification all hardware features, and all software features and combinations of software
features to be tested (descriptions of functionality and activities to be tested)
Features not to be tested
 Identification all features and combinations of features that will not be tested and the reasons
Approach
 Description of the overall approach to Testing. For each major group of features or feature
combinations, specifying the approach that will ensure that these feature groups are adequately
tested
 Specification of the major activities, techniques and tools that will be used to test the
designated groups of features
 The approach will be described in sufficient details to identify the major testing tasks
 Identification of the techniques that will be applied to judge the comprehensiveness of the
testing effort
 Lists of both the Entry and Exit Criteria for the Tests
 Any additional completion criteria e.g. error frequency
 The techniques to be used to trace requirements will be specified
Item pass/fail criteria
 The criteria to be used to determine whether each test item has passed or failed testing, and
the Severity / Priority assigned to each class of Defect
Suspension criteria and resumption requirements
 The criteria to be used to suspend all or a portion of the testing activity on the test items
associated with this Plan
 The testing activities that must be repeated, when testing is resumed
Page 21 of 25
 Test Deliverables
 Identification of the deliverable Test documents i.e. Test Plan, Test Specifications, Test Scripts,
Test Logs, Test Defect Reports, Test Completion Report, Test Data
Testing Tasks
 The set of tasks necessary to prepare for and perform testing (Task, predecessor,
responsibility, effort, end date)
 Identification of inter-task dependencies and any special skills required
Environment needs
 Specification of both the necessary and desired properties of the Test environment
 The physical characteristics of the environment including the hardware, communications and
system software, the mode of usage, and any other software or supplies needed to support the
test
 The level of security that must be provided for all components of the Test environment, i.e.
hardware, software and data
 Identification of the tools needed
 The office space and desks etc required for the Test team
Responsibilities
 Identification of the groups responsible for managing, designing, preparing, executing,
witnessing, checking and resolving
 Identification of the groups responsible for providing the Test Items and Environment Needs
identified earlier
Staff and training needs
 Specification of the Test staffing by skill level
 Training requirements and options for providing necessary skills
Schedule
 Test milestones identified in the Project plan
 Any additional Test milestones needed
 Estimates for the time required to perform each Testing task
 The schedule for Testing tasks and Test milestones
Risks
 Identification of the high-risk assumptions of the Test Plan

NOTES:
Within the Test Plan, a full description will be provided of the test environment, all required test scripts and
harnesses, and all interfaces required with third party systems. Where the environment is not fully
representative of the live environment, the reasons for the limitation will be provided and a risk assessment
undertaken to determine the impact of this on the validity of the results obtained during the tests.
The Test Plan will also specify the input data sources and any expected outputs, including volumes and
types of data. An explanation will be provided for each data type and flow relating it to the predicted or
measured live environment

Page 22 of 25
APPENDIX D – SAMPLE TESTING ROLES AND RESPONSIBILITIES
The following table outlines the test team roles and their responsibilities:

Testing Role Responsibility/Accountable

Test Manager  Responsible for producing the Test Strategy.
 Deliver the High Level Test Plan to be utilised for the
delivery of detailed Test Plans
 Deliver Detailed Test Plan for all the respective test
areas
 Recruitment of the Test Team (e.g. Test Analysts)
 Accountable for Phase Test Plans e.g. ST, UAT,
OAT etc.
 Leading the end-to-end testing effort as outlined in
this Test Strategy document (ST, UAT, OAT etc).
 Management of all testing resources.
 Testing management reporting
 Responsible for creating and maintaining the test
project plan for all core testing activities (as
baselined in MS Project)
 Responsible for ensuring the agreed delivery of all
project testing deliverable’s (as baselined).
 Responsible for estimating, planning and ensuring
appropriate level of resourcing for the project testing
efforts.
 Responsible for managing all project testing related
issues, risks and dependencies. Raising the above
according to the agreed issues and risk management
procedures.
 Responsible for ensuring the specified testing entry
and exit criteria are met for ST, E2E, UAT, TECH.
 Main escalation point between testing and other
teams i.e. business, Development,
Test Phase Team Lead  Provide input into the Test Strategy
 Responsible for providing input into estimating,
planning and ensuring appropriate level of
resourcing for the test phases.
 Create, maintain and ensure sign-off of the Test
Plans.
 Lead the testing effort including: Delivery of the test
cases/scripts, data and results.
 Ensure test artefacts delivered are stored correctly
in Test Director or Excel
 Defect Management relevant to responsible test
phase.
 Manage test preparation and execution risks, and
issues.

Page 23 of 25
Testing Role Responsibility/Accountable
 Create, maintain and ensure sign-off of the Test
Summary Reports.
Test Analysts (TA)  Provide input into the Test Plans.
 Undertake testing activities ensuring these meet
agreed specifications.
 Create, maintain and execute the test cases in Test
Director or Excel.
 Devise, create and maintain test data.
 Analyse and store test results in Test Director or
Excel.
 Raise, maintain and retest defects in Test Director
or Excel)
 Provide input into the Test Summary Reports.
Technical Test Analysts  Provide input into the Technical Test Plans.
(TTA)
 Undertake technical testing activities ensuring these
meet agreed specifications.
 Create, maintain and execute the test cases in Test
Director or Excel.
 Devise, create and maintain test data.
 Analyse and store test results in Test Director or
Excel.
 Raise, maintain and retest defects in Test Director
or Excel.
 Provide input into the Test Summary Reports.
Business Analysts (BA)  Provide business input into the Test Plans, test
cases and test data.
 Execute test cases stored in Test Director or Excel.
 Analyse and store test results in Test Director or
Excel.
 Raise, maintain and retest defects in Test Director
or Excel.
 Provide input into the Test Summary Reports i.e.
business workarounds and impact assessment.
Technical Lead (Team)  Provide solution details to Test Analysts
 Review detailed test plans produced by Test
Analysts
 Input into and review test cases produced by Test
Analysts
 Review and categories/priorities test results
 Validate, raise and progress defects to resolution
Vendors  Input into the test cases
 Review and sign-off the DTP and test cases/scripts
 Review of Test results
 Ownership of defects associated with the vendor
Page 24 of 25
Testing Role Responsibility/Accountable
solution
 Responsibility for issue resolution if associated with
the vendor product/solution
 Assist in testing and defect reproduction for de-bug
information purposes
Global Operations (GO)  Deliver OAT Detailed Test Plan
 Delivery and reporting of OAT testing results and
progress
 Management of the OAT environments
 Execute OAT tests
 Validate, raise and progress defects to resolution
 Sign-off OAT
Business User from THE  Input into the development of the User Acceptance
CLIENT Legal test scripts
 Review and sign off User Acceptance Detailed Test
Plans
 Review and sign off User Acceptance test
requirements and scripts
 Agree acceptance criteria based on the successful
completion of test execution
 Perform User Acceptance Testing
 Sign-off UAT

Page 25 of 25