S70/S75 Release
Testing Plan
Version 0.3
ROLE
Delivery Director
$70/S75 Release Manager
PO LTD Release Test Manager
NAME SIGNATURE
Dave Smith
Mare Reardon
Peter Jones
POL00038881
POL00038881
POL00038881
POL00038881
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
1. Document control
1.1. Version history
05/03/04 Initial draft for internal team review
0.2 23/03/04 Initial issue for POL internal review
0.3 16/04/04 Updated version from POL internal review for external review
1.2. Change co-ordinator
Peter Jones, PO LTD Release Test Manager,}
1.3. Related documents
{1} PO Lid High Level Testing Strategy 1.0 November 2001
(2] PO Lid Incident Management Procedures I 1.4 September 2002
[3] PO Ltd Measurement Incident Progress I 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 61
$70 \ S75 Release
POL00038881
POL00038881
Testing Plan
1.4. Distribution List
Dave Smith IT Delivery Director Post Office Limited Internal
Mare Reardon $70 Release Manager Post Office Limited Internal
Sue Harding IMPACT Programme Manager Post Office Limited Internal
Beverly Dunn Banking Programme Manager Post Office Limited Internal
Louis Prastitis IMPACT Technical Manager Post Office Limited Internal
Steve Grayston IMPACT Business Change Manager Post Office Limited Internal
Mark Lodge NRDS & POL MI Project Manager Post Office Limited Internal
Tim Batterbee Card account Project Manager Post Office Limited Internal
John Bruce POL Release Implementation Manager Post Office Limited Internal
Bob Booth Solutions Architect Post Office Limited Internal
Jason Crellin Solutions Architect Post Office Limited Internal
Jason Slatcher Solutions Architect Post Office Limited Internal
Torstein Godeseth IMPACT Design Authority Post Office Limited Internal
Keith Fowler $70/S75 Technical Programme Manager Post Office Limited Internal
Jeremy Nash Streamline Testing Streamline External
Steve Tate EDS Test Manager EDS External
Alan D’Alvarez Fujitsu Development and Test Manager Fujitsu Services External
Debbie Richardson I Fujitsu Test Manager Fujitsu Services External
Tony Brain IMPACT Programme Manager Prism External
Martin Cox Prism NRDS & POL MI Project Manager I Prism External
Peter Rusling Parity NRDS & POL MI Project Manager I Parity External
Dave Lawrence IBM Service manager IBM External
Neil Scott Alliance & Leicester Testing Alliance & Leicester External
Andrew Bames LINK Project Manager LINK External
nativeFile
Page 4 of 61
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
2. Contents
4, DOCUMENT CONTROL 3
LL 3
1 3
1 3
1.4, 4
2. CONTENTS 5
3. INTRODUCTION 7
3.4. Scope of S70/S75 7
3.1.1. New Reference Data System 8
New PO LTD Management Information System 9
EMV Retail 10
NBX (NBE Replacement ll
EMV Banking 1
CP’s for inclusion at S70 1
12
mM 5 Test Phases and Objectives 12
12
S7 13
Purpose of PO LTD $70/S75 testing 13
Assumptions 13
Migration Testing 15
1s
15
18
18
Internal Functional Testing 18
Non Functional Testing 18
Direct Interface Testing 18
Certification or Accreditation Testing 18
E2E Integration Testing 19
47. E2E Functional Testing 19
5. POLTD TEST ORGANISATION 20
Roles and responsibilities 21
Release Test Manager 21
Non Functional Test Manger 22
Horizon Test Manager 23
Horizon Test Analysts 24
Horizon Test Operators 25
PO Ltd Domain Test Manager 25
External Systems (Banking) 26
External Systems (Non-Banking) 27
Domain Test Analysts 28
Test Support 29
6. TEST ENVIRONMENT MANAGEMENT 30
$70 and $75 test environment 30
Horizon configuration 30
Post Office configuration (provided by Prism) 31
Streamline configuration 31
NBE configuration 31
LINK configuration ($75 Only) 32
Alliance & Leicester configuration (S75 Only) 32
First Rate configuration (not required for cither $70 or S75 release) 32
nativeFile Page 5 of 61
$70 \ S75 Release Testing Plan
6.L8. NS&I configuration (not required for either $70 or $75 release) 32
6.1.9. — e-Pay configuration (S70 & $75) 32
6.1.10. card account configuration (S75 Only) 33
6.2. Test data - 33
. Physical test data - 33
. System test data 33
6.3. Testing tools 34
7. TESTING PROCEDURES 36
7a. ~ Requir 36
72 36
36
Test execution 37
Incident management 37
5.1. Incident management approach 38
n 38
Incident management process 43
. Fix management 4B
7.6. Test reporting 44
22. Test schedule 44
8. APPENDIX A- GLOSSARY OF TERMS 46
9. APPENDIX B — S70 INTERFACE DIAGRAM & MATRIX 48
410. APPENDIX C — TEST PLAN - KEY MILESTONES 56
41. APPENDIX D - SCHEDULES 58
412. APPENDIX E —$70/S75 NRDS MIGRATION AND TESTING 60
nativeFile
Page 6 of 61
POL00038881
POL00038881
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
3. Introduction
This document outlines the Post Office Ltd (PO Ltd) high level testing plan for
the S70 and S75 releases. It identifies the scope and approach for testing
each release, and ascribes responsibility for testing between PO Ltd, Fujitsu
Services, Prism, IBM and other 3° party suppliers/clients.
PO Ltd will use testing to support acceptance of the S70 and S75 releases
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
recent S50 release without any issues, and is again being operated for the
S60 release, and will therefore form the basis of the S70/S75 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 S70/S75
The S70 release includes 3 main components, together with agreed change
requests and defect fixes. Two of these components being projects within the
Impact programme the other being within the Banking programme.
The three main components of S70 are:
1. New Reference Data System
2. New PO LTD Management Information System
3. EMV Retail
In addition to these, the Horizon counter code will support EMV Banking at
this release and therefore S70 testing will include pre-proving as much as
possible the “counter” element of S75.
The S75 Release includes two main components, together with agreed
change requests and defect fixes.
nativeFile Page 7 of 61
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
The two main components of S75 are:
4. NBX (NBE Replacement)
5. EMV Banking
3.1.1. New Reference Data System (NRDS)
The current reference data processes and systems within POL are complex,
inflexible and inconsistent. There are several key systems within POL which
key in their own reference data and there are several more systems which
key in their own reference data which exists in master systems. The New
Reference Data System will ensure consistency in reference data usage
within Post Office and Fujitsu, simplify the current processes and allow
changes to be made in a more timely fashion. This will support data driven
change within the business, a reduction in operation costs, the removal of
inconsistent reference data within the organisation and improved speed to
market. It will also support a fully automated end to end process to capture
reference data changes to reduce delays and errors.
The current reference data systems feed many other legacy systems; these
feeds must remain in place and must remain in exactly the same format as
they are currently. There will be no changes to any interface files during this
project and there will not be any requirement for change to any of the
receiving systems.
NRDS Interfaces
Ref I Status Existing Interface New Interface Frequency Transfer
Mechanism
From To From To
1 I Existing I NNDB/PIVOT HMIS. New RDS. HMIS Weekly FTP
2 I Existing I NNDB/PIVOT Local New RDS Local Monthly FTP
schemes schemes
3. I Existing I NNDB/PIVOT RFLS New RDS RFLS Monthly FTP
4 I Existing I NNDB/PIVOT POCM New RDS POCM Daily FTP
5 I Existing NNDB CREDO I NewRDS I CREDO Monthly FTP
6 I Existing PAF NNDB PAF New RDS Monthly Tape
7 I Existing Intellect UK PA New RDS UK PA Fortnightly FTP
8 I Existing RDS Internet New RDS Internet Weekly Email
9 I Existing RDS Link New RDS Link Weekly Email
10 I Existing RDS NBSC New RDS NBSC Weekly FTP
nativeFile Page 8 of 61
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
Ref I Status Existing Interface New Interface Frequency I Transfer
Mechanism
From To From To
ll Existing RDS. Network New RDS Network Daily FTP
Bank Bank
12 Existing RDS NRM New RDS NRM Monthly FTP
13 Existing RDS EDS card New RDS EDS Weekly Email
account
14 Existing RDS POLC New RDS POLC Weekly FTP
1S Existing RDS SAPADS New RDS SAPADS Weekly Email
16 Existing RDS. AP Clients New RDS I AP Clients Weekly Email
17 Existing RDS Horizon New RDS Horizon Daily FIP
18 Existing WRDS. EDS Data New RDS EDS Data Weekly FTP
Central Central
19 Existing, RDS WRDS New RDS MI Daily FIP
20 I Existing/ RDS OpTIP New RDS OpTIP Daily FTP
Temporar
y
21 I Existing RDS e-pay New RDS c-pay Daily FTP
22 New - - HRSAP New RDS. Daily FTP
23 New : : ES-FS New RDS ? ?
24 New - - New RDS Benefits ? ?
Agency
3.1.2. New PO LTD Management Information System
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.
MI Interfaces (Inbound)
e NRDS
e ESFS
va
Internal Order Data
nativeFile
Page 9 of 61
$70 \ S75 Release Testing Plan
> Cost Centre Data
e Branch Sales Targets
« CBDB
¢ Horizon
» Transaction Files
> Client Transmission Files
>» Cash Account Files
© Client Reported Errors
> DVLA
> Order Book Control Service (OBCS)
> Girobank
v
Benefits Agency
¢ Fixed Income
e Local Schemes
e Sales Forecast
MI Interfaces (Outbound)
e Branch Error Advice Letters
3.1.3. EMV Retail
Smart card tokens (EMV chip cards / Integrated Chip Cards [ICC]) with PIN
as the customer verification are being introduced in the UK electronic
payments industry in order to combat card fraud. The advent of EMV, or Chip
& PIN as it is also referred to, introduces:
1. Chip — a secure Integrated Chip Card token that cannot be easily
counterfeited — unlike magnetic cards that are simply, and regularly
copied.
2. PIN —in place of signature at the point of sale for retail, the customer
will enter a PIN number.
The importance of the chip is that it can process and authenticate the entered
PIN and this allows terminals to verify the customer without having to go on
line (off-line PIN — Retail Point of Sale model. For retail, this means that PIN
verification can now occur anywhere — just like a signature, in a taxi, on a train
etc. — but with high degree of confidence that the card is genuine.
In the retail sector, where debit and credit cards are used, from 01/01/2005,
EMV transactions will become the normal transaction type. From this date,
the card schemes will change the liability for card fraud to sit with the party
that has the weaker security system and if the Post Office™ were unable to
accept EMV cards it would be open to greater liability challenges.
nativeFile Page 10 of 61
POL00038881
POL00038881
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
The introduction of the EMV standard for cardholder verification and card
authentication means that a number of mechanisms originally developed for
stripe card and signature will need to be enhanced to allow for EMV. The
main EMV development, to add EMV processing, will support the same
transaction set as the magnetic card, but with the chip token rather than
magnetic swipe and PIN for customer verification. Note that signature
remains the Cardholder Verification Method (CVM) for mag cards and that
signature and no CVM are possible for ICC.
3.1.4. NBX (NBE Replacement)
The functionality currently provided by IBM via the NBE is to be supplied by
Fujitsu Services, in addition to current functionality, the replacement for the
NBE will also be capable of dealing with banking transactions initiated via ICC
cards. The replacement for the NBE is to be called “NBX”.
The NBX will interface with card account, LINK and Alliance & Leicester. It will
also provide management information and a Transaction Enquiry Service
(TES) that will be the replacement for Data Navigator
3.1.5. EMV Banking
In the banking sector, the agreement with the Government and expectation of
Banks participating in Universal Banking services is that Post Offices would
migrate to Chip/PIN in line with the industry i.e. 01/01/2005 and this aligns
with the LINK expectation that its’ acquiring network will be chip and PIN
capable by this date.
All the banking transaction types currently available through magcard swipe
are to be made available via the insertion of ICC cards into the Pin Pad at
Horizon counters. Note that deposit transactions will not require the input of a
PIN.
3.1.6. CP’s for inclusion at S70
¢ P3467 - Change the delivery mechanism for D type reference data
e CP3572 - Process for updating Smart Post HTML files — full solution
e CP3595 - System Management platforms to be maintained within POA
SCM process
¢ CP3626 - BFPO Selection in Smart Post
¢ CP3627 - Generic Message Tablet in Smart Post
e CP3647 - Support for signature CVM and for no CVM
e CP3648 - Beeps relating to EMV card slot
nativeFile Page 11 of 61
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
e The Release will also be used as a vehicle for applying PinICL fixes — as
yet to be agreed.
3.1.7. CP’s for inclusion at S75
e There are no CP’s currently targeted at S75
e PinICL’s identified during testing of S70 may be targeted to be fixed at
S75
3.2. Summary of S70/S75 E2E Test Phases and Objectives
3.2.1. $70 E2E
e Integration of NRDS with other systems in the E2E environment
e Operation and outputs of the New PO Ltd Management Information
System
e EMV Retail counter functionality and E2E data integrity including
reconciliation and settlement. Plus accreditation for debit and credit cards
achieved via on-site (Feltham) testing by Streamline personnel. This on-
site testing is specifically targeted at obtaining
o Streamline Accreditation
o Mastercard Accreditation
o VISA Accreditation
e EMV Banking — From a counter perspective all functionality for S75 will be
present at S70 and as much of the banking solution as possible will be
tested during S70 E2E.
o Counter screens Non-Core control products for the migration of
Non-EMV to EMV
o Connectivity to EBT test environment via key exchanges and
exchange of administrative type messages from the test NBX
platform.
o Running and pre-proving LINK accreditation scripts from a
counter perspective via an enhanced NB emulator
o The definition of EMV enabled cards and Issuer Schemes by
NRDS
o The Fujitsu maintained reference data applied to the Pin pad
which identifies the banking Application Id’s appropriate to LINK,
A&L and card account
o Use of type D reference data to prove the mechanism for routing
banking transactions from NBE to NBX as per the proposed
migration plan
nativeFile Page 12 of 61
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
o Creation by RDS of 13 new Banking Operation Types
o Adding Service Code as a Bank Card Element for each Bank
Card to be tested for EMV
°
3.2.2. S75 E2E
e Operation and outputs of the NBX for both EMV and non-EMV banking
transactions
¢ Migration testing in terms of Cutover from the NBE to the NBX and then
cutback to the NBE should this contingency state be required in Live
e E2E operation of EMV Banking Services
e Gain formal LINK accreditation for the introduction of EMV Banking and
the introduction of the NBX. The process of achieving accreditation from
LINK is in two stages. The first stage is to be gained during Fujitsu SV&l
testing when an agreed set of tests will be run against a Lexcel Simulator
within the Fujitsu domain and resultant transaction logs and trace files will
be sent to LINK for examination. The second stage is to perform a set of
transactions agreed with LINK over the E2E environment with transactions
being authorised by a Lexcel Simulator within the LINK domain.
e Gain agreement from card account that the NBX and EMV Banking
solutions can be migrated into the production environment.
e Gain agreement from Alliance & Leicester that the NBX and EMV Banking
solutions can be migrated into the production environment. However at the
time of writing, there has been no discussion with Alliance & Leicester
regarding their involvement in S75 E2E testing.
3.3. Purpose of PO LTD S70/S75 testing
The specific purpose of PO Ltd S70/S75 testing is to:
e Support contractual acceptance of the new functionality and agreed
change requests from Fujitsu Services, Prism, IBM and other 3 party
suppliers/clients.
e Prove the integration of supplier systems.
e Support release authorisation for S70 and S75 by PO Ltd.
3.4. Assumptions
There are a number of key planning assumptions for S70/S75 testing by PO
Ltd :
e Test Reference Data will be aligned and be provided from both current
RDS and NRDS for S70 and from NRDS only for S75.
nativeFile Page 13 of 61
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
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.
In line with the previous assumption POL 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 S70 and S75 components,
functional and non-functional, will have been defined and agreed with 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 a number of test cycles as part of their System Validation and
Integration (SV&I) testing.
Fujitsu Services maintain a LINK configured Lexcel simulator during SV&I
and can execute adequate tests to fit with the stage 1 accreditation
requirements of LINK without disruption to their own testing.
Fujitsu Services will undertake sufficient regression testing to demonstrate
that the existing Horizon functionality will continue to work. For S75 testing
this includes S70 as part of the regression test.
Fujitsu Services and Prism will have completed their development and
testing prior to the final cycle of E2E testing by PO Ltd.
All suppliers and clients will work co-operatively to support the PO Ltd led
Integration and E2E testing phases including accreditation for EMV Retail
and Banking.
A stable E2E test environment is in place, with the S60, S70 and S75
(counter) code sets incorporated as appropriate.
The necessary resources (people, environments, test data, test tools and
test cards) are available from PO Ltd, Fujitsu Services, Prism, IBM and
other 3" parties to support the agreed testing schedule.
The planned test schedule for S70 can be achieved during 5.2 days of
E2E test cycles. These will start on a Monday and the final transactions
will be undertaken on the following Saturday morning (08:00 to 09:30) to
ensure that weekend transactions are included in the test cycle. The rigs
will then be accelerated to roll forward to produce the required reports.
They will be released for a rig reset by close of play on the Sunday.
Checking of outputs will continue into the second week during which the
rigs will be reset ready for the next cycle.
The planned test schedule for S75 can be achieved during 10.2 days of
E2E test cycles. These will start on a Monday, include Saturday morning
nativeFile Page 14 of 61
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
(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. 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.
¢ CBDB is out of scope for S70 and S75 E2E testing.
e All systems and hardware delivered into these POL led phases will be
EMV certified.
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.
3.5.1. RDS To NRDS -
The early stages of preparation for S70 E2E testing will see data provided from an
RDS test environment delivered to and loaded by those participating systems that
receive Type A reference data feeds from POL.
Throughout the preparation for each cycle of S70 E2E testing, data will be supplied
by NRDS and loaded to those participating systems that receive Type A reference
data feeds from POL.
$70 E2E testing will therefore demonstrate that systems can continue to operate by
using a mixture of RDS and NRDS created data.
Details of E2E testing of the NRDS are to be defined within the NRDS High Level
Test Plan
Changes keyed to the NRDS environment will also be keyed to RDS and Prism will
execute automated comparison routines to demonstrate that extracts from NRDS are
the same in terms of data content as they are from RDS.
The diagram and notes at Appendix E ( S70/S75 NRDS Migration and
Testing) explain the backups required to be taken by various systems and the
sequence of reference data keying that is to be performed
The testing will cover having the Horizon outlets operating on ref data
supplied from the current Ref Data then getting the next changes from NRDS
demonstrating that the transfer is seamless.
3.5.2. NBE To NBX
Testing during S70 will ensure that the enhancements to the Horizon counter
to support EMV Retail and EMV Banking have not impacted the Horizon to
NBE interface. The Fujitsu environment during S70 will only be capable of
routing banking transactions to either the NBE or an emulator at any point in
time. The NBE cannot accept EMV Banking transactions but the emulator
nativeFile Page 15 of 61
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
can. It is proposed that on day one of each cycle of S70 E2E, banking
transactions are routed via the NBE and via the emulator on all subsequent
days.
The table below shows how transactions for various institutions will move
through the S70 E2E Test cycles from NBE to NBX (NBX is enhanced NB
emulator at S70) and from Non-EMV to EMV.
BANKING MIGRATION (S70)
a CT
ay IOay5" Joay
sien
7 fsx ——INEX
Ti Bak oan gear =e — re
LUNK= Bank of eand (0) [REX [Nex Jno]
‘Diher LINK Schemes (Magoand exe Te I
Cher LINK Schemes (CC) [hex [NBK Ine]
Ha gan ee)
ABLIICO) Tex INSK___INex__I
sgt
iBay't” AW NBE (ie Conirel Prod for lacking linked to any ofthe ast cces)
iy 2 Ui an oie ed
Card Account roves to NEX fom ab
LINK (Bani: ef tend) (EMV) enadl
Day 3) Card Account (EM) enabled st el but one ts
iBay A Gard Aen ERA or ales eran fal es
Testing during S75 will prove the NBX migration plan for the production
environment through use of the following:
e The creation in RDS/NRDS of three new Routing Gateways
* Subscription Groups to control the routing of transaction messages for
individual banking schemes
These reference data changes will also be applied for S70 and will be partially
proved by the make-up of DRS reports but the routing of banking messages
will not be fully proven until S75 and the existence of the NBXThe table below
shows how transactions for various institutions will move through the S75 E2E
Test cycles from NBE to NBX and from Non-EMV to EMV.
nativeFile Page 16 of 61
$70 \ S75 Release
POL00038881
POL00038881
Testing Plan
BANKING MIGRATION (S75)
[wed [tho JFa_,..[Sa_.[Sum,. [en ue ed faa
Day 3 ay lay 5 ay 8 ay? € [aya [ay 10 [ay it” Day 12 Joay 13
ard Account (Magee Ne NK NK BK Lea La
Cari Accovnt (CC Pot EY Nex [Ne — ae a
Ti Ban and age en wn _—_ NE eee rar
LUN Bank ofan (cc) Pict EMV JNEX—NGX—NBX Re NS Nex [Ne
Te ra CT
[Nex INBx Tex [Nox [nex nex
[hex he he re
INBK__INBK TReX_ INK Inox [ne
Bayi
ay
Daya
Bayé
‘iT ie Conia Prats or Baring inkodo any afte tast cee)
ie arta eat Be ‘aoc Yor na i
Card Accu routed to NEX ton all est cfces fornonice
“LINK (Banko ela) (EMV) onablee at all ul ore at ofice
(Other LINK Schemes reuted to NEN hem all est offezs for rar iCC
Catd Account (ENV) enabled 3 4 but ene test ofc
LINK (Bank of rela) (EMY) enablec at remaining test of
(er LINK Schemes (EMY) onailes al all's! fone,
‘ABL routed to NEX fom all test ofces far nowiCC
ABL EM) enabled at ol test afore,
Gard Aczount EROA enabled remaining test ofice,
nativeFile
Page 17 of 61
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
4. Testing approach
4.1. Overview
The S70 and S75 releases are 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 card account,
e Review Interface scripts between the two supplier domains
e Support set — up of test environments
e Support or coordinate the provision of required Ref Data
e Support where appropriate the tests
e Review the test results including any faults
4.5. Certification or Accreditation Testing
PO Ltd will coordinate supported by Suppliers the preparation and execution
of scripts to achieve certification or accreditation.
e Review and agree Certification / Accreditation scripts
e Support or coordinate set — up of test environments
nativeFile Page 18 of 61
$70 \ S75 Release Testing Plan
e Support or coordinate the provision of required Ref Data
e Support or execute where appropriate the tests
e Provide required evidence e.g. counter receipts
e Review the test results including any faults
4.6. 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 including carrying out some E2E
test transactions to confirm the readiness to enter the PO Ltd E2E
functional testing cycles.
4.7. 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” 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 the changes to current systems and the
introduction of new systems has not impacted upon the businesses operation
including E2E financial aspects (accounting, reconciliation, settlement,
remuneration) have been and can maintained during live operation. 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 19 of 61
POL00038881
POL00038881
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
5. POLTD Test organisation
Testing of the S70 and S75 releases will flexibly utilise the appropriate
resources from within the PO Ltd Release test team. This team are also
preparing for PO Ltd testing of the S60, and S80 releases. The execution of
$75 which will commence immediately after the PO Ltd S70 testing has
completed and they are also concurrently supporting the internal testing by
suppliers of these other releases. Members of the team are also supporting
other smaller self contained testing phases e.g. card account releases.
This team consists of the core team members, supplemented by appropriate
non-core as required.
I I
oe
The core test team consists of:
e ARelease Test Manager.
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 A Test Support Domain, which will provide support by the provision of
test environments, test tools, test data and test cards. This domain also
includes the coverage of the New Reference Data system operated by
Prism.
nativeFile Page 20 of 61
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
Test Domains, who coordinate and manage testing across supplier/client
domains and covering a number of systems.
There are five domains which are:
o External Systems (Banking) Domain — covering Card Account
(EDS), NS&l, LINK, other LINK Fis, A&L and IBM. Also NatWest
Streamline (Debit Card)
o External Systems (Non-Banking) Domain — covering e-Pay,
DVLA, FRTS, AP Clients and SAPADS. The majority of these will
not be directly targeted within S70 other than general regression.
o Horizon Domain — covering Fujitsu Services.
o POLtd Backend Domain. — covering PO Ltd BAU areas (TP,
Finance and Network support) other PO Ltd systems (e.g.
NRDS,SAPFIN, TIP, CBDB, PO Ltd MI)
The non-core 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).
BAU resources appropriate to the release (e.g. RDS, NRDS, TIP, TP,
Network Support, Ml).
Prism resources (e.g. who support TestDirector).
Testing resources will be used flexibly to deliver both Non Functional and
business testing activities for S70 whilst maintaining the required progress on
other releases.
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:
Assist in the project initiation for S70 and S75.
Develop and maintain the S70 and S75 Release Test Plans and test
schedules.
Provide testing input to the S70 and S75 release plan.
Provide test / reqts coverage information to the design authority in support
of the release authorisation process.
Sign-off the completion of S70 and S75 testing.
Manage S70 and S75 testing issues through to resolution.
Provide risk analysis and manage any risks associated with testing the
release.
Provide a contact point for testing issues.
Provide input to the development of S70 and S75 acceptance criteria.
nativeFile Page 21 of 61
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
e Organise the resources for the team.
e Liase with the different suppliers to maintain the relationship and agree the
environment requirements for S70 and S75 testing.
e Assign, schedule and manage the day to day activities of the S70 and S75
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 S70 and S75. 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 S70 and S75 Release Test
Plans.
e Provide input to the development of S70 and S75 acceptance criteria.
e Develop and maintain the S70 and S75 testing plans for the Non
Functional test phases.
e Sign-off the completion of S70 and S75 Non Functional testing.
e Manage S70 and S75 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.
nativeFile Page 22 of 61
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
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.
e 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 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 EMV Retail
o EMV Banking
o Transition from RDS to NRDS
o Any other changes to functionality being introduced by Fujitsu
Services as part of S70 or S75 (e.g. CRs, fixes for previous
releases)
e Manage the co-ordination of the interface testing (DIT phase) of all
interfaces where the Horizon Test Manager is identified as the primary
owner of that interface (see Appendix B).
« Provide liaison between the external / PO Ltd domains and Horizon for all
interfaces identified at Appendix B, where the Horizon Test Manager is
identified as the secondary owner.
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 at the S70 and S75
releases, including:
o Cash Account integrity.
nativeFile Page 23 of 61
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
o EPOSS transactions.
o AP transactions (including barcode, magnetic stripe and
SMART).
o Banking transactions.
o Debit Card transactions.
o New S60 functionality at S70 and new S70 functionality at S75
e Manage the development of counter test scripts to support the testing of
any new non-counter functionality for S70 and S75 (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 S70 and S75 Test
Plans.
e Team lead both the core and non-core Horizon testers throughout the
preparation and execution of the S70 and S75 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.
e 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 the Horizon testing
domain.
e Support the Release Test Manager in obtaining additional resource 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 counter test
scripts. They will also deputise as the Horizon test manager when required.
The responsibilities of this role include:
e Actas the author for test scripts to test the new counter functionality in
relation to:
o EMV Retail
o EMV Banking
nativeFile Page 24 of 61
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
o Any other changes to functionality being introduced by Fujitsu
Services as part of S70 or S75 (e.g. CRs, fixes for previous
releases)
¢ 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 S70 and S75 E2E test plans.
e Maintain the script schedules (TestDirector test sets) throughout S70 and
S75 testing.
e Execute test scripts.
e Support integration test execution.
e Provide testing expertise and training to the non-core 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 S70 and S75 E2E testing.
e Executing testing scripts.
e Completing status logs.
e Collecting and collating test results.
« Document defects.
e Re-testing fixes and confirm successful completion.
5.1.6. PO Ltd Domain Test Manager
Reporting to the Release Test Manager, the PO Ltd Domain Test Manager
will be responsible for the creation, maintenance and execution of PO Ltd test
scripts, 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 the PO Ltd Test Manager.
nativeFile Page 25 of 61
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
Provide liaison between the external/Horizon domains and PO Ltd for all
interfaces identified at Appendix B, where the PO Ltd Test Manager is
identified as the secondary owner.
Gather test requirements for the S70 and S75 releases from all impacted
PO Ltd areas including:
o Transaction Processing (including OPTIP).
o Audit and Security.
o Finance.
o Network Support (NBSC).
Assist in the development of testable acceptance criteria for any functional
and non-functional requirements within the PO Ltd domain.
Act as the author for test scripts and obtain sign off from the relevant PO
Ltd areas (as detailed above).
Liaise with the PO Ltd BAU areas to identify and obtain the required
resources for test preparation/execution.
Execute test scripts.
Co-ordinate the scheduling/planning of tests into cycles and test days with
the relevant PO Ltd teams.
Complete status reports for the PO Ltd domain.
Collect and collate test results.
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 and issue management between the third party
suppliers and PO Ltd personnel for testing activities.
5.1.7. External Systems (Banking)
Reporting to the Release Test Manager, the External Systems (Banking) will
be responsible for:
Provide the liaison between the PO Ltd and Horizon domains to all
External Systems (Banking) domains suppliers involved in a release.
These are:
© IBM (NBE)
o LINK
o NS&l
o Other LINK Fl’s
o Direct Fl’s (A&L and/or card account)
o NatWest Streamline
nativeFile Page 26 of 61
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
e Gather the business and client/supplier test requirements for each of the
systems detailed above.
e Manage the co-ordination of the interface testing (DIT phase) of all
interfaces where the External Systems (Banking) is identified as the
primary owner of that interface at Appendix B.
e Provide liaison between the Horizon/PO Ltd domains and External
Systems for all interfaces identified at Appendix B, where the External
Systems (Banking) is identified as the secondary owner.
e Assist in the development of testable acceptance criteria for functional and
non-functional requirements for each supplier.
e Manage the development of the 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 S70 and S75
test plans.
e Executing test scripts as required.
e Co-ordinating the tests with the relevant supplier teams in these domains.
¢ Completing status reports for the External Systems (Banking) 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.
¢ 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 the 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 banking domains.
5.1.8. External Systems (Non-Banking)
Reporting to the Release Test Manager, the External Systems (Non-Banking)
domain will be responsible for:
e Provide the liaison between the PO Ltd and Horizon domains to all
External Systems (Non-Banking) domains involved in a Release.
o AP- Clients — if applicable
o DVLA - if applicable
o e-Pay (ETU) — if applicable
o First Rate Transaction Services (Bureau de Change) — if applicable
nativeFile Page 27 of 61
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
o SAPADS - if applicable
e Gather the business and client/supplier test requirements for each of the
systems detailed above.
e Manage the co-ordination of the interface testing (DIT phase) of all
interfaces where the External Systems (Non-Banking) is identified as the
primary owner of that interface at Appendix B
e Provide liaison between the Horizon/PO Ltd domains and External
Systems for all interfaces identified at Appendix B, where the External
Systems (Non-Banking) is identified as the secondary owner.
e Assist in the development of testable acceptance criteria for functional and
non-functional requirements for each supplier.
e Manage the development of the test scripts for this strand.
e Work with other members of the testing team to co-ordinate the
scheduling of the test into cycles and test days within the S70 and S75
test plans.
e Execute test scripts as required.
e Co-ordinating the tests with the relevant supplier teams in this strand.
e Complete status reports for the External Systems (Non-Banking) domain.
¢ Collect and collate test results.
e Prepare 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 the 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 non-banking domains.
5.1.9. Domain Test Analysts
Reporting to the Domain Test Manager, the domain test analysts will be
responsible for the creation, maintenance and execution of the test scripts for
their domain. They will also deputise as their Domain test manager as and
when required.
The responsibilities of this role include:
nativeFile Page 28 of 61
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
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.
¢ Gather test requirements for the S70 and S75 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 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.10. Test Support
Reporting to the Release Test Manager, the Test Support will be responsible
for the co-ordination and maintenance of all test environments and test tools.
They will also own the NRDS as a system and assure its supplier internal
testing phases prior to entry into the PO Ltd led phases.
This will 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:
¢ Specification of all reference data required to support S70 and S75
testing.
e Co-ordination of delivery of non-RDS 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.
e Support the Horizon Test Manager throughout the test phases.
nativeFile Page 29 of 61
POL00038881
POL00038881
$70 \ S75 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 Test Support
Domain. It will then be 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 S70 and S75 testing environments,
including the tools, simulators and test data required for day-to-day operation
of the test environment.
6.1. S70 and S75 test environment
A schematic of the E2E test environment required to support all aspects of
testing the S70 release is presented in Appendix B. It consists of the following
components.
6.1.1. Horizon configuration
The Horizon E2E test rig at Fujitsu Services consists of the following
elements, some will be in place at S70 and some at S75
e 12 Counter terminals in the Post Office test room at Feltham (room F1) —
as this has existing connectivity to the Post Office network. (S70 & S75)
e Amixture of single, dual and multi-counter office configurations, consisting
of the 12 counter terminals. (S70 & S75)
e Network monitoring/message spy software to assist in incident
investigation. (S70 & S75)
« Connections to the NBE and e-Pay.
e Connection to Streamline for debit card testing (EMV retail)
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
¢ Connection to an enhanced NB emulator. (S70 Only)
e Transaction Enquiry Service (TES) (S75 Only)
¢ Connection to the PO Ltd test gateways for:
o Delivery of TIP transaction, cash account and client summary files.
(S70 & S75)
o Receipt of PO Ltd reference data from NRDS. (S70 & S75)
nativeFile Page 30 of 61
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
o Delivery of end of day files from the NBE to the NBE PO Ltd
gateway or Fujitsu Services. (S70 & S75)
o Delivery of the spot rate and margin files from FRTS via the
FTMS/TIP gateway and the EDG. (S70 & S75)
o Delivery of the daily Trx file for FRTS via the FTMS/TIP gateway.
(S70 & S75)
© Delivery of the control totals file for PO Ltd to the PO Ltd gateway
(S70 & S75)
o Delivery of DRS reconciliation/reports. (S70 & S75)
o Delivery of MIS reports. (S70 & S75)
o Delivery of NBX Reports (S75 Only)
e Connection to EBT which is part of the card account test system (S75
Only)
e Connection to LINK (S75 Only)
e Connection to Alliance & Leicester test system (S75 Only)
6.1.2. Post Office configuration (provided by Prism)
e Two test gateways to support the file transfers from Horizon (inc. NBX),
NBE and DVLA. (S70 & S75)
e Current Reference Data System to provide test reference data. (S70 Only)
e New Reference Data System to provide test reference data. (S70 & S75)
e New POL Management Information System (S70 & S75)
e Delivery of reconciliation and MIS reports. (S70 & S75)
« Connections to the Electronic Data Gateway. (S70 & S75)
¢ OPTIP Test Environment
6.1.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 accreditation
An ISDN connection is required for Payment File (and EMIS File if
necessary).
6.1.4. NBE configuration
e Connection to Horizon to support interface and integration testing: (S70 &
S75)
nativeFile Page 31 of 61
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
e Connection to LINK (S75 Only)
e Connection to card account EBT (S75 Only)
e Connection to Alliance & Leicester (S75 Only)
e Connection to LINK, card account and Alliance & Leicester simulators
(S70 Only)
e Data Navigator access. (S70 & S75)
e Connect: Direct service to send end of day files to the PO Ltd test
gateway, and receive reference data from PO Ltd RDS. (S70 & S75)
¢ Connect: Direct service to receive files from LINK. (S75 Only)
e FTMS connection to Horizon to send files to Horizon. (S70 & S75)
6.1.5. LINK configuration (S75 Only)
e Simultaneous but separate connections to NBE and NBX for LISS
interface
¢ Connection to NBX for LISS interface
e Connection to a minimum of two EMV compliant Lexcel Simulators to
simulate two issuers for E2E and accreditation testing
¢ ConnectDirect for transmission of LREC files to NBE
¢ ConnectDirect for transmission of LREC files to NBX
6.1.6. Alliance & Leicester configuration (S75 Only)
No contact with Alliance & Leicester at the time of writing but it is expected
that A&L test systems will connect to the NBE and NBX during S75
6.1.7. First Rate configuration (not required for either S70 or S75 release)
Test system connected to the PO Ltd gateway to send rate (spot and margin
rates ) data and receive daily transaction files.
6.1.8. NS&I configuration (not required for either S70 or S75 release)
e NS&l test system connected to the LINK ATMOS system for LINK
certification for NS&l and NS&I free-for-all testing.
e Asystem to receive APS files from Horizon containing initial transaction
data
6.1.9. e-Pay configuration (S70 & S75)
A test system to receive ETU requests and provide the appropriate
responses. This test system is also required to generate daily transaction
summary for reconciliation purposes.
nativeFile Page 32 of 61
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
6.1.10. card account configuration (S75 Only)
An EBT test system connected to the NBE and subsequently NBX to support
migration and card account testing. It is expected that for the S70 release
regression card account transactions will be handled within the Fujitsu domain
using the NB emulator.
6.2. 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.
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.2.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
testing, which should exercise all possible response / outcome code
combinations. To test EMV Banking via LINK, scripts (text files that
determine how a card will respond to commands from the Pin Pad) will be
provided by LINK and loaded onto ICC Solutions EMV cards
e Debit Cards — A set of magswipe debit and credit cards, again exercising
all response code variations for use when interfacing with the Streamline
test system. To test EMV Retail, which will be provided by Streamline,
VISA and Mastercard and loaded onto ICC Solutions EMV cards
e AP Tokens — AP tokens of various types (magnetic card, smart and
barcode) for regression purposes.
¢ OBCS Barcodes — For regression testing purposes.
¢ card account Card Receipt barcodes — As per AP tokens.
e PIN & ETU Cards — A set of PIN and ETU cards
e Smartpost labels
6.2.2. System test data
Test data required by supporting systems will be specified in advance, and
published within the “S70/S75 Release E2E Test Reference Data
nativeFile Page 33 of 61
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
Specification’, this will allow the creation of test scenarios and detailed test
planning.
POL RDS reference data — At a given point in time, a backup of the live
reference data position will be 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 at this stage)
o Additional EFTPoS schemes to support Credit Card
o Additional Retail and Banking operations, items, cards,
bankcard elements, etc.
POL NRDS reference data will be populated with that contained within the
test RDS after the above data has been created. The NRDS system will
then be used for two purposes:
o Input and extraction of data to prove the tests detailed within the
NRDS HLTP
o Provide the data that is specific to each cycle of S70 and S75
E2E, e.g. non-core links to EMV banking control items, etc.
Type C reference data to support Identification of cash and near cash
items for SAP FIN.
MAILS Tariff Data — usually taken from the latest live version available.
MID / TID Data -for Debit Card and ETU transactions.
Response Data — to be loaded into the
= Simulators at the NBE (for S70)
= NB emulator within Fujitsu Domain (for S70)
= Simulators within LINK Domain (for S75)
= Streamline Test Sytem (for both S70 & S75)
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
either NBE or NBX. This data will be specified for both S70 and S75.
Although it will only control the flow of banking messages during S75, it’s
effect on DRS reports will be seen during both S70 and S75 E2E phases.
6.3. Testing tools
TestDirector will be used to manage the following elements of testing:
nativeFile Page 34 of 61
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
e Requirements — a hierarchy of requirements which are then used as a
basis for the creation of test scenarios.
e Test Planning — a repository for the test scenarios generated to prove
requirements and system functionality.
e Test Execution — groups of test scenarios, planned into logical test sets,
and executed in a controlled manner.
e Incident Management — tracking the lifecycle of identified incidents,
through identification, action, retest and resolution.
e Test Reporting - management information on each of the above
elements, in graph and tabular form.
These Testing Procedures are covered in greater detail in the next section of
this document.
nativeFile Page 35 of 61
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
7. Testing Procedures
7.1, Requirements
The requirements of each project within a release are included within a
catalogue of business requirements (Conceptual Designs) which will be used
as a basis for testing and system acceptance. These requirements will be
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 requirement 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 which will
be based on the solution achieving the acceptance criteria/methods defined
within the Conceptual Designs (CD). These acceptance methods will be used
as the basis for determining the requirements which 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 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, who are responsible for ensuring that the scenarios
cover the requirement/acceptance criteria satisfactorily and sign off the Test
Plan. Following development of the HLTP, lower level tests are then
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 S70 & S75.
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
number of folders/strands covering regression testing of the E2E solution
nativeFile Page 36 of 61
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
which are then supported by a folder for each project within the S70 release,
which would then contain appropriate tests to cover functionality for that area.
For S70 and S75, the test plan tree could look something like this.
LA (S60)
16 ONCH (S60)
17 PAF (S80)
18 Smart Post ($60)
19 Debit Cara (S70)
20/NBS (S70)
23 NBE
2) Non_eMiv
21 NBS (S70_75)
I_75) - Balance Enquiry
Cash Deposit
- Cash Withdrawal
- Cash Withdrawal With Balance
~ Change PIN
= Cheque Deposit
= Withalran Litt
The example shows that 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 can be Passed, Not
Run or Failed, Not completed, in which case, an incident may be raised (see
below).
7.5. Incident management
TestDirector provides a section to manage incidents as they are raised.
Incidents will be classified and managed in accordance with the PO Ltd Test
Incident Management Process [2]. This document which is one of the detailed
documents within the PO Ltd Testing document hierarchy and sits under the
Test Plan. It will be reissued to all parties involved in the S70 and S75
releases. This section provides a brief overview of the documents coverage.
e Incident management approach
nativeFile Page 37 of 61
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
* Incident classification
e Incident management process
e Fix management
e Incident management tool
7.5.1. Incident management approach
Every test campaign is focused on finding incidents. Given that the goal is
to fix them, monitoring the status of incidents is critical to the successful
and timely release of a system. Incidents must be fixed and then the
service and associated systems/processes must be tested such that both
the incidents have been fixed and that the fix implemented has not
resulted in the introduction of any new incidents elsewhere in the service.
The process of finding, reporting and tracking the incidents found during
the PO Ltd led testing will be monitored carefully.
The PO Ltd internal process will use the web-based tool, TestDirector.
Authorised PO Ltd users will be able to see the status of the outstanding
incidents. These can be “sliced and diced” in the manner required by the
person viewing the incidents, provided that they are sufficiently skilled in
the use of the incident management tool. With the selected test tool, there
are standard reports that can be produced to support management
reporting and analysis. These reports can be customised, and additional
reports generated, as required. In this way, managers can view high-level
summaries of which incidents have been identified and/or fixed and can
then drill-down for more detail as required.
In order that this can be achieved, it is essential that the details of each
incident are carefully recorded and classified, and that the status of the
incident is maintained throughout its lifecycle. Details of how incidents will be
classified and the typical lifecycle of an incident are described in the following
sections.
Incidents are linked to test scenarios, so that it is possible to identify which
test to rerun once the defect has been resolved.
Incidents will be categorised by test phase and then major component, and
management information (in graph and table form) will be available to aid
discussion between domains.
7.5.2. Incident classification
There are many characteristics associated with every incident found
during testing. These include at /east following details that must always be
held within the incident management system (see Appendix B for example
Test Director input screen):
nativeFile Page 38 of 61
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
* The date the incident was found
e A description of the incident
e Details regarding how to reproduce the incident (or a clear statement
that the incident cannot be reproduced)
e The version of the system or process in which the incident was
found (and where appropriate, details of any environmental
conditions)
e The name of the person who detected the incident
e Reference to the test case (or Acceptance Test if appropriate)
e Testing phase in which the incident was found
e The severity of the incident [ratified by the incident review meeting]:
Severity _I 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.
Low A minor incident, which might not be noticed by all users, as:
nativeFile Page 39 of 61
$70 \ S75 Release
Testing Plan
POL00038881
POL00038881
Severity
Description
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 th
e following additional information is also required. This
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. The identification of Supplier raised incidents will be the
combination of Supplier Organisation and their unique reference
number. These two fields must be used in all communication regarding
supplier-originated incidents so that cross-reference is possible.
This number will be entered into the “Other Ref.” field in TestDirector as
a single entry (i.e. IBM 001)
This combination of Supplier and Supplier Reference Number
must be entered in the “Other Ref.” Field in TestDirector so that it
is interlocked with the PO LTD incident tracking.
nativeFile
Page 40 of 61
$70 \ S75 Release
POL00038881
POL00038881
Testing Plan
e Responsibility for fixing the incident. 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]:
e The name of the organisation assigned to investigate and resolve
the incident [ratified by the incident review meeting]:
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
nativeFile Page 41 of 61
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
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 ;
is fixed Owner/Domain Co-ordinator
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 42 of 61
POL00038881
POL00038881
$70 \ S75 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)
Y ¥ , ¥
status: Rejected status: Open status: Deferred
Y
Incident fixed
status: Fixed
y
Incident tested: fail
Test Fail status: Re-open
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 follow tightly
controlled processes.
e Each System Supplier will appoint a Version Control Representatives
to act as their central notification point through whom all
communications and approvals pass.
* Onentry into the PO Ltd Testing, the system suppliers will be
responsible for base lining 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.
e 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 on a “Pull” basis controlled by the PO Ltd Testing
Domain owner.
e Fixes or changes will be compiled into release packages.
nativeFile Page 43 of 61
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
e Oncompletion of a release package to match a release window, each
supplier will create a list of content for their package including all fixes
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 both 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
which is one of the detailed documents within the PO Ltd Testing
document hierarchy and sits under this Test Plan. It will be reissued to all
parties involved in the S70 and S75 releases. This section provides a brief
overview of the documents coverage.
During the last 3 major PO Ltd releases (BI3,S30 & S50) a 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 is well received and 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 S70 and S75 Releases, the intention is to again use Test Director
and it’s outputs 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 S70 and S75 testing and are
documented separately in appendix C.
nativeFile Page 44 of 61
POL00038881
POL00038881
$70 \ S75 Release Testing Plan
nativeFile Page 45 of 61
S70 Release
Testing Plan
8. Appendix A — Glossary of Terms & Abbreviations
AIS Application Interface Specification
APS Automated Payments System
A&L Alliance & Leicester
BI3 Banking Increment 3
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
HMIS Horizon Management Information System
LINK LINK banking network
LINK FI A financial institution connected via the LINK network
MID Merchant Identifier
NBA R1 Network Banking Automation — Release 1
NBE Network Banking Engine
NNDB National Network Data Base
NS&l National Savings & Investments
NSSC National Secure Stock Centre
PIN Personal Identification Number
PO Ltd Post Office Ltd.
nativeFile Page 46 of 61
POL00038881
POL00038881
S70 Release Testing Plan
RDS Reference Data System
SBS Siemens Business Services
SV&l System Validation and Integration Testing
Testing
TID Terminal Identifier
TIS Technical Interface Specification
nativeFile Page 47 of 61
POL00038881
POL00038881
POL00038881
POL00038881
S70 Release Testing Plan
9. Appendix B — $70 Interface Diagram & Matrix
EPAY
LINK A&l CA
sim Sim Sim Streamline
30 40 pat —T
NBE 18 16 !
NB Emulator a 2 4 7 8 22 SAP FIN 24
(at Fujitsu) arr I
i I LFS 33
° v i__w i POC ’ 38 SAP ADS.
DVLA Online a1, I DVLA] NB I ETU I DRS I DC Fs I TPS 20 if
Agent I Agent I Agent I Host I Agent A t Host
DVLA 1 gen 21 TIP '
1 APS Bdc 23 POL I
7 Agent HORIZON Agent I 24s Gateway I_ 5 I
AP Clients First Rate 28
APS TMS (Message Store) RDMG }:------27------~ “ee I
Host 9 I
: - NRDS i
I I PAF
30 DES/EDG 29 I i (QAS)
5 4 3
I POL MI
L LL *
Counters
nativeFile Page 48 of 61
POL00038881
POL00038881
S70 Release Testing Plan
S75 Interface Diagram & Matrix
Bank Bank
sim2f “7 “sim 4 EPAY
“43 LINK 395 {
i Streamline
aa] ABL fo I i
NBX : NBE 1816 I
45 a I I
CA 7 32 SAP FIN 34
38 I
4 a i LFs 33 I
° 1 ! L 35—-I SAP ADS
DVLA Online 31 v fovea I Reet’) eru I prs I pe I FS I tes 20
Agent Agent I Host I Agent Host
DVLA Agent Agent 2 TIP ,
APS Bdc 23 POL i
Agent HORIZON Agent Ig, Gateway I_ » I
AP Clients, First Rate I 28
APS TMS (Message Store) ROMC 27 — i
- Host ge Store) I ROME Fo — . I
. . - 26---- NRDS J
i j I PAF I
30 DES/EDG 29 I I I I (easy i
5 4 3 2 1 I
I I I 12 -nenn enna POL MI
Counters
nativeFile
Page 49 of 61
S70 Release
POL00038881
POL00038881
Testing Plan
Description
Comment
Primary
Owner
Secondary Owner
1 Counter Campus EPOSS Existing feed, with Fujitsu Horizon Test Manager /
(TPS) Transaction additional Bureau Services Banking Strand Manager /
stream products. Will include Non Banking Strand Manager
DVLA and NS&l and
ETU confirmation
transactions
2. Counter Campus APS Transaetion PO Ltdled with EPOSS Fujitsu Horizon Test Manager /
(APS) stream stream, will include Services Banking Strand Manager /
DVLA transactions with Non Banking Strand Manager
additional data, and
NS&d Initial transaction
3 Counter Campus Debit Card Online Regression test of Fujitsu Horizon Test Manager / Non
(Dc) Transaction existing interface Services Banking Strand Manager
stream
4. Counter Campus NB Online Enhanced with Fujitsu Horizon Test Manager /
(NB) Transaction additional Cheque Services Banking Strand Manager
stream Deposit transaction
type, and manual
method of capture for
LINK
5 Counter Campus ETU Online E Top Up / PIN Sales Fujitsu Horizon Test Manager / Non
(ETU) Transaction and Refunds Services Banking Strand Manager
stream
6. Campus AP APS Client Files Regression test of Fujitsu Non Banking Strand Manager
Clients existing interface Services
7 Campus DVLA APS Client Files Existing interface Fujitsu Non Banking Strand Manager
enhanced at $70 with Services
additional data
8. Previous Please
Link Ignore
Page 50 of 61
S70 Release
POL00038881
POL00038881
Testing Plan
Description Comment Primary Secondary Owner
Owner
9 Campus NBE Horizon to NBE Requests and Fujitsu Banking Strand Manager
Emulator Emulator (NBX at Authorisations Emulator Services
(NBX at S75) at S70 to cater for no
$75) NBX
10. Previous Please
Link Ignore
11 Previous Please
Link Ignore
12. Previous Please
Link Ignore
13. Previous Please
Link Ignore
14. NBE DRS NBE Emulator to Fujitsu Banking Strand Manager
Emulator DRS reconciliation Services
at S70 stream (Emulator
(NBX at replaced by NBX
S75) at S75)
15. Campus EPAY Campus to EPAY Regression test of Fujitsu Non Banking Strand Manager
Online ETU existing interface Services
Transaction
stream
16. EPAY DRS Daily Transaction Regression test of Fujitsu Non Banking Strand Manager
File to DRS existing interface Services
17. Streamline DRS EMIS Files to DRS Regression test of Fujitsu Non Banking Strand Manager
existing interface Services
18. Campus Streamli Campus to Regression test of Fujitsu Non Banking Strand Manager
ne Streamline Online existing interface Services
OC Interface
Page 51 of 61
S70 Release
POL00038881
POL00038881
Testing Plan
Description
Comment
Primary
Owner
Secondary Owner
19. Campus Streamli Payment Files to Regression test of Fujitsu Non Banking Strand Manager
ne Streamline existing interface Services
20. Campus PO Ltd TIP Files Transaction, Cash Fujitsu PO Ltd Test Manager
Gateway Account and Client Services
Transaction Files
21 PO Ltd TIP TIP Files as 20. Prism PO Ltd Test Manager
Gateway
22. First Rate PO Ltd Exchange Rate Regression test of FRTS FRTS / Non Banking Strand
Gateway and Margin Data existing interface Manager
from First Rate
23. PO Ltd Campus Exchange Rate Regression test of Prism PO Ltd Test Manager / Non
Gateway and Margin Data to existing interface Banking Strand Manager
Horizon
24. Campus PO Ltd Bureau Regression test of Fujitsu PO Ltd Test Manager / Non
Gateway Transaction Data existing interface Services Banking Strand Manager
to PO Ltd
25. PO Ltd First Bureau Regression test of Prism PO Ltd Test Manager / Non
Gateway Rate Transaction Data existing interface Banking Strand Manager
to First Rate
26 RDS PO Ltd Reference Data to Prism PO Ltd Test Manager
Gateway PO Ltd Gateway
27. PO Ltd RDMC Reference Data to Prism PO Ltd Test Manager
Gateway Horizon RDMC.
28. RDS TIP Reference Data to New Item, TRX Mode Prism PO Ltd Test Manager
TIP and Cash Account
mappings
29. Campus DES/ED Data for external New Interface at S60 Fujitsu Prism
G clients to Services
exchange server
Page 52 of 61
S70 Release
POL00038881
POL00038881
Testing Plan
Description Comment Primary Secondary Owner
Owner
30, DES/EDG AP Data from New Interface at S60 Prism PO Ltd Test Manager
Clients exchange server to
external clients
31. Campus DVLA Interactive DVLA New Interface at S60 Fujitsu DVLA
Online MOT verification Services
and price requests
32 Campus SAP Cash and near New Interface at S60 Fujitsu Prism
Finance cash movements Services
33, Campus PO Ltd LFS Interface Enhanced interface at Fujitsu Prism
Gateway $60 to include Services
generated cash figure
(ONCH)
34 SAP ADS SAP Movement of cash New Interface at S60 Prism Prism
Finance values between
cash centres to
SAP FIN
35, SAP ADS PO Ltd LFS Interface Enhanced interface at Prism Prism
Gateway $60 to include POUCH
contents
36. Campus Counter Parameters from New Interface at S60 Fujitsu Horizon Test Manager /
and address fields Services Banking Strand Manager /
to counter for PAF Non Banking Strand Manager
lookups
37 NBE DRS NBE to DRS Regression test of 1BM Banking Strand Manager
reconciliation existing interface
stream
38. Banking NBE Horizon to NBE Regression test of Fujitsu Banking Strand Manager
Agent existing interface Services
Page 53 of 61
S70 Release
POL00038881
POL00038881
Testing Plan
Description
Comment
Primary
Owner
Secondary Owner
39, NBE LINK NBE to LINK Use of simulator to IBM Banking Strand Manager
Sim at cater for absence of
S70 and LINK from E2E
LINK at environment during S70
$75
40. NBE A&L Sim NBE to A&L Use of simulator to IBM Banking Strand Manager
at S70 cater for absence of
and A&L A&L from E2E
at S75 environment during S70
4 NBE card NBE to card Use of simulator to IBM Banking Strand Manager
account account cater for absence of
Sim at card account from E2E
$70 and environment during S70
card
account
at S75
42. PO Ltd PO Ltd TIP Files & NRDS Major components of Prism POL Backend Domain Owner
Gateway Mi Files data inbound to POL MI
43. NBX LINK Horizon to LINK New Interface at S75 Fujitsu Banking Strand Manager
Services
44 NBX Alliance Horizon to Alliance New Interface at S75 Fujitsu Banking Strand Manager
& & Leicester Services
Leicester
45. NBX card Horizon to card New Interface at S75 Fujitsu Banking Strand Manager
account account Services
46. LINK Lexcel Lexcel Simulator in LINK Banking Strand Manager
Sim 1 LINK domain
acting as
Authorising bank
Page 54 of 61
S70 Release
Lexcel
Sim 2
Description
Lexcel Simulator in
LINK domain
acting as
Authorising bank
Comment
POL00038881
POL00038881
Testing Plan
Primary Secondary Owner
Owner
Banking Strand Manager
nativeFile
Page 55 of 61
S70 Release
POL00038881
POL00038881
Testing Plan
10. Appendix C - Test Plan - Key Milestones
$70 and S75 Business Change Processes and Testing End of April 2004 Business Change
Requirements Agreed
$70 and S75 High Level Test Plans Completed End of May 2004 PO LTD Test Team
S70 Interface Validation (pre DIT) 14/06/04 25/06/04 Fujitsu
$70 Direct Interface Testing 19/07/04 30/07/04 Fujitsu
S70 Fujitsu S, V & I Cycle 4 16/08/04 27/08/04 Fujitsu
$70 Integration Testing 19/07/04 30/07/04 PO LTD Test Team
$70 E2E Testing Cycle I 09/08/04 13/08/04 PO LTD Test Team
S70 E2E Testing Cycle 2 23/08/04 27/08/04 PO LTD Test Team
S70 E2E Testing Cycle 3 06/09/04 10/09/04 PO LTD Test Team
S75 Interface Validation (pre DIT) 31/08/04 10/09/04 Fujitsu
$75 Direct Interface Testing 14/09/04 17/09/04 Fujitsu
$75 Fujitsu S, V & I Cycle 3 11/10/04 22/10/04 Fujitsu
$75 Integration Testing 14/09/04 17/09/04 PO LTD Test Team
$75 E2E Testing Cycle 1 27/09/04 08/10/04 PO LTD Test Team
S75 E2E Testing Cycle 2 18/10/04 29/10/04 PO LTD Test Team
nativeFile
Page 56 of 61
S70 Release
POL00038881
POL00038881
Testing Plan
te
S75 E2E Testing Cycle 3
08/11/04
19/11/04
PO LTD Test Team
nativeFile
Page 57 of 61
POL00038881
POL00038881
S70 Release Testing Plan
11. Appendix D - Schedules
$70 E2E Testing Cycle
sf2aIsI4als 6}7I8]9I10] 14]12}13] 14/15 116] 17I18]19]20I 12122] 23] 24] 25I /26I27] 28] 29] 30] '31I32}33]34] 35] 36I37I38I39]40
inesraton ee Eee, oe)
Connectivity
Reset Contingency
n
e
*
o
System Rollover oRt Re
Mon Tues I IWed Thurs I I Fri Sat Sun
Cash Account Counter Activity
Week End ‘Completed (Sat)
eFile Page 58 of 61
POL00038881
POL00038881
S70 Release Testing Plan
S75 E2E Testing Cycle
13} 14 15} 16 17] 1] 19]20}21 29}23 }24] 25] 26]27I 28}29]30}01 o2}o3} 04}0s}o6]o7}o8 oo] 10} 1112] 13]14]15]16]17 18] 19} 20]21]22 23}24 }25I26 }27]28] 29]0}31 Jo1]02]03}04] 0s}06] 07] oa]09I 10]11}12}13] 14] 15] 16] 17/18] 19}20]21}22}23 I24}25 I26I
sfalafals 6{7I 8] ohio +1] 12/13] 14h15I 16} 17}13]19}20] I J2x}22] 23] 24}29} 26}27] 28} 2010] 's1}32}33]34) 39) 36] 37I38]30]40 }41]42}43}44]45) I Jaa] 47/48] 49]59} [51]52]53}54]55}
Cont
1 2 3 4 8 6 7
[I System Rollover 8 ® 10 1" 12 Ri R2
Mon I I Tues I Jwed Thus} ] Fa I I sat sun I] mon I I Tues I Iwee Thurs] } Fn I I sat Sun
nativeFile Page 59 of 61
S70 Release
POL00038881
POL00038881
Testing Plan
12. Appendix E - S70/S75 NRDS Migration and Testing
kK
milestone 26/4/04
01/0604 = = 1410604 = = — — — — — 28/06/04
dates
eccccoescccc ~
Live Export for FS t Prism \
RDS and OPT I prism to Key !
(using Scripts) I their own broad 47 !
Fujitsu Required I Sample changes \ i}
S70 Changes I raa--) I
I Backup I I
L Test I I
Test Backup P>77Towoomoemeneene ony eeeeeeeneeeee =p} RDS I i
RDS Migration & I
A output file - — ey ee ee ee ee
10 Proving Broad samiple E2E
Export of Changes eg. Products Cycle 4
E2E Data (Outlets, FAD etc) Data
S75 Restore Point } }
Test Back uP
NRDS EE Data
MI
Security CBDB
Settings -
"4 port
(user ID's) ‘Changes only’
(Outlets etc) NRDS
& HLTP
Data Keyed
into CBDB
for additional
outlets.
nativeFile
Page 60 of 61
S70 Release
POL00038881
POL00038881
Testing Plan
$ 70/S 75 NRDS Testing Diagram - Notes
Point 1 - All systems are to be backed up on between 23/4/04 - 26/4/04. The interfacing systems are RDS (23/4/04), TIP (24/04/04), CBDB (25/04/
04), ES FS and WRDS are to be confirmed. (A file needs to be taken on the Friday night -23/4/04, and sent to FS for them to load, once loaded
then back up).
Point 2 - These are all key backup points that need to be taken at the appropriate times. The back points that are asterisked are also contingency
sites for NRDS.
There are specific changes for $70 that are required for FS and these need to be built into RDS after the initial back up has been taken.
Point 3 - Prism need to do a comparison of the files between RDS and NRDS. Prism will query both Databases to check on Record count validation
and the specification matching.
RDS should also prove exporting for FS and Optip (by using scripts) and NRDS needs to be tested against imported interfaces and Data NRDS will
also need to prove exporting through a migration and output file. The latest version will be the one carried forward to the S75 restore point, after
product changes and E2E Data have been input together with the HLTP requirements on testing. The export output to TIP will be taken on ‘st
June, stored and then loaded onto TIP early in July.
Point 4 - Prism to retain RDS and keep updated with Testing process and this will have product changes keyed in by Prism themselves. - To act as
contingency site - if required.
Point 5 - Key-in any date specific data for the end to end testing i.e Routing gateway links to migrate over will need to be input at this point ie. NBX
and EMV migration as an example. At the end of cycle 1, the preparation for the next cycle need to start back at the position - as of the 1/06/04.
Data must then be re keyed for cycle 2 and again for cycle 3. It should also be noted that Date progression may need to be manually overridden as
the default will always be 1st June, yet cycle E2E testing is progressing throughout July.
S70 is complete after following this process.
The S 75 E2E testing start point will be as the 14th June position database that will be used as the base and data needs to be entered as in point 5
for the three cycles until the end of S 75 testing.
N.B - All Back ups taken must all be synchronized.
nativeFile
Page 61 of 61