POL00038937
POL00038937
S80 Release
Testing Plan
Version 1.0
ROLE NAME SIGNATU!
Impact Programme Manager/ $80 Sue Harding
Release Manager
PO LTD S80 Release Test Chris Young
Manager
POL00038937
POL00038937
S80 Release
Testing Plan
1. Document control
1.1. Version history
POL00038937
POL00038937
0.1 22/11/04 Initial draft for internal team review
0.2 14/12/04 Initial issue for POL internal review
0.3 06/01/05 Updated version from POL internal review for external review
04 13/01/05 Updated to include comments from Fujitsu Services
1.0 24/01/05 Issued for Authorisation
1.2. Change co-ordinator
Chris Young, PO LTD Release Test Manager
1.3. Related documents
{1} PO Lid High Level Testing Strategy 1.0 November 2001
(21 PO Lid Incident Management Procedures I 1.4 September 2002
[3] PO Ltd Measurement Incident Progress 1.0 July 2003
Reporting
[4] Testing Approach For The Horizon 1.0 Aug 2003
System
[5] PO LTD Generic Testing Approach 1.0 Sept 2003
nativeFile Page 3 of 43
POL00038937
POL00038937
S80 Release Testing Plan
nativeFile Page 4 of 43
S80 Release
POL00038937
POL00038937
Testing Plan
1.4. Distribution List
Sue Harding IMPACT Programme Manager Post Office Limited Internal
Keith Hall IMPACT Technical Manager Post Office Limited Internal
Steve Grayston IMPACT Business Change Manager Post Office Limited Internal
Peter Jones RDS80 & POL MI Project Manager Post Office Limited Internal
Keith Lawless Smartpost Track & Trace Project Post Office Limited Internal
Ijaz Bhatti +1 Sales Prompts Project Manager Post Office Limited Internal
Jamie Dixon POL Release Implementation Manager Post Office Limited Internal
Torstein Godeseth I IMPACT Design Authority Post Office Limited Internal
Linda Austin POL Release Testing Post Office Limited Internal
James Brett POL Release Testing Post Office Limited Internal
Debbie Shirley POL Programme Office Deployment Post Office Ltd Internal
Bill Reynolds Fujitsu Project Manager Fujitsu Services External
Alan D'Alvarez Fujitsu Development and Test Manager I Fujitsu Services External
Debbie Richardson I Fujitsu Test Manager Fujitsu Services External
Peter Flood Prism Project Manager Prism External
Martin Cox Prism MI Project Manager Prism External
Jim Robson Prism MI Project Manager Prism External
Willie Brown Prism POL FS Testing Manager Prism External
nativeFile Page 5 of 43
S80 Release Testing Plan
2. Contents
CONTENTS
INTRODUCTION
Scope of $80
Summary of $80 E2E Test Phases and Obj
Purpose of PO LTD S80 testing
Assumptions
Migration Testing.....
Overview
Internal Functional Testing,
Non Functional Testing.......
Direct Interface Testing
E2E Integ i Testing.
E2E Functional Testing.
Roles and responsibiliti:
Release Test Manager
Non Functional Test Manger
Horizon Test Man
ager
Horizon Test Analysts
Horizon Test Operator: soe
POL FS Domain Test Manager ...
Client Strand Domain Test Manager
Non Horizon Domain Test Analysts. . . sess . . sees
st Support 21
TEST ENVIRONMENT MANAGEMENT
Horizon configuration......
Post Office configuration (p
Test
Physical test data
System test di
Testing tools
TESTING PROCEDURES
ided by Prism).
Test Planning -.......
Test Execution
Incident Management
Incident management approac!
Incident cla
Incident management proces:
Fix management, .
nativeFile Page 6 of 43
POL00038937
POL00038937
S80 Release Testing Plan
9. APPENDIX B - $80 DIT INTERFACES... sereenene seeeeeener ee BB
410. APPENDIX C —- TEST PLAN — KEY HIGH LEVEL TESTING
MILESTONES... we
41. APPENDIX D —- TESTING SCHEDULES..
12. APPENDIX E — POL $80 TESTING ORGANISATION
41
-42
43
nativeFile Page 7 of 43
POL00038937
POL00038937
S80 Release Testing Plan
3. Introduction
This document outlines the Post Office Ltd (PO Ltd) high-level testing plan for
the S80 release. It identifies the scope and approach for testing, and ascribes
responsibility for testing between PO Ltd, Fujitsu Services, Prism, and other
3" party suppliers/clients.
PO Ltd will use testing to support acceptance of the S80 release from Fujitsu
Services, Prism and other 3rd party suppliers/clients, and for release
authorisation of the service.
The approach detailed within this document is the approach developed over a
number of Horizon releases and documented as part of the revised Fujitsu
contract. This PO Ltd Generic approach was successfully validated during the
$50, S60, S70 and S75 releases without any issues, and will therefore form
the basis of the S80 approach.
This document sits at the top of the PO Ltd Release Testing documents
Hierarchy issued for each release.
Release Plan
Measurement, Incident Rules Of I
Incident Management
3.1. Scope of S80
The S80 release includes major projects commissioned under the Impact
Programme relating to the Post office Ltd accounting process and
management information. These will be delivered together with an
enhancement to the Smartpost system to provide Track and Trace data to the
client, and an application to provide +1 Sales prompts to front line staff during
customer sessions.
The proposed content of S80 is:
e Branch Trading - the implementation of a new process in all outlets
to replace the existing Cash Account process. With the introduction
of Branch Trading, stocktaking, discrepancy and liability handling,
periodicity and reporting formats will all change.
e SAP Financials - the implementation of a new SAP based system,
(POL FS) and new business processes and procedures to support
business accounting and reporting at outlet and business level. This
nativeFile Page 8 of 43
POL00038937
POL00038937
POL00038937
POL00038937
S80 Release Testing Plan
event includes a large data and process migration from CBDB and
it’s various systems interfaces.
Further Impact Programme deliverables to allow full integration of
the new finance systems and changes to the S70 baselined
versions of RDS and POL MI. The new Management Information
System is a replacement for the existing systems such as LID,
STAM and Intellect. It will be built on the current data warehouse
functionality and reduce operating costs to the business. It will
improve granularity, providing a product view of profit and loss. It
will provide a single point for management information and will
allow the redundant MI legacy systems to be decommissioned.
Mails Track & Trace Integration - Enhancement of the smartpost
system to allow the scanning in of mails items being posted using
one of the Royal Mail or Parcel Force Track and Trace services.
The project includes the ability to capture the T&T data and
transmit it to the client systems via the existing Post Office Ltd
external data gateway
+1 Sales Prompts - creation of an intelligent application to run at
the counter and interact with customer sessions, providing sales
prompts, advice and guidance to front line staff, under central Post
Office Ltd control. New reference data structures and processes will
be required to ensure that the application is flexibly driven by
business rules and values. This is a key interface to the existing +1
Sales Training project.
CRs - various, to be confirmed.
The Release will also be used as a vehicle for applying PinICL fixes — as yet
to be agreed.
3.2. Summary of S80 E2E Test Phases and Objectives
The E2E test cycles provide PO Ltd with an independent view of the usability
and appropriateness of the system and services. It confirms end-to end data
integrity across all interfacing systems and end-to-end integrity of supporting
procedures. The tests will specifically seek to confirm that financial integrity is
maintained across the business system.
The following areas will be exercised specifically within the test cycles with the
objective of providing PO Ltd with the necessary assurances.
Integration of upgraded RDS80 with other systems in the E2E
environment
Operation and outputs of the New PO Ltd Management Information
System
Operation of the processes supporting branch trading
nativeFile
Page 9 of 43
POL00038937
POL00038937
S80 Release Testing Plan
Operation of new POL FS functionality and integration with Horizon, client
and PO Ltd accounting systems.
Operation of the new track and trace and +1 sales Prompts products.
Migration testing in terms of POL FS Cutover from CBDB.
Regression packs will be included within the tests to ensure that existing
system functionality and products that are unchanged have not been
impacted.
3.3. Purpose of PO LTD S80 testing
The specific purpose of PO Ltd S80 testing is to:
Support contractual acceptance of the new functionality and agreed
change requests from Fujitsu Services, Prism, and other 3" party
suppliers/clients.
Prove the integration of supplier systems.
Support release authorisation for S80 by PO Ltd.
3.4. Assumptions
There are a number of key planning assumptions for S80 testing by PO Ltd:
Test Reference Data will be aligned and be provided from RDS80.
Suppliers are responsible for and capable of carrying out internal testing to
the point of delivery of a completed internal system to the PO Ltd led E2E
testing phases. Albeit, PO Ltd will wish to be involved with internal testing
via reviewing supplier plans, scripts, results and fault logs. In particular this
will be the method used to achieve the completion of PO Ltd non-
functional testing.
PO Ltd E2E testing will not cover all permutations and combinations as
these are assumed to have been covered prior to E2E, albeit a thin slice
of common failures may be included.
Requirements and acceptance criteria for all S80 components, functional
and non-functional, will have been defined and agreed with all parties.
All new processes and procedures required to support the operation of the
$80 components will have been defined and agreed between all parties.
Individual (hardware and software) components will have been tested,
proved and stable before PO Ltd testing commences.
Fujitsu Services will undertake testing during development and will have
undertaken at least one test cycle as part of their System Validation and
Integration (SV&I) testing.
Fujitsu Services will undertake sufficient regression testing to demonstrate
that the existing Horizon functionality will continue to work.
nativeFile Page 10 of 43
POL00038937
POL00038937
S80 Release Testing Plan
e Fujitsu Services and Prism will have completed their development and
functional testing prior to the final cycle of E2E testing by PO Ltd. Note: As
contingency, further cycles of limited testing may be required after E2E for
specific components if readiness for current testing timescales is not
achieved.
e All suppliers and clients will work co-operatively to support the PO Ltd led
Integration and E2E testing phases.
e Astable E2E test environment is in place, with the S70/75, and S80
(counter) code sets incorporated as appropriate.
e The necessary resources (people, environments, test data, test tools and
test cards) are available from PO Ltd, Fujitsu Services, Prism and other 3rd
parties to support the agreed testing schedule.
e The planned test schedule for S80 can be achieved during 3 x 10 day
cycles of E2E testing. These will start on a Monday, include the middle
Saturday morning (08:00 to 09:30) to ensure that weekend transactions
are included in the test cycle and the final transactions will be undertaken
on the Friday afternoon of the second week. Note — It is accepted that any
transactions performed after this period i.e. Saturday of final week will not
be reported. The rigs will then be accelerated to roll forward to produce
the required reports. Checking of outputs will continue into the third week
during which the rigs will be reset ready for the next cycle.
3.5. Migration Testing
The E2E cycles will carry out testing to confirm as far as possible the
proposed migration approaches planned for the live migration. However,
although tests will prove that the systems function as expected within
controlled business scenarios, they will not provide any indication of the
volumes of mismatches which may occur in live operation or the causes of
those mismatches.
E2E Testing will cover a cross section of products/transaction types that will
be a small percentage of the full range of products actually transacted in live
operation.
nativeFile Page 11 of 43
POL00038937
POL00038937
S80 Release Testing Plan
4. Testing approach
4.1. Overview
The S80 release is classed as a significant release, under the PO Ltd Generic
approach, and therefore testing will include the following stages:
4.2. Internal Functional Testing
Joint working with internal functional testing via the following:
e Review Suppliers internal test plans/ scripts for completeness
e Review Suppliers internal test results / progress reports
e Review Suppliers internal testing fault logs for impact
4.3. Non Functional Testing
Joint working with Suppliers internal non-functional testing via the following:
e Suppliers document reviews
e Review Suppliers test plans for completeness
e Involvement with testing specific key tests during a Suppliers testing cycle
e Review Suppliers test results
e Review Suppliers test fault logs for impact
4.4. Direct Interface Testing
Support Suppliers through the execution of Direct Interface testing between
two suppliers e.g. Horizon to POL FS
e POL to jointly produce and obtain agreement from suppliers to a DIT plan
and testing schedule
e Review Interface scripts between the two supplier domains
e Support set up of test environments
e Support or coordinate the provision of required Reference Data
e Support where appropriate the tests
e Review the test results including any faults
4.5. E2E Integration Testing
This phase is where PO Ltd will lead, supported by Suppliers, in
demonstrating the successful connection of all the appropriate systems
(test versions) in the release E2E solution. To perform some E2E test
nativeFile Page 12 of 43
POL00038937
POL00038937
S80 Release Testing Plan
transactions, to confirm the readiness of all parties to enter the PO Ltd
E2E functional testing cycles.
4.6. E2E Functional Testing
This phase is where PO Ltd will lead, supported by Suppliers, in
demonstrating through short “days in the life of the PO Ltd business” test
cycles that the revised systems interact correctly in an E2E manner, and with
the revised business process and procedures.
This is also to assure PO Ltd that changes to current systems, and the
introduction of new systems have not impacted business operations. It will
prove that E2E financial aspects (accounting, reconciliation, settlement,
remuneration) have been and can be maintained during live operation.
Provide assurance that E2E Management Information is maintained, or new
information reflects the requirements and business needs.
Successful completion of this phase will lead to the introduction into the live
environment via one or more of the following PO Ltd selected options:
¢ apre-pilot (transactions carried out in a passive Post Office)
e pilot (small number of outlets)
e soft launch (a progressive planned roll out)
e go-live ( rolled out to the full estate)
nativeFile Page 13 of 43
POL00038937
POL00038937
S80 Release Testing Plan
5. POLTD Test organisation
Testing of the S80 release will flexibly utilise the appropriate resources from
within the PO Ltd Release test team that reside within the IT skills group.
Some members of this team will also need to prepare for PO Ltd testing of
the S90 release at various stages. Members of the team may also support
other smaller self-contained testing phases e.g. card account releases.
This team consists of IT skills group resources, supplemented by appropriate
external/non IT skill group resources as required.
Note: The POL S80 Release Testing Organisation Chart is included at
Appendix E.
The S80 Release test team consists of:
e A Release Test Manager, who will oversee all S80 test preparation and
E2E test execution activities.
e Non Functional Test Manager, who will manage all the non functional
testing which includes areas such as security, performance, volume
testing, resilience and Disaster recovery. This manager will be supported
by external experts, as and when required.
e Test Domains, who coordinate and manage testing across supplier/client
domains and covering a number of systems.
There are three domains which are:
o Client Strand Domain — covering client data feeds for A&L, NS&l,
FRTS, Camelot, Moneygram and any external client systems that
will not be directly targeted within S80 other than general
regression.
o POL FS Domain - covering expected results for POL FS,
SAPADS, STAMPS, HR SAP, POL CA&CM.
o Horizon Domain — covering Fujitsu Services.
The non IT Skills Group resources required to support testing will include:
¢ Specialist testers, particularly to cover non-functional testing (these will be
expert external consultants, brought in for specific testing activities).
e BAU resources appropriate to the release (e.g. RDS80, TIP, CACM,
Network Support, MI).
e Prism resources (e.g. who support TestDirector).
5.1. Roles and responsibilities
5.1.1. Release Test Manager
The Release Test Manager has the overall responsibility for testing delivery.
The responsibilities of this role are:
e Develop and maintain the S80 release test plans and test schedules.
nativeFile Page 14 of 43
POL00038937
POL00038937
S80 Release Testing Plan
e Provide testing input to the S80 release plan.
e Provide test requirements coverage information to the design authority in
support of the release authorisation process.
e Sign-off the completion of S80 testing.
e Manage S80 testing issues through to resolution.
e Provide risk analysis and manage any risks associated with testing the
release.
e Provide a contact point for testing issues.
e Provide input to the development of S80 acceptance criteria.
e Organise the resources for the team.
e Liase with the different suppliers to maintain the relationship and agree the
environment requirements for S80 testing.
e Assign, schedule and manage the day-to-day activities of the S80 test
team.
e Monitor the progress of the testing activities and prepare status reports as
required.
e Manage the defect/incident management process with the different
suppliers.
e Prepare and distribute daily progress reports throughout the execution
phases.
e Ensure that the testing activity/scripts planned during the various test
phases support the verification of the functional and non-functional
requirements and acceptance criteria in each domain.
5.1.2. Non Functional Test Manger
The Non Functional Test Manager has the responsibility for the delivery of
Non Functional testing. Reporting to the Release Test Manager the Non
Functional Test Manager will review the individual supplier designs and the
PO Ltd business requirements to determine the scope of the Non Functional
testing required for S80. This will consider aspects such as security,
performance, volume and disaster recovery. The responsibilities of this role
are:
e Review supplier Non Functional specifications and determine level of
testing required for security, performance, volume, disaster recovery and
other Non Functional infrastructure changes.
e Produce/review test scripts for all Non Functional testing.
e Agree a witnessing plan for Non Functional testing with each
supplier/client.
e Co-ordinate tests between interfacing suppliers/clients, as necessary.
e Provide Non Functional testing input to the S80 Release Test Plans.
nativeFile Page 15 of 43
POL00038937
POL00038937
S80 Release Testing Plan
e Provide input to the development of S80 acceptance criteria.
e Develop and maintain the S80 testing plans for the Non Functional test
phases.
e Sign-off the completion of S80 Non Functional testing.
« Manage S80 Non Functional testing issues through to resolution.
e Provide risk analysis and manage any risks associated with Non
Functional testing.
e Provide a lead contact point for Non Functional testing issues.
e Organise the Non Functional testing resources, including supporting the
Release Test Manager obtaining additional non-core resources to support
Non Functional testing.
e Liase with the different suppliers/clients to maintain the Non Functional
testing relationship.
e Prepare status reports as required throughout the test preparation stage.
e Assign, schedule and manage the day-to-day Non Functional testing
activities.
e Monitor the progress of the Non Functional testing activities.
Manage the Non Functional defect/incident management process with the
different suppliers.
e Prepare and distribute progress reports throughout the execution phases.
e Ensure that the testing activity/scripts planned during the Non Functional
phases support the verification of the non-functional requirements and
acceptance criteria in each domain.
5.1.3. Horizon Test Manager
Reporting to the Release Test Manager, the Horizon Test Manager will be
responsible for the creation, maintenance and execution of the High Level
test plans (HLTPs) and counter test scripts. The responsibilities of this role
include:
e Manage the development of test scripts to assure the new counter
functionality in relation to:
o +1 Sales Prompts
o Smartpost Track & Trace
o Branch Trading
o Any other changes to functionality being introduced by Fujitsu
Services as part of S80 (e.g. CRs, fixes for previous releases)
e Manage the co-ordination of the interface testing (DIT phase) of all
interfaces where Fujitsu Services are identified as the primary owner of
that interface (see Appendix B).
nativeFile Page 16 of 43
POL00038937
POL00038937
S80 Release Testing Plan
e Assist in the development and/or review of testable acceptance criteria for
functional and non-functional requirements within the Horizon domain.
e Manage the selection and updating of existing test scripts required to
support regression testing of the existing functionality including:
o EPOSS transactions.
o AP transactions (including barcode, magnetic stripe and
SMART).
o Banking transactions.
o Debit Card transactions.
o New functionality introduced at S70/S75.
e Manage the development of counter test scripts to support the testing of
any new non-counter functionality for S80 (e.g. reconciliation processing,
external system requirements, PO Ltd back end requirements).
e Manage the scheduling/planning of the counter tests scripts into test sets
relating to cycles and/or test days within the overall S80 Test Plans.
e Team lead the Horizon testers throughout the preparation and execution
of the S80 testing activities.
e Execute testing scripts.
e Co-ordinate the scheduling/planning of tests into cycles and test days with
Fujitsu Services, PO Ltd and other suppliers.
e Complete status reports for the Horizon domain.
¢ Collect and collate test results.
e Prepare defect reports and provide an impact analysis rating (low, medium
or high) for both the business and testing impacts.
« Re-test fixes.
¢ Provide the liaison between Fujitsu Services and Post Office
Limited/External Systems for testing activities.
e Manage the Horizon counter test environment.
e Provide risk analysis and manage any risks associated with the Horizon
testing domain.
e Support the Release Test Manager in obtaining additional resource as
required to support the E2E test phase.
5.1.4. Horizon Test Analysts
Reporting to the Horizon Test Manager, the Horizon test analysts will be
responsible for the creation, maintenance and execution of the HLTPs and
counter test scripts. They will also deputise as the Horizon test manager when
required. The responsibilities of this role include:
nativeFile Page 17 of 43
POL00038937
POL00038937
S80 Release Testing Plan
e Actas the author for HLTPs and test scripts to test the new counter
functionality in relation to:
o +1 Sales Prompts
o Smartpost Track & Trace
o Branch Trading
o Any other changes to functionality being introduced by Fujitsu
Services as part of S80 (e.g. CRs, fixes for previous releases)
e Maintain/update existing test scripts used during S70 and S75 testing for
regression purposes.
e Schedule/plan test scripts within cycles and/or test days (test sets within
TestDirector) as per the S80 test plans.
e Maintain the script schedules (TestDirector test sets) throughout S80
testing.
e Execute test scripts.
e Support integration test execution.
e Provide testing expertise and training to the testers both on initial
recruitment and as support on an ongoing basis.
e Collect and collate test results to assist in preparation of Expected
Results.
e Prepare defect reports and provide an impact analysis rating (low, medium
or high) for both the business and testing impacts.
e Re-test fixes and confirm successful completion.
5.1.5. Horizon Test Operators
Reporting to the Horizon Test Analysts, the Horizon Test Operators will be
responsible for the creation, maintenance and execution of the counter test
scripts during the E2E cycles.
The responsibilities of this role include:
¢ Maintaining/updating all test scripts used during S80 E2E testing.
e Executing testing scripts.
e Completing status logs.
e Collecting and collating test results.
¢ Document defects.
e Re-testing fixes and confirming successful completion.
5.1.6. POL FS Domain Test Manager
Reporting to the Release Test Manager, the POL FS Domain Test Manager
will be responsible for the creation, maintenance and execution of HLTPs,
nativeFile Page 18 of 43
POL00038937
POL00038937
S80 Release Testing Plan
test scripts and expected results for the back end systems The
responsibilities of this role include:
e Manage the co-ordination of the interface testing (DIT phase) of all
interfaces identified at Appendix B where the primary owner of that
interface is Prism POL FS.
« Gather test requirements for the S80 release from all impacted PO Ltd
areas including:
o POLFS
o CA&CM.
o HRSAP
o STAMPS
o SAPADS
o Audit and Security.
o Finance.
e Assist in the development of testable acceptance criteria for any functional
and non-functional requirements within the POL FS domain.
e Actas the author for test scripts and obtain sign off from the relevant PO
Ltd areas (as detailed above).
e Liaise with the PO Ltd BAU areas to identify and obtain the required
resources for test preparation/execution.
e Execute test scripts.
e Co-ordinate the scheduling/planning of tests into cycles and test days with
the relevant PO Ltd teams.
« Complete status reports for the POL FS domain.
¢ Collect and collate test results.
e Prepare defect reports and provide an impact analysis rating (low, medium
or high) for both the business and testing impacts.
¢ Re-test fixes.
e Provide the liaison and issue management between the third party
suppliers and PO Ltd personnel for testing activities.
5.1.7. Client Strand Domain Test Manager
Reporting to the Release Test Manager, the Client Strand Domain Test
Manager will be responsible for:
¢ Provide the liaison between the PO Ltd and Horizon domains to all
external Clients involved in the release. These include:
o A&l
o NS&l
nativeFile Page 19 of 43
POL00038937
POL00038937
S80 Release Testing Plan
o FRTS
o Camelot
o Moneygram
o Any other external client systems may be identified to be included
within the release.
e Gather the business and client/supplier test requirements for each of the
systems detailed above.
e Provide client liaison during interface testing (DIT phase) as required.
e Assist in the development of testable acceptance criteria for functional and
non-functional requirements for each supplier.
e Manage the development of the HLTPs and test scripts for these domains.
e Work with other members of the testing team to co-ordinate the
scheduling of the test into cycles and test days within the S80 test plans.
e Executing test scripts as required.
e Co-ordinating the tests with the relevant supplier teams in these domains.
e Completing status reports for the Client Strand domain
e Collecting and collating test results.
e Preparing reports and provide an impact analysis rating (low, medium or
high) for both the business and testing impacts.
e Re-test fixes.
e Provide the liaison and issue management between the each of the
suppliers and PO Ltd personnel for testing activities.
e In support of the Release Test Manager, assist in the provision of co-
ordination across all of the domains (PO Ltd, Horizon and external
systems) throughout the E2E test phases, ensuring that all scripted tests
for each domain are supported/planned within dependant domains where
necessary.
e In support of the Release Test Manager provide the consolidation of
status and incident reporting across all client strands.
5.1.8. Non Horizon Domain Test Analysts
Reporting to the POL FS or Client Strand Domain Test Manager, the domain
test analysts will be responsible for the creation, maintenance and execution
of the HLTPs and test scripts for their domain. They will also deputise as their
Domain test manager as and when required.
The responsibilities of this role include:
e Support the co-ordination of the interface testing (DIT phase) of all
interfaces identified at Appendix B where the primary owner of that
interface is their Domain.
nativeFile Page 20 of 43
POL00038937
POL00038937
S80 Release Testing Plan
e Gather test requirements for the S80 releases from all impacted areas
within their domain.
e Assist in the development of testable acceptance criteria for any functional
and non-functional requirements within their domain.
e Actas the author for HLTPs and test scripts and obtain sign off.
e Execute test scripts.
e Co-ordinate the scheduling/planning of tests into cycles and test days with
the other domains.
¢ Collect and collate test results.
e Prepare defect reports and provide an impact analysis rating (low, medium
or high) for both the business and testing impacts.
e Re-test fixes
5.1.9. Test Support
A number of test support tasks are required to ensure the co-ordination and
maintenance of all test environments and test tools.
These activities will be performed within the test domains as appropriate to
include:
The specification and, in liaison with BAU areas, the provision of PO Ltd
reference data required to support the E2E test environment. Also to specify
non-PO Ltd reference data required to support the E2E test environment (e.g.
simulator tables, Mails Reference Data, margin and spot rate files). The
responsibilities of this role also include:
e Specification of all reference data required to support S80 testing.
e Co-ordination of delivery of non-RDS80 data to relevant suppliers.
e Management/maintenance of Test Tools (e.g. TestDirector).
e Maintenance of central ‘pool’ of test scripts.
e Maintenance of test environments details, including use of simulators,
access/availability of external supplier test systems (e.g. NBE, LINK, e-
Pay, NatWest Streamline).
e Co-ordination of E2E test environment requirements/usage.
e Gather the expected result requirements of all domains for the test phases
and develop/maintain a system to meet those requirements.
e Manage the production of detailed expected results for all domains
throughout the test phases.
nativeFile Page 21 of 43
POL00038937
POL00038937
S80 Release Testing Plan
6. Test environment management
A key element of the testing framework is the management of the E2E test
environment. This environment consists of a number of test rigs and/or
simulators, which can be connected together and configured, with suitable
test data, to perform the required tests. Suppliers will provide, maintain,
support and operate the test rigs within their domain. PO Ltd will have overall
management and co-ordination of the E2E test environment.
Maintenance of the environment plan will be the responsibility of the Test
Support Domain. It will be the Test Support’s responsibility to ensure that
external suppliers are aware of their responsibilities for delivering facilities to
the agreed plan.
The following sections describe the S80 testing environments, including the
tools, simulators and test data required for day-to-day operation of the test
environment.
6.1. Horizon configuration
The Horizon E2E test rig at Fujitsu Services consists of the following
elements:
e 12 Counter terminals in the Post Office test room at Feltham (room F1) —
that have existing connectivity to the Post Office testing network.
e Amixture of single, dual and multi-counter office configurations, consisting
of the 12 counter terminals.
e Network monitoring/message spy software to assist in incident
investigation.
e Connections to the NBX and e-Pay.
e Connection to Streamline for debit card regression testing
e EMIS Tool which is required to provide EMIS files in support of regression
testing of DRS outputs relating to debit or credit card transactions
e Transaction Enquiry Service (TES)
« Connection to the PO Ltd test gateways for:
o Delivery of TIP transaction, cash account and client summary files.
(S70 & S75 pre migration to S80)
o Receipt of PO Ltd reference data from RDS80.
o Delivery of the spot rate and margin files from FRTS via the
FTMS/TIP gateway and the EDG.
o Delivery of the daily Trx file for FRTS via the FTMS/TIP gateway.
o Delivery of the control totals file for PO Ltd to the PO Ltd gateway
o Delivery of DRS reconciliation/reports.
nativeFile Page 22 of 43
POL00038937
POL00038937
S80 Release Testing Plan
o Delivery of MIS reports.
o Delivery of NBX Reports
o Delivery of MI interface files for POL MI system
e Connection to Lexcel simulator to emulate EBT card account
¢ Connection to Lexcel simulator to emulate LINK
e Direct connection to Alliance & Leicester test system or connection to
Lexcel simulator (dependent upon client test requirements).
6.2. Post Office configuration (provided by Prism)
e Two test gateways to support the file transfers from Horizon NBX and
DVLA.
e Reference Data System to provide test reference data, and to enable
testing of the enhanced RDS80 functionality and procedures.
e New POL Management Information System
e Delivery of reconciliation and MIS reports.
e Connections to the Electronic Data Gateway.
¢ Connections to POL FS
e OPTIP Test Environment (Pre migration)
« Connections to STAMPS
e Connections to HR SAP
e Connectivity from Horizon to POL FS
6.3. Streamline configuration
Connectivity to the Streamline test environment via an X25.TNS protocol
connection will be required for on-line EMV Retail testing and Streamline,
VISA and Mastercard transactions
An ISDN connection is required for Payment File (and EMIS File if
necessary).
6.4. Test data -
In this context, test data takes the following forms:
e Physical objects are required to support testing — such as DVLA tax discs
and bar codes, network banking cards, debit cards, ETU PIN cards, ETU
cards, AP & OBCS barcodes, Avery Scales, rate boards, POUCH
barcodes.
nativeFile Page 23 of 43
POL00038937
POL00038937
S80 Release Testing Plan
e System data — such as PO Ltd reference data, MAILS tariff data, MID /
TID data for debit card and ETU, margin and spot rate files for Bureau.
The following sections describe physical and system data in more detail.
6.4.1. Physical test data -
The following set of physical objects will be manufactured, maintained and
referenced within the appropriate test scenarios and scripts. Where required,
corresponding system data will be generated and loaded into the appropriate
test system/simulator to enable the use of the objects within the test
environment.
e Network Banking Cards — A set of banking cards for each FI involved in
regression testing, to exercise response / outcome code combinations.
e Debit Cards — A set of magswipe debit and credit cards, again exercising
response code variations for use when interfacing with the Streamline test
system.
e AP Tokens — AP tokens of various types (magnetic card, smart and
barcode) for regression purposes.
e OBCS Barcodes — For regression testing purposes.
e Card account Card Receipt barcodes — As per AP tokens.
e PIN & ETU Cards —A set of PIN and ETU cards.
e Smartpost labels
6.4.2. System test data
Test data required by supporting systems will be specified in advance, and
published within the ‘S80 Release E2E Test Reference Data Specification’
this will allow the creation of test scenarios and detailed test planning.
« POL RDS80 reference data — A backup of the live reference data position
has been taken, on top of this the following data will be created:
o Outlet data, including outlet structures and opening times.
o Standing Data such as new Customer Verification Method,
Permitted Methods of Entry and Banking Operation Types
o Outlet links to non-core products (not EMV Retail or EMV
Banking)
o Additional EFTPoS schemes to support Credit Card
o Additional Retail and Banking operations, items, cards,
bankcard elements, etc.
e Type C reference data to support Identification of cash and near cash
items for SAP FIN.
e MAILS Tariff Data — usually taken from the latest live version available.
« MID/TID Data -for Debit Card and ETU transactions.
e Response Data — to be loaded into the
nativeFile Page 24 of 43
POL00038937
POL00038937
S80 Release Testing Plan
= Simulators within LINK Domain
= Streamline Test System EMIS Response Data — Actions required to
authorise/pend/reject Debit Card transaction received in the daily
payment files.
ETU Response Data — as per the network banking simulator above.
Rate and Margin Data — to provide rate and margin data for updating of
rate board and reference during bureau transactions.
Type D reference data to control the routing of banking transactions via
the NBX.
Revised POL accounting structures/data for Horizon and POL FS.
POL FS reference data feed to RDS80.
6.5. Testing tools
TestDirector will be used to manage the following elements of testing:
Requirements — a hierarchy of requirements that are then used as a basis
for the creation of test scenarios.
Test Planning — a repository for the test scenarios generated to prove
requirements and system functionality.
Test Execution — groups of test scenarios, planned into logical test sets,
and executed in a controlled manner.
Incident Management — tracking the lifecycle of identified incidents,
through identification, action, retest and resolution.
Test Reporting — management information on each of the above
elements, in graph and tabular form.
nativeFile Page 25 of 43
POL00038937
POL00038937
S80 Release Testing Plan
7. Testing Procedures
7.1, Requirements
The requirements of each project within the release are included within a
catalogue of business requirements (Conceptual Designs) that will be used as
a basis for testing and system acceptance. The requirements are owned by
the PO Ltd Design Authority, with changes and updates being managed
through formal change control.
Once a baseline set of requirements is available, it will be imported into
TestDirector. This will form the basis of test scenario creation, with each
scenario being linked to an originating requirement. Once tests are executed,
a view of requirements coverage can be easily obtained.
7.2. Test Specification
Testing the integration of supplier domains will be based on the interface
specifications produced by the relevant suppliers. There are Application
Interface Specifications (AIS) and Technical Interface Specifications (TIS) for
all inter-domain interfaces. Integration testing will develop test scenarios and
test scripts using the agreed AIS and TIS.
PO Ltd testing supports the PO Ltd Release Authorisation process that is
based on the solution achieving the acceptance criteria/methods defined
within the Conceptual Designs (CD). These acceptance methods are used as
the basis for determining the requirements that can be accepted through PO
Ltd testing, and developing test scenarios and test scripts for E2E testing to
support those requirements.
The Test Team will use the Requirements Catalogue and CD to develop the
Test Scenarios required to cover the identified requirements and document
these within a High Level Test Plan (HLTP) for each project. The High Level
Test Plan is a deliverable to the Project manager and PO Ltd Design
Authority for each area, that have responsibility for ensuring that the
scenarios cover the requirement and acceptance criteria satisfactorily and
sign off the Test Plan.
Following development of the HLTP, lower level tests are developed and input
to Test Director, under the relevant folder for execution during E2E Testing.
Appropriate BAU resources will be required to contribute to the development,
review and acceptance of test scenarios and scripts.
Test scenarios and test scripts developed by PO Ltd will be held in
TestDirector, together with the Requirements Catalogue and High Level
Acceptance Criteria for S80.
7.3. Test Planning —
The test plan is a section of TestDirector where tests are created and stored
in a logical hierarchy, or Test Plan Tree. The Test plan tree contains a
nativeFile Page 26 of 43
S80 Release Testing Plan
number of folders/strands covering regression testing of the E2E solution.
These are supported by a folder for each project within the S80 release,
which contain appropriate tests to cover functionality for that area.
The release is broken down into the relevant test phases, and then into the
components of each test phase. For integration testing, this would be each
domain, but for interface testing, it could be each interface under test.
7.4. Test Execution
Tests will be taken from the Test Plan Tree and allocated into a Test Set. A
Test Set is a logical grouping of tests in run order. Test Sets will be executed,
and the results of each test within the set updated. Tests may be classified as
‘Passed’, which indicates a successful run, or classified as ‘Not Run’, ‘Failed’
or ‘Not completed’, in which case, an incident may be raised.
7.5. Incident Management
The E2E test phase assumes that all systems and processes have been
thoroughly tested in isolation, and should therefore be fault free. However,
with all linked interfaces in place, system and/or procedural incidents will be
found.
Given that the objective is to fix any faults that will impact testing or live
operation, it is critical that the status of all incidents are monitored.
TestDirector is used to manage any incidents that are raised. Incidents will be
classified and managed as documented within the ‘PO Ltd Test Incident
Management Process’ [2]. Copies of this document will be issued to all
parties involved in the S80 release.
However, the following sections provide a brief overview of the incident
management process.
7.5.1. Incident management approach
High impact incidents must be fixed, and the service and associated
systems/processes must be retested to ensure the fix is successful and it
has not resulted in the introduction of any new incidents elsewhere in the
service.
The details of each incident identified will be recorded and classified, and
the incident status monitored throughout its lifecycle. Standard reports will
be produced to support management reporting and analysis.
All incidents are linked to test scenarios, so that it is possible to identify which
test to rerun once the defect has been resolved.
7.5.2. Incident classification
Incidents will be categorised by test phase and then major component.
nativeFile Page 27 of 43
POL00038937
POL00038937
S80 Release Testing Plan
The following details are held within the incident management system to
assist the fault analysis and resolution process:
The date the incident was found
A description of the incident
Details regarding how to reproduce the incident (or a clear statement
that the incident cannot be reproduced)
The version of the system or process in which the incident was
found (and where appropriate, details of any environmental
conditions)
The name of the person who detected the incident
Reference to the test case (or Acceptance Test if appropriate)
Testing phase in which the incident was found
The severity of the incident [ratified by the incident review meeting]:
POL00038937
POL00038937
Severity Description
High An incident that has serious impact on functionality or
reliability, such that the service or components of the service
are either:
e Not available or are inoperable
e Prevent further testing of the service or component of the
service
e Prevent key data being passed to another system
e Would render the service unfit for operational use
For a high severity incident, there is no workaround available.
Medium An incident that is obvious to all or many users, but it would
not prevent operation of the service and the service remains
usable. A medium severity incident either:
e Restricts testing, but testing could continue in the short
term without too much detrimental effect
e Would cause significant operational problems
For a medium severity incident, a workaround is available,
but only possible in the short term.
nativeFile Page 28 of 43
POL00038937
POL00038937
S80 Release Testing Plan
Severity Description
Low A minor incident, which might not be noticed by all users, as:
e Its is either cosmetic or an inconsistency
e The service remains usable
e It does not impede further testing
For a low severity incident, either a minor workaround, or no
workaround, is required.
e The priority or urgency for which a fix is needed by the testers or the
business [ratified by the incident review meeting]:
Priority Description
High Required immediately, as testing cannot continue for the
system, or key functions of the system are impaired.
Medium Needs to be fixed as soon as possible (within suppliers’
agreed turn-round times), as it stops or significantly restricts
testing of a particular function or component of the system. A
medium priority incident must be fixed prior to pilot (soft
launch).
Low There is no urgent need, as the impact of the incident is low
and does not impeded testing or would not prevent a move
into pilot (soft launch).
If a test team within one of the System Suppliers identifies and raises
the incident the following additional information will be recorded on the
manual Incident Tracking form:
e The originating organisation.
e The originating organisation’s unique reference number from their
own Incident Management system.
N.B. Supplier raised incidents will be identified by using a combination
of the supplier organisation name and their unique reference number
e.g. Prism 001.
The supplier identifier will be entered into TestDirector so that it is
interlocked with the PO LTD incident tracking.
e The name of the organisation assigned to investigate and resolve
the incident [coordinated by the Test Stage owner or Domain
Coordinator and ratified by the incident review meeting]:
nativeFile Page 29 of 43
S80 Release
POL00038937
POL00038937
Testing Plan
e The status of the incident within the incident management system
(see the following section for a description of the incident lifecycle)
[ratified by the incident review meeting]:
Status Set when Set by
New The incident is reported The person who reports the
incident.
Test Operator/Test Analyst
or Test Stage
Owner/Domain Co-ordinator
Open The Test Stage Test Analyst or Test Stage
Owner/Domain Co- Owner/Domain Co-ordinator
ordinator /Domain Owner
agree that the incident
must be fixed
Rejected The Test Stage Test Analyst or Test Stage
Owner/Domain Co- Owner/Domain Co-ordinator
ordinator /Domain Owner
agree that the incident has
been raised in error
Deferred The Test Stage The Test Stage
Owner/Central Co- Owner/Central Co-ordinator.
ordinator or daily progress
meeting determine that the
incident is to be deferred,
or is an enhancement, and
is to be fixed at some point
in the future, after E2E
testing.
Fixed The incident has been The Test Stage
fixed, tested in Owner/Domain Co-
development and is ordinator.
available for testing
Closed When the fix is included The individual who identified
within a full release and the incident.
this release has been
tested by an independent Test Operator/Test Analyst
tester to show the incident I oF Test Stage 7
is fixed Owner/Domain Co-ordinator
nativeFile Page 30 of 43
POL00038937
POL00038937
S80 Release Testing Plan
Reopen When the incident is The individual who identified
shown to still be present that the incident is not fixed
Test Operator/Test Analyst
or Test Stage
Owner/Domain Co-ordinator
nativeFile Page 31 of 43
S80 Release Testing Plan
7.5.3. Incident management process
The diagram below shows the lifecycle for an incident reported by PO
Ltd or suppliers, indicating how the status changes as the incident is
reviewed, fixed and re-tested.
Incident raised I Incident reviewed
status: New status: (see options below)
v ¥ , ¥
status: Rejected status: Open status: Deferred
Y
Incident fixed
status: Fixed
Y
Pass
¥
New release tested : pass
status: Closed
7.5.4. Fix management
In order to ensure that fixes and changes to software and environment levels
are maintained in a controlled manner it is necessary to implement the
following tightly controlled processes:
Each System Supplier will appoint a Version Control Representatives
to act as their central notification point through whom all
communications and approvals pass.
On entry into the PO Ltd Testing, the system suppliers will be
responsible for baselining their system levels as a reference point for
future updates. The version levels of the supplier systems will be
notified to the PO Ltd Testing Domain owner who will distribute this
information to all interested parties.
No updates to systems, applications, data or environments impacting
the systems within the scope of the release will be permissible unless
agreed and approved with the PO Ltd Testing Domain owner. All
updates will be controlled by the PO Ltd Testing Domain owner.
Fixes or changes will be compiled into release packages.
On completion of a release package to match a release window, each
supplier will create a list of content for their package including all fixes
nativeFile Page 32 of 43
POL00038937
POL00038937
Incident tested: fail
Test Fail status: Re-open
POL00038937
POL00038937
S80 Release Testing Plan
and changes being applied. Each supplier will also indicate the new
version level of their system(s) and pass this on to the PO Ltd Testing
Domain owner.
e On agreement of the release content, the system suppliers will
implement their fixes and changes within the pre-agreed release
window.
7.6. Test reporting
Monitoring the progress and measuring the success of E2E testing is a
vital management tool required to assess the suppliers performance
against requirements, as input into the Release Authorisation/Acceptance
process, and to gauge the business and systems readiness to move into
a live environment. Test reporting will be managed in accordance with PO
Ltd Measurement Incidents and Progress Reporting [3]. This document
resides within the PO Ltd Testing document hierarchy and sits under this
Test Plan. It will be issued to all parties involved in the S80 release. This
section provides a brief overview of the document's coverage.
During the previous major PO Ltd releases the PO Ltd testing team
developed and maintained a reporting system covering progress,
measurement and incidents across the release.
Daily progress reports were completed by each domain and consolidated
into a release progress report.
Incidents statistics and details were maintained monitored and reported.
Measurement information provided reporting on three dimensions across
the release; Performance, Confidence and Coverage.
This reporting stream allows progress to be measured in a controlled
manner, giving managers a clear picture of the current status and the
rising confidence of the system(s) and processes under test.
For The S80 Release, the outputs from Test Director will be used to create
the reporting described above.
7.7. Test schedule
As with previous releases, planned test schedules, which show the PO Ltd led
phases, have been developed to support S80 testing and are documented
separately in appendix C.
nativeFile Page 33 of 43
S80 Release
Testing Plan
8. Appendix A — Glossary of Terms & Abbreviations
AIS Application Interface Specification
APS Automated Payments System
A&L Alliance & Leicester
BAU Business as Usual
BCM Business Change Management
cD Conceptual Design
DIT Direct Interface Test
DR Disaster Recovery
DRS Data Reconciliation Service
DVLA Driver & Vehicle Licensing Agency
E2E End-to-end
EDG Electronic Data Gateway
ETU Electronic Top-Ups
Fl Financial Institution
FRTS First Rate Travel Services
HLTP High Level Test Plan
HMIS Horizon Management Information System
LINK LINK banking network
LINK FI A financial institution connected via the LINK network
NBX Network Banking Engine Replacement
NNDB National Network Data Base
NS&l National Savings & Investments
NSSC National Secure Stock Centre
PIN Personal Identification Number
PO Ltd Post Office Ltd.
POL FS Post Office Ltd Financial Systems
RDS80 Reference Data System
nativeFile Page 34 of 43
POL00038937
POL00038937
POL00038937
POL00038937
S80 Release Testing Plan
SV&l System Validation and Integration Testing
Testing
TID Terminal Identifier
TIS Technical Interface Specification
nativeFile Page 35 of 43
S80 Release
POL00038937
POL00038937
Testing Plan
9. Appendix B - S80 DIT Interfaces
Description Comment Support Role
1 TMS POL FS Transaction Data Fujitsu Prism (POL FS)
(Horizon) (Txn via XI Middleware Services
Data)
2 TMS First Transaction Data/ Fujitsu Prism (EDG) First Rate
(Horizon) Rate Controls Totals via Services
Travel EDG
Service
(FRTS)
3 TMS Mi (Txn Transaction Data Fujitsu Prism (Ml)
(Horizon) Data) via FTMS Services
4 TMS HR SAP Remuneration Fujitsu Prism (HR SAP)
(Horizon) Data via FTMS Services
5 TMS PO Ltd CTS Data via Fujitsu Prism (PO Ltd Gateway)
(Horizon) Gateway FTMS Services
6 TMS Track Track and Trace Fujitsu Prism (EDG) PO Ltd (Track
(Horizon) and Data via EDG Services and Trace Client)
Trace
Clients
7 RDS 80 TMS Reference Data Fujitsu Prism (RDS80)
(Horizon) via FTMS Services
8 POL FS TMS Direct Link for Txn Prism Fujitsu Services
(Horizon) Corrections (POL FS)
nativeFile
Page 36 of 43
S80 Release
POL00038937
POL00038937
Testing Plan
Description Comment Support Role
9. POL FS NS&l Transaction Prism Fujitsu Services (FTMS)
Summaries via (POL FS) Prism (EDG)
FTMS/EDG
10. POL FS ABL Transactions via Prism Fujitsu Services (FTMS)
FTMS/EDG (POL FS) Prism (EDG)
"1 POL FS ESFS Financial Data via Prism Prism (ESFS)
FTMS (POL FS) Fujitsu Services (FTMS)
12 POL FS BACS BACS Payments Prism (POL POL/Prism (BACS)
File via FTMS FS) Fujitsu Services (FTMS)
13. POL FS SAPADS Payment Values Prism Prism (SAPADS)
via FTMS (POL FS) Fujitsu Services (FTMS)
14 POL FS RDS 80 Reference Data Prism Prism (RDS80)
via FTMS (POL FS) Fujitsu Services (FTMS)
15, RDS 80 POL FS Reference Data Prism Prism (RDS80)
via FTMS (POL FS) Fujitsu Services (FTMS)
16 SAPADS POL FS Transactions via Prism Prism (POL FS)
FTMS (SAPADS) Fujitsu Services (FTMS)
17 STAMPS POL FS NSSC Stock via Prism STAMPS
FTMS (POL FS) Fujitsu Services (FTMS)
18. Camelot POL FS Transaction Data Development of CR248 Prism POL (Camelot)
via EDG/FTMS (POL FS client data (POL FS) Prism (EDG)
feeds) is unlikely to be Fujitsu Services (FTMS)
completed for DIT
19, Money POL FS Transaction Development of CR248 Prism POL (Moneygram)
gram Summaries via (POL FS client data (POL FS) Prism (EDG)
EDG/FTMS feeds) is unlikely to be Fujitsu Services (FTMS)
completed for DIT
nativeFile Page 37 of 43
S80 Release
POL00038937
POL00038937
Testing Plan
Description Comment Support Role
20 EDS POL FS TVL, Personal Development of CR248 Prism POL (EDS)
Banking and (POL FS client data (POL FS) Prism (EDG)
Cheques data via feeds) is unlikely to be Fujitsu Services (FTMS)
EDG/FTMS completed for DIT
21. FRTS POL FS Travellers Development of CR248 Prism POL (First Rate)
Cheques data via (POL FS client data (POL FS) Prism (EDG)
EDG/FTMS feeds) is unlikely to be Fujitsu Services (FTMS)
completed for DIT
22. ABL POL FS Giro Errors via Development of CR248 Prism POL (A&L)
POL Gateway (POL FS client data (POL FS) Prism (POL Gateway)
feeds) is unlikely to be
completed for DIT
23. ASL POL FS ATM Transaction Development of CR248 Prism POL (A&L)
Summaries via (POL FS client data (POL FS) Prism (POL Gateway)
POL Gateway feeds) is unlikely to be
completed for DIT
24 HANCO POL FS ATM Transaction Development of CR248 Prism POL (HANCO)
Summaries via (POL FS client data (POL FS) Prism (POL Gateway)
POL Gateway feeds) is unlikely to be
completed for DIT
25. TRM POL FS ATM Transaction Development of CR248 Prism POL (TRM)
Summaries via (POL FS client data (POL FS) Prism (POL Gateway)
POL Gateway feeds) is unlikely to be
completed for DIT
26. Bank POL FS ATM Transaction Development of CR248 Prism POL (Bank Machines)
Machines Summaries via (POL FS client data (POL FS) Prism (POL Gateway)
POL Gateway feeds) is unlikely to be
completed for DIT
27. DVLA POL FS Transaction Development of CR248 Prism POL (DVLA)
Summaries via (POL FS client data (POL FS) Prism (POL Gateway)
POL gateway feeds) is unlikely to be
completed for DIT
nativeFile Page 38 of 43
S80 Release
POL00038937
POL00038937
Testing Plan
Description
Comment
Support Role
28. Branch MI Management Prism (Ml) POL (BST)
Sales Information via Prism (POL Gateway)
Targets POL Gateway
29. Sales MI Management Prism (Ml) POL (SF)
Forecasts Information via Prism (POL Gateway)
POL Gateway
30. Fixed MI Management Prism (Ml) POL (Fl)
Income Information via Prism (POL Gateway)
POL Gateway
34 Camelot MI Transaction data Prism (Ml) POL (Camelot)
via EDG Prism (EDG)
32 Non MI Financial Services, Prism (Ml) POL (Various)
Horizon Change Giving Prism (POL Gateway)
Data ATMS, Home
Phones etc.
transaction data
via POL Gateway
33. RDS 80 MI Reference Data to Interface Connection Prism (Ml) Prism (RDS 80)
MI method to be agreed
34 EDS MI TVL, Personal Prism (Ml) POL (EDS)
Banking and Prism (EDG)
Cheques data via
EDG
36. ESFS MI Income Data via Prism (Ml) Prism (ESFS)
Direct Interface
36. MI HR SAP Non Horizon Prism (Ml) Prism (HR SAP)
Remuneration data
via Direct Interface
37 EDS Mi Card Account data Prism (Ml) POL (EDS/Card Account)
via POL Gateway
Prism (EDG)
Page 39 of 43
POL00038937
POL00038937
Description Comment Support Role
38. HR SAP RDS 80 Interface to be agreed Prism Prism (HR SAP)
(RDS 80)
39. RDS 80 Siebel Interface to be agreed Prism Prism (Siebel)
(RDS 80)
nativeFile Page 40 of 43
S80 Release
POL00038937
POL00038937
Testing Plan
10. Appendix C —- Test Plan - Key High Level Testing Milestones
S80 Direct Interface Testing
PO Lid Test Team
24/01/05 04/02/05
S80 Prism POL FS functional testing 19/11/04 20/01/05 Prism
S80 Fujitsu SV&I Cycle 3 28/02/05 18/03/05 Fujitsu Services
S80 E2E Testing Cycle I 14/02/05 25/02/05 PO Ltd Test Team
S80 E2E Testing Cycle 2 07/03/05 18/03/05 PO Lid Test Team
S80 E2E Testing Cycle 3 29/03/05 08/04/05 PO Ltd Test Team
nativeFile
Page 41 of 43
POL00038937
POL00038937
S80 Release Testing Plan
11. Appendix D - Testing Schedules
I
1 2 3 4 I 5 6 7 8 9 10 "1 12
Mon I Tue I Wed = Thur I I Fri Sat I Sun I Mon I Tue I Wed I Thur I Fri
24/01/2005 - 04/02/2005 14/02/2005 - 25/02/2005 07/03/2005 - 18/03/2005 29/3 - 8/4
Integration Testing $80 E2E Cycle 1 Back-end chgeKing $80 E2E Cycle 2. Back-end checking $80 E2E Cycle 3 Back-end checking
A A A A. A. A.
Nf Vv \ C Y \
31/1 72 J 14/2 21/2 242 J 7/3 14/3 243 J 28/3 4/4 11/4
7/2 - 11/2 28/2 - 4/3 21/3 - 25/3
Rig Rebuild Rig Rebuild Rig Rebuild
nativeFile Page 42 of 43
S80 Release
POL00038937
POL00038937
Testing Plan
12. Appendix E — POL S80 Testing Organisation.
Sue Harding Kevin Brothwood
Impact Programme IT Integration
Manager Programme Manager
[ J
[
Chris Young
S80 Release Testing
Manager
I
[ I I I
Lee Farman James Brett Linda Austin Andrew Thompson
Non-Functional Test Horizon Domain POL FS Domain Client Strand
Manager Manager Manager Domain Manager
As Required 5 x Horizon Test 4x POL FS Test 1 x Client Strand
Non-Functional Analysts Analysts Test Analyst
Domain Support Andy Fisher Michele Storey Nell Payton
Martin Rolfe Paula Woolley
Andy Hamilton* Richard Fielden
Gary Webb* Mike Dybala
Jon Thompson* 7 x Test Operators
I Andy Hamilton*
Gary Webb*
Branch Trading Jon Thompson* AGL
Track & Trace +4 (Test Execution Expected Results NS&l
+1 Sales Prompts Only) POL FS CR248
Regression Packs SAPADS File Delivery
Horizon Counter STAMPS changes to:
Tests for NBSC, HR SAP Camelot Moneygram
SAPADS, POL FS, meh etc,
STAMPS, MI, HR
SAP, Migration. (cA+cM) & CRs.
Assurance of
RDS80 Functional
Testing
Keyed Test
Reference data for
E2E
MI Functional
Testing Assurance
MI E2E Testing
nativeFile
Page 43 of 43