POL00439364
POL00439364
Network Banking
Automation
Debit Card Project
Testing Strategy (Version 0.5 — Draft)
ROLE NAME SIGNATURE DATE
Author Greg O’Connell
RI Test Manager Andrew Thompson
Supplier Manager Barry Forrest
Design Authority Manager _Torstein Godeseth
POL-BSFF-096-0001291
POL00439364
POL00439364
POL-BSFF-096-0001291_0001
POL00439364
POL00439364
Debit Card Project Draft Testing Strategy
1. Document control
1.1. Version history
0.1 13 September 2002 Initial issue for comment
02 20 September 2002 I Issued for I* informal review following comments from
Andrew Thompson, Barry Forest and Peter Jones 18/9/2
0.3 30 September 2002 I Comments from Andrew Thompson, Lee Farman,
Torstein Godeseth
0.4 22 October 2002 Incorporating $30 aspects and updates from a Debit
Card test planning review
0.5 25 October 2002 Incorporating updates from informal review by test
team and Barry Forrest
1.2. Change co-ordinator
Andrew Thompson, NBA RI Test Manager, Calthorpe House, London
Telephone:
1.3. Related documents
ia] POL High Level Testing Strategy 1.0 November 2001
PI Debit Card Service Requirements 1.1 (draft) I June 2002
Catalogue
3] Debit Card Requirements with Acceptance I None None
Criteria for each impacted system
[4] Compliancy Matrix TBA TBA
[5] POL Incident Management Procedures 14 September 2002
[6] VU/STR/0S2__ I Supplementary PTU Test Strategy for 0.5 (draft) I October 2002
Debit Card
7] Fujitsu Debit Card High Level Test Plan
Version 0.5 Page 3 of 23
POL-BSFF-096-0001291_0002
POL00439364
POL00439364
Debit Card Project Draft Testing Strategy
2. Contents
[TOC \o "1-3" \h \z]
Version 0.5 Page 4 of 23
POL-BSFF-096-0001291_0003
Debit Card Project Draft Testing Strategy
3. Executive summary
This document outlines the approach to be adopted by Post Office Ltd. for testing
Debit Card functionality as part of the $30 release of Horizon and the accreditation of
Horizon by Streamline. It is understood that the $30 release will include:
e Debit Card (including Streamline Accreditation)
e American date format
¢ Modulus 11 (stage 2 fix)
e MAILS enhancement (excluding any external interfaces)
© Remote key management
e Bug fixes for NBA R1 banking infrastructure (BI3) release
Post Office Ltd. testing will be based on witnessing supplier testing and executing
additional tests where necessary. Testing will be in four distinct test threads, namely:
e Supplier testing — witnessing of supplier testing at Fujitsu. This will involve
the agreement and execution of a witnessing plan, where we will witness tests
from Fujitsu’s High Level Test Plan during cycles 3, 4 & 5 of their Business
Integration Testing (BIT).
e Integration testing — testing the interfaces between systems in supplier
domains (e.g. Horizon to Streamline). This will be undertaken prior to E2E
testing to prove that messages and files are transferred in accordance with the
agreed AIS and TIS. It will also include a practice Streamline Accreditation.
e E2E testing — performing E2E functional testing across supplier domains (i.¢.
including Post Office Ltd, Horizon and Streamline systems and processes).
E2E testing will be undertaken with code from the end of the 3“ cycle of
Fujitsu’s BIT. E2E testing will be undertaken in a series of 5 days cycles with
the systems operating in real time (i.e. there will be no manipulation of dates
or times).
e Non-functional testing — witnessing and auditing of testing in the areas of
security (including remote key management), performance and disaster
recovery. This will be undertaken by witnessing Volume and Integrity (V&I)
testing at Fujitsu, and auditing evidence from Streamline.
Separate test plans will be produced for each test thread. For supplier and non-
functional testing, these will be witnessing plans. For E2E and integration testing, we
will produce test scenarios and scripts for each test thread.
Process walkthroughs will be conducted separately from the testing described in this
document. This will be undertaken by the Business Change team within the NBA RI
programme.
Version 0.5 Page 5 of 23
POL00439364
POL00439364
POL-BSFF-096-0001291_0004
Debit Card Project Draft Testing Strategy
4. Introduction
As part of the Network Banking Automation Release 1 (NBA R1) programme, the
Post Office is introducing counter facilities to support the receipt of payments using
Debit Cards. This facility requires connection to the Merchant Acquirer service from
Streamline and an enhancement to Horizon. This will allow Horizon to operate as a
Debit Card acceptance terminal. The introduction of Debit Card payment facilities is
being managed as a separate project within the NBA R1 programme, with a separate
business case.
It has been proposed by Fujitsu that the Debit Card is implemented as part of the S30
release which is scheduled for 1 April 2003. It is understood that the $30 release will
include:
e Debit Card (including Streamline Accreditation)
e American date format
¢ Modulus 11 (stage 2 fix)
e¢ MAILS enhancement (excluding any external interfaces)
e Remote key management
e Bug fixes for NBA R1 banking infrastructure (BI3) release
This document sets out to identify the scope and approach for the testing required to
prove that Debit Cards can be processed successfully, both functionally and non-
functionally, and to ascribe those tests to agreed testing threads.
The testing of Debit Card, however, must incorporate an element of testing for the
other components of the $30 release. Also, it must be recognised that whilst extensive
testing has been undertaken for BI3 (including functionality shared with Debit Card),
there is a need to undertake regression testing for banking and existing Horizon
functionality.
The testing will be used to support acceptance of the Debit Card functionality from
Fujitsu and release authorisation of the service by Post Office Ltd. It will also be used
complete Streamline Accreditation for Horizon.
The Post Office is buying a service from Fujitsu and Streamline. Fujitsu will
undertake their own testing of Horizon, which we will witness. Streamline is an
existing service and we will audit various aspects of their service to ensure that they
meet the Post Office’s requirements. In addition, we will conduct end-to-end (E2E)
functional testing to ensure that the facility works within a Post Office context and to
achieve full Streamline Accreditation.
4.1. Purpose of Debit Card testing
The specific purpose of Debit Card testing is to demonstrate that:
Version 0.5 Page 6 of 23
POL00439364
POL00439364
POL-BSFF-096-0001291_0005
Debit Card Project Draft Testing Strategy
valid Debit Card transactions are proved capable of being swiped or keyed and
that an appropriate authorisation message is received by the originating outlet
and progression to confirmation of the transaction is possible
invalid Debit Card transactions are rejected, either at the outlet, or at the
Merchant Acquirer with the appropriate error message returned to the
originating outlet
RDS updates will enable the control of Debit Card transactions through the
system, but RDS itself is not being tested
all valid Debit Card transactions are accounted for and that accurate settlement
and full reconciliation is possible
the Debit Card reference data can be maintained
error situations (e.g. duplicate transactions) can be resolved for all impacted
parts of the process (e.g. incorporating settlement adjustments)
management information (e.g. bank analysis and outlet outcome analysis) is
produced correctly
Horizon meets Streamline Accreditation requirements
the system meets agreed functional and non-functional acceptance criteria
4.2. Assumptions
There are a numbers planning assumptions for Debit Card testing:
Individual (hardware and software) components will have been tested, proved
and stable, as an outcome of testing BI3, before this phase commences.
Fujitsu will undertake testing during development and will have undertaken a
number of test cycles as part of their Business Integration Testing (BIT) and
Volume & Integrity (V&I) testing.
A stable testing infrastructure is in place.
A Debit Card requirements, functional and non-functional, are defined and
agreed.
Debit Card compliancy matrix has been defined and agreed with Fujitsu.
Debit Card acceptance criteria, functional and non-functional, are defined and
agreed. These will only be agreed within Post Office Ltd., as they are not
contractually binding on Fujitsu.
The necessary resources (people, environments, test data and test cards) are
available from Post Office Ltd., Fujitsu and Streamline to support the agreed
testing schedule.
Version 0.5 Page 7 of 23
POL00439364
POL00439364
POL-BSFF-096-0001291_0006
POL00439364
POL00439364
Debit Card Project Draft Testing Strategy
e Only signature based Debit Cards are being tested. No testing will be done for
PIN based Debit Cards.
e Fujitsu are using Retail Logic which has already been type accredited by
Streamline. This means that Horizon will be using a pre-validated interface to
Streamline, which should reduce integration testing requirements.
e Fujitsu will undertake sufficient regression testing to demonstrate that the
existing Horizon functionality, including the banking solution, will continue to
work.
e Testing will use Fujitsu’s NBE simulator, such that there is no involvement of
IBM, LINK, Card Account or A&L.
e OPTIP and CBDB systems will not be within scope for E2E testing, although
we will check the OPTIP files from Fujitsu at the POL gateway.
e The period-end and year-end reconciliation process is the same as for network
banking and has been proved as part of BI3 testing.
In addition, for testing the S30 release, it is assumed that MAILS has been fully tested
and released as a pilot. Hence, we are only doing a regression test for MAILS as part
of Debit Card testing.
Version 0.5 Page 8 of 23
POL-BSFF-096-0001291_0007
Debit Card Project Draft Testing Strategy
5. Testing approach
5.1. Overview
As Horizon is a managed service, Fujitsu will perform all the necessary testing to
assure the delivered product. Post Office Ltd. will witness Fujitsu testing as required
to support acceptance of the system from Fujitsu. Witnessing of Fujitsu testing will be
in accordance with a witnessing plan that has been agreed between Post Office Ltd
and Fujitsu. The witnessing plan will identify the relevant tests from Fujitsu’s High
Level Test Plan [7] that we will observe to demonstrate that Fujitsu have met the
Debit Card Compliancy Matrix [4]. Witnessing of functional testing will be conducted
during cycles 3, 4 & 5 of Fujitsu’s BIT testing.
Non-functional testing will cover security, performance and disaster recovery (DR).
This will be achieved by witnessing V&I tests at Fujitsu and auditing evidence from
Streamline and Fujitsu. Witnessing of non-functional testing will be undertaken as
part of cycles 2 & 3 of Fujitsu’s V&I testing.
In addition, Post Office Ltd. will conduct E2E functional testing to support release
authorisation and complete acceptance of the system from Fujitsu. The POL High
Level Testing Strategy [1] dictates that duplication of testing should be avoided. This
principle is followed within the Debit Card testing strategy, but it is recognised that
E2E testing may duplicate testing already carried out by suppliers. The testing context
for E2E testing, however, is such that it undertakes business scenario testing,
including Post Office Ltd. systems and operational areas.
Prior to E2E testing, there will be a need to conduct integration testing to prove
connectivity and messaging between Fujitsu’s BTC 7 test environment and the
Streamline test system. This will consist of connectivity testing and sufficient Direct
Interface Testing (DIT) to prove that messages and files are being transferred with the
correct data format and content. DIT will be based on the relevant Application
Interface Specification (AIS) and Technical Interface Specification (TIS). This will
also incorporate a practice Streamline Accreditation.
Process walkthroughs will be conducted separately from the testing described in this
document. This will be undertaken by the Business Change team within the NBA RI
programme.
5.2. Test organisation
The testing will be organised into test threads, each reporting to the NBA R1
Programme Test Manager. The threads will be:
e Supplier testing — witnessing of supplier testing at Fujitsu. This will involve
the agreement and execution of a witnessing plan, where we will witness tests
from Fujitsu’s High Level Test Plan during cycles 3, 4 & 5 of their Business
Integration Testing (BIT).
e Integration testing — testing the interfaces between systems in supplier
domains (e.g. Horizon to Streamline). This will be undertaken prior to E2E
Version 0.5 Page 9 of 23
POL00439364
POL00439364
POL-BSFF-096-0001291_0008
Debit Card Project Draft
POL00439364
POL00439364
Testing Strategy
testing to prove that messages and files are transferred in accordance with the
agreed AIS and TIS. It will also include a practice Streamline Accreditation.
e E2E testing — performing E2E functional testing across supplier domains (i.c.
including Post Office Ltd, Horizon and Streamline systems and processes).
E2E testing will be undertaken with code from the end of the 3“ cycle of
Fujitsu’s BIT. E2E testing will be undertaken in a series of 5 days cycles with
the systems operating in real time (i.e. there will be no manipulation of dates
or times).
e Non-functional testing — witnessing and auditing of testing in the areas of
security (including remote key management), performance and disaster
recovery. This will be undertaken by witnessing Volume and Integrity (V&I)
testing at Fujitsu, and auditing evidence from Streamline.
5.3. Testing scope
The table below identifies, at a high level, the types of testing required for Debit Cards
and assigns the tests to various testing threads. A description of each test area is
included in Appendix A.
Testing Area
Supplier Testing
(witnessed by POL)
Integration Testing
E2E Testing
Non- Functional
Testing
Interface connectivity testing
Direct Interface Testing (DIT)
Reconciliation and reporting
Cash Account (including debit card transactions)
Payment file submission & EMIS retrieval
Card format and content validation
Counter dialogue
Regression testing
Credit card transactions
Streamline Accreditation
MI reporting
Version 0.5
Page 10 of 23
POL-BSFF-096-0001291_0009
POL00439364
POL00439364
Debit Card Project Draft Testing Strategy
> pp
I =
2S) 4 wo I =
zm g = Ss
ad & =. eM
i esl os G es
Testing Area st a) i= ES
23 z eI me
ag = a a
Fe; 2) # I 3
MID/TID maintenance and outlet data management e e
Security testing (including remote key management) . .
Performance testing e .
Volume testing ° e
Disaster recovery & business continuity . .
Rollback testing e .
There are a numbers of areas that are out of scope, these include:
Usability testing. No specific usability testing will be undertaken as it is
assumed that the system will work to specification and that process
walkthroughs will cover this area.
MID/TID Management Set-up. This is the full load of MIDs, TIDs and
corresponding FADs to all outlets.
Validation of MID, TID FAD data.
Testing of RDS, it is assumed to be fully working.
Testing of POL systems (including OPTIP and CBDB). We will check files
delivered to the POL Gateway, but we will not load them into OPTIP.
Testing of the POL Gateway.
5.4. Test specification
Testing is designed to:
Support acceptance of the system from Fujitsu and Streamline.
Prove the integration of supplier domains.
Support the achievement of Streamline Accreditation, demonstrating that
Horizon meets the requirements for connection to the Merchant Acquirer
system.
Version 0.5 Page 11 of 23
POL-BSFF-096-0001291_0010
Debit Card Project Draft Testing Strategy
e Support release authorisation from Post Office Ltd, allowing S30 to go live
within the business.
Acceptance of the enhancements to Horizon from Fujitsu will largely be based on
witnessing Fujitsu testing against its High Level Test Plan. The development of test
cases and scripts for this is a Fujitsu responsibility. The witness plan will be based on
the Debit Card Compliancy Matrix [4]. It will developed by Post Office Ltd. and
agreed with Fujitsu.
Acceptance of the Merchant Acquirer system will be based on auditing evidence from
Streamline. Again, POL will determine the what evidence they require in consultation
with Streamline.
Testing the integration of supplier domains is based on the interface specifications
produced by the Design Authority and agreed with the relevant suppliers. There are
Application Interface Specifications (AIS) and Technical Interface Specifications
(TIS) for the interfaces between Streamline, Horizon, OPTIP and RDS. For Debit
Card, there are no changes to the interfaces between Horizon, OPTIP and RDS.
Integration testing, therefore will focus on the interface between Horizon and
Streamline. For this, we will develop test scenarios and test scripts using the agreed
AIS and TIS.
Streamline Accreditation will use the test scripts and test cards developed and
supplied by Streamline. Scripts will be executed from Horizon and checking will be
undertaken by Streamline. A practice accreditation will be undertaken as part of
integration testing, but final accreditation will be undertaken after the final code drop
from Fujitsu. The execution of scripts for final accreditation will be undertaken at
Fujitsu by a Streamline tester. This will be followed by detailed checking off-site by
Streamline.
Release authorisation will be based on a set of high level acceptance criteria that have
been defined by the Design Authority. These relate to Streamline, Fujitsu and POL.
These acceptance criteria are used as the basis for developing test scenarios and test
scripts for E2E testing.
The approach for developing test scenarios and scripts is outlined in the diagram
below. Test scenarios and test scripts developed by POL will be held in TestDirector,
together with the Requirements Catalogue and High Level Acceptance Criteria for
Debit Card.
Version 0.5 Page 12 of 23
POL00439364
POL00439364
POL-BSFF-096-0001291_0011
POL00439364
POL00439364
Debit Card Project Draft Testing Strategy
‘Steanine falas
4 Catogue aa
FOL
[Srearia]
Feltsu
High Level
Acceptance
Gren
‘Streamline Requirements Design Authority Requirements
Fujitsu Testing
Post Office Ltd Testing
Fujtsu PTU
Test Sorts
5.5. Test environment
Fujtsu Val
Test Serpis
POL POL POL PoL
Functional Non functional Integration EE
Winess Plan Wness Pian Test Scenarios Test Scenarios
Fyjtsu
FujtsuPTU ae Fujtsu Val
‘Test Scenaros :. Test Scenarios POL, POL
jest Pian re
Test Serpts
Post Office Lid, Domain Testing
The diagram below outlines the test environment required for E2E Debit Card testing.
Merchant
‘Acquirer
Simulator
Fujtsu !
Version 0.5
Page 13 of 23
POL-BSFF-096-0001291_0012
Debit Card Project Draft Testing Strategy
The test environment for E2E testing will consist of the BTC 7 test rig at Fujitsu,
interfaced to the Streamline test system and the POL Gateway. It will not extend to
include the NBE, LINK, LINK FIs, A&L or Card Account test systems. Rather, an
NBE simulator will be connected to the BTC 7 rig to handle banking transactions. A
more detailed schematic of the test environment is that shown in Appendix B
5.6. Incident management
The management of incidents will be supported by the use of TestDirector. Incidents
will be classified and managed in accordance with the NBA RI Test Incident
Management Process [5].
5.7. Test schedule
Debit Card testing is covered in the Level 1 NBA R1 Programme Plan. It is also
included in the Debit Card Project Plan.
5.8. Testing resources
Testing resources for Debit Card are documented separately in the Integration and
Acceptance Testing Resource plan.
Version 0.5 Page 14 of 23
POL00439364
POL00439364
POL-BSFF-096-0001291_0013
Debit Card Project Draft Testing Strategy
6. Appendix A - Testing Areas
6.1. Interface connectivity testing
Connectivity testing will be required to prove the connections between the Horizon
BTC 7 test rig and Streamline prior to Direct Interface Testing (DIT).
6.2. Direct Interface Testing (DIT)
Direct Interface Testing will ensure that messages and batch files are successfully
transferred with the correct format and content. This needs to be completed prior to
E2E testing. It will also include a practice Streamline Accreditation.
6.3. Reconciliation & reporting
Reconciliation and reporting will be undertaken to ensure that all transactions for
which Debit Card is the method of payment are fully reported and accounted for in the
back end systems and reconciled with the financial institution. Testing will
demonstrate that settlement figures generated at Streamline can be agreed with those
in the POL gateway. This should include the settlement reports NB101, 102 and 103.
6.4. Cash account
All Debit Card payments at an outlet will be clearly identifiable on the cash account
for that outlet. Debit Card transactions for payment for goods and refunds will be
shown separately on the cash account.
6.5. Payment file submission & EMIS retrieval
The contents of the payment file and the EMIS will be proved by comparison of the
Streamline transaction totals against Fujitsu Data Reconciliation Service.
6.6. Card format and content validation
[to be added]
6.7. Counter dialogue
[to be added]
6.8. Regression testing
Additional, limited, end-to-end testing of banking functionality will be required to
ensure that the additional Debit Card functionality will not adversely impact the
banking solution or existing Horizon infrastructure.
6.9. Credit card transactions
Although the Post Office does not currently intend to accept payment by credit card,
testing needs to prove their acceptability. Streamline will have credit cards “turned
on” in their system. We need to prove that RDS will allow us to turn the facility on
and then off for live running. These will also be included in reconciliation testing to
Version 0.5 Page 15 of 23
POL00439364
POL00439364
POL-BSFF-096-0001291_0014
Debit Card Project Draft Testing Strategy
prove correct accountability for credit card transactions. Testing of credit cards must
also prove their rejection at the outlet, when ‘turned-off by reference data.
6.10. Streamline Accreditation
Streamline will provide a set of test cards and test scripts to support accreditation. We
will need to give Streamline notification that we wish to do accreditation. Testing
should only take about half a day to execute, but it will require a Streamline tester to
execute the scripts at Fujitsu. It will then take Streamline about 10 days to verify the
results. A practice accreditation will probably be undertaken as part of DIT, but full
accreditation needs to be undertaken using the final code drop.
6.11. MI reporting
In the context of Debit Card Testing, there are two MI reports (bank analysis and
outlet outcome analysis) produced in the Fujitsu domain and transmitted to Post
Office Ltd. for financial control purposes. These will be verified against the Fujitsu
Data Reconciliation Service for accuracy and content.
6.12. MID/TID maintenance and outlet data management
[to be added]
6.13. NBSC
As part of functional testing, a series of tests will call upon the NBSC (Network
Banking Service Centre) to simulate calls from branches. This ensure that support
procedures and documentation are in place and there is sufficient to support the
network.
6.14. Security
There is need to assure the business that the security of the system is such that fraud
can be prevented and attempted fraud detected.
e Streamline - Security at financial institutions such Streamline is taken very
seriously and as a consequence they are reluctant to share detailed information
on the subject. We therefore need acceptance criteria and formal assurance, via
the contract, from Streamline that the Post Office criteria will be met. They
should also be able to present evidence to support their claim, which we will
audit.
e Fujitsu - The majority of the Horizon infrastructure will be tested
satisfactorily for the banking solution. This leaves the areas of key
management, encryption and authentication to be proved. It is envisaged that
all these areas would be subject to witness testing by the Post Office. Security
being a specialist subject means that the Post Office witness will need the
appropriate level of expertise to validate the Fujitsu test results.
¢ Post Office Systems - There are no new security implications affecting Post
Office Systems.
Version 0.5 Page 16 of 23
POL00439364
POL00439364
POL-BSFF-096-0001291_0015
Debit Card Project Draft Testing Strategy
6.15. Performance testing
The purpose of this testing is to prove that the system will withstand and successfully
process peak transaction loading, within the appropriate response times back to the
outlet. Witness testing of tests using a Fujitsu transaction simulator will suffice.
There are three components involved:
¢ Horizon infrastructure — It is assumed that banking will have stressed the
infrastructure sufficiently to provide confidence that this component will
support peak loads for Debit Cards.
e Retail logic — As this is within the Fujitsu domain, Fujitsu must run tests using
a simulator and provide a witnessing facility to Post Office Ltd.
e Streamline — A testing facility for this purpose is not available from
Streamline. We will need a formal statement from Streamline that they will be
capable of processing peak loads within our predicted transaction volumes.
Performance testing will audit this evidence.
6.16. Volume testing
The purpose of this testing is to prove that all the system’s storage components will be
capable of holding and processing the data to a volume at least equal to highest
predicted volumes.
There are three components involved in volume testing:
© Streamline - As no facilities exist from Streamline to conduct volumes testing
of their system we will require a contractual item to assure the Post Office of
Streamline’s ability to support the predicted volumes. Streamline will be
expected to provide evidence to support their assurance and POL will audit the
evidence. Acceptance criteria should be documented for this.
¢ Fujitsu - As part of the banking solution Fujitsu will have conducted volume
testing, to the Post Office’s satisfaction, for the major part of the Horizon
infrastructure. However, there remains the interface from Horizon, via the
Retail logic application to Streamline. The suggested test environment for this
would be for Fujitsu to use two simulators. One simulator to inject Debit Card
transaction into Horizon and another simulator to simulate Streamline. The
Post Office will document acceptance criteria and witness the testing in this
area.
© Post Office Systems - As part of the banking solution testing, a “double day”
test will be performed. This test involves loading two day’s worth of data
(high volume days are chosen) and ensuring that all processing can be
completed successfully within the appropriate production window. The
success of this test will be taken as sufficient evidence that the systems will
cope with Debit Card transaction to the currently predicted volumes
Version 0.5 Page 17 of 23
POL00439364
POL00439364
POL-BSFF-096-0001291_0016
POL00439364
POL00439364
Debit Card Project Draft Testing Strategy
6.17. Disaster recovery and business continuity
The loss of Debit Card acceptance for a finite period is not likely to be business
critical therefore, in that context, testing will be limited to auditing of the plans
available from the suppliers, as described below.
There are three major components at risk in this area. They are:
¢ Loss of Fujitsu campus - This part of the infrastructure has built in resilience
with two sites and multiple clusters. Extensive testing will have been carried
out for the general Horizon infrastructure and the banking application.
Therefore no additional, Debit Card specific testing is required.
¢ Loss of Merchant Acquirer site - Streamline does not provide facilities to do
DR testing. They have a second site to which they switch transactions in the
event of the failure of the primary site. What Post Office Ltd. require is an
assurance that adequate plans and procedures are in place and audit evidence
to support the assurance. We will also need to prove connectivity to the DR
site.
¢ Loss of Retail Logic application - There are four separate instances of the
application each supporting about one quarter of the outlets. The application is
subsumed into the Horizon infrastructure. Witnessing of Fujitsu testing by
Post Office Ltd. will be necessary to ensure that that controlled recovery of
data is achieved or reconciliation possible if the application fails.
6.18. Rollback testing
Fujitsu will demonstrate to Post Office Ltd. that they have adequate version control in
place.
Version 0.5 Page 18 of 23
POL-BSFF-096-0001291_0017
POL00439364
POL00439364
Debit Card Project Draft Testing Strategy
7. Appendix B - Overview of systems scope
Shaded boxes will not be directly involved in the testing. The NBE would be
simulated for regression testing. Files from the MA will be delivered to the POL
gateway for input to TIP and CBDB and would be checked manually for accuracy at
the Gateway.
Financial 2 Bindi:
Institutions 2 Ippthatons
a a
R, Aand R, Aand
Reversals, E (Reversals)
vy Y MIDITID data (Email)
Fujitsu
Merchant Acquirer ee
‘Simulator
ry i ry ry -MIDTID data» Tvansaction
C4andd —C4ando oma Processing
Rada
Y m4 RandA C(nul) I Reports > POLTP
Retail Logic soe Reccten : Me umted Getowey
Y rn
' ‘ Outlet MIDITIO data
Randa c
Y I pee ome.
IHoizoncoters) I fo EERE —
Gach Account
con
Version 0.5 Page 19 of 23
POL-BSFF-096-0001291_0018
POL00439364
POL00439364
POL-BSFF-096-0001291_0019
Debit Card Project
Draft
POL00439364
POL00439364
Testing Strategy
8. Appendix C - Risks
The following table details the potential risks for the business associated with using
the above approach and the imposed constraints.
Constraints/
Considerations
Risk
Mitigating Factors
Real-time
testing
Unable to develop all Ref Data
changes in advance as date will be
always moving
The planning of key events is
dependent upon no slippage in
start date of each run
The planning of key events is
dependent upon no slippage within
each run once started
This restricts options if better than
planned progress occurs
If slippage occurs prior to
commencement re-planning and
Ref Data changes will be required
which may not be achievable
If slippage occurs during a cycle
re-planning and Ref Data changes
will be required which may not be
achievable
Some key events, e.g. financial
year end will not be possible
Limited ability to produce
weekly/monthly reports with
accurate expected results
Opportunities to run some tests
which rely on cash account
week/period ends will be limited
and may be missed altogether if
the system is unavailable that day.
Some weekly/monthly reports
therefore may not be fully tested.
NB103 not fully tested and
anomalies cause discrepancies
between Post Office limiter’s
financial (‘T’ and ‘S? ledger
reconciliation) ledgers.
Reference Data changes for Bank
Card data (of which Debit Cards is a
subset), will have been tested as part
of the NB Release I testing
Daily reconciliation reports would
be fully tested and the weekly
NB103 would have been tested as
part of the NB Release I testing.
Witnessing of Fujitsu system testing
could be performed to give
confidence in areas of concem, e.g.
reconciliation.
Version 0.3
Page 21 of 23
POL-BSFF-096-0001291_0020
Debit Card Project
Draft
POL00439364
POL00439364
Testing Strategy
Constraints/ Risk Mitigating Factors
Considerations
No TIP Debit Card transactions cause TIP Unlikely - Debit Card transactions
involvement
to reject transaction files
could be checked for correct
format/content manually as part of
testing.
No change to Horizon to TIP
interface
No CBDB
involvement
Debit Card cash account lines
rejected by CBDB
Highly unlikely — existing
interface/process between TIP and
CBDB.
No Reference
Data Changes
tested
Debit Card data changes not
correctly actioned by Horizon
Interface to Horizon from RDS not
changing for Debit Cards, all
changes will be tested as part of NB
Release 1.
Witnessing of Fujitsu system testing
could be performed to give further
confidence for Debit Card changes.
Version 0.3
Page 22 of 23
POL-BSFF-096-0001291_0021
Debit Card Project Draft Testing Strategy
9. Glossary of Terms
AIS Application Interface Specification
BB Banking Increment 3
BIT Business Integration Testing
DIT Direct Interface Test
E2E End-to-end
EMIS Electronic Management Information System
FAD Financial Account Division — unique per outlet allocated by Post
Office Ltd.
MA Merchant Acquirer — Streamline
MID Merchant Identifier — unique code per outlet allocated by Streamline
NBE Network Banking Engine
PTU Pathway Test Unit — test cycles defined and executed by Fujitsu
RDS Reference Data System
TID Terminal Identifier unique code per outlet terminal allocated by
Streamline
TIS Technical Interface Specification
V&I Volume & Integrity
_Version 0.3 Page 23 of 23
POL00439364
POL00439364
POL-BSFF-096-0001291_0022