POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0 ; . .
Bringing Technology to Post Offices and Benefit Payments
END TO END TESTING
EVALUATION REPORT FOR NILE RELEASE 2.0
Controlled Copy No
Reference: R2E2Eeul.doc
Author: Keith Hall
Approved: Chris Young
Classification: BA/POCL Restricted
Version: Draft 0.1
Date: 19/03/99
Status: Draft
Authority: Horizon
Document Summary:
This document reports the results and conclusions drawn from the final pass
of the End to End testing of Nile release 2.0.
Outstanding incidents, known problems and usability issues will also be
identified.
Version Draft 0.1 Page 1 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
0 DOCUMENT CONTROL
0.1 Circulation
Contact Area Copy I Signature
‘Baldwin, Hadley CAPS i
Baldwin, Ted. . Ref. Data Project
Blood Iain - I Haps
Bollom, Sue BA OBCS
Box, Martin TIP Project
Brunskill, Richard Pathway BSU
Gaze, Richard Horizon
Holleran, Ruth POCL
Jepmond, Carol CAPS
Jeram, Peter Pathway
Jones, Peter TIP Project.
Meagher, John Horizon
Miller, Dave Horizon
Moran, Sue BA PACS
O'Sullivan, Nikki” Pathway
Parnell, Dave TIP Project
Radka, Andy ° Horizon
Reardon, Marc Horizon
Shervington, Graham HAPS
Simpkins, Andrew Horizon
Stocker, Rod : Horizon
Topham, Janet Horizon
Young, Chris Horizon
0.2 Version History
Version Issue Date Change Details
Version 0.01 draft 19/03/99 Initial draft sent for QR
0.3 Related documentation
Reference Title Version I Date Author
1] End to End Interface and Model Office I 1.0 Horizon
Testing Approach
Version Draft 0.1 Page 2 of 73
Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
[2] End to End Testing Final Pass - Daily I - - Horizon
Reports 3
3] New Release 2 MOT Release Notice 10 19/02/99 I Pathway
Version Draft 0.1
Page 3 of 73
Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
1 CONTENTS
0 DOCUMENT CONTROL.
01 CIRCULATION...
0.2 VERSION History.
0.3 RELATED DOCUMENTATION.
D_ CONTENTS essesccsscensseensosnseoe
wR PNK
2 MANAGEMENT SUMMARY.
3 INTRODUCTION.
3.1 BACKGROUND..
4.21 Pathway Di F
4.2.2 Test Office Configuration:
43 SOFTWARE BASELINE...
44 SUMMARY OF SYSTEM FUNCTIONALITY.
44.1 Areas covered within End to End..
44.2 Areas not covered within End to E1
5 TEST CONDUCT........
51
5.11 Planned Schedule
5.1.2 Actual Schedule.
6 OBSERVATIONS
61 TRAINING ISSUES.
6.2 COUNTER PROCESSES.
6.2.1 Shared Stock.Unit Balancing.
6.2.2 Losses and Gains.......
63 SUPPORT THROUGHOUT THE CYCLE.
7 TEST RESULTS.
71 HORIZON ENDTO END...
7.11 Access Control / User Administration (ACUA,
7.1.2 Automated Payment Service (APS)..
7.13 Benefit Encashment Service (BES)
714 Electronic Point Of Sale Service (EPOSS,
715 Fallback & Recovery.
7.1.6 File Transfers.
717 Helpdesks..
7.18 Migration
719 Reference Data..
15
5
5
5
5
6
7
20
0
2
4
33
0
1
2
8
45
>
ie)
Z
B
fe}
5
RRR BR BRSSSSOo © MMMM MUDD
Version Draft 0.1 Page 4 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
7.1.10 Order Book Control Service (OBCS).
7.2. EXTERNALSYSTEMS.....
7.21 Business Support Unit (BSI
7.2.2 Customer Accounting and Payments System (CAPS).
7.2.3 Host Automated Payment System (HAPS)..
7.24 Transaction Information Project (TIP)
8 CLOSED INCIDENTS.......
Version Draft 0.1 Page 5 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
2 MANAGEMENT SUMMARY
2.1 Summary
End to End testing originated from the requirement to test some of
the longer business processes i.e. 3 week cash account, and to ensure
that data integrity was maintained throughout the system
‘ environment. Using lower volumes and including more exception
tests than the Model Office Test, an agreed plan was generated and
scripted by the Horizon test team, with input from all parties ice.
CAPS, TIP, HAPS, OBCS and POCL RDP.
The final pass of End to End was the culmination of earlier passes,
which achieved their test objectives to an extent. However,
throughout the earlier passes some areas of functionality were not
available in the build being used for the test, and other areas fell short
of the expected functionality.
Prior to the commencement of the final pass, to provide sufficient
confidence that the software was stable enough to enter the End to
End and Model Office testing final passes, an additional 6 - day pre-
proving exercise took place. Two runs of the 6 - day test were
performed and were deemed as successful.
Lessons learrit from previous passes of End to End were implemented
prior to the commencement of the final pass. These were:
e A reduction in the volume of transactions entered onto the
Horizon counter throughout the cycle.
e Additional information on areas which had previously been
unclear i.e. 3 week cash account, BES recovery etc.
e Expected results for each Stock Unit and Office Balance for each
day of the cycle e.g. all transactions were reconciled to the office
balance each day.
e Additional checking of the input data versus the output reports
and summaries. This was performed on the day following the day
of input.
As a result of the work performed by all parties between End to End
2nd pass and the commencement of the final pass, in ensuring that the
test data and environment would support the cycle, the final pass was
performed with fewer issues than previous cycles. The main
differences were:
¢ The cycle ran day - for - day to the end with no slippage -
¢ There was a reduction in invalid incidents raised
Version Draft 0.1 Page 6 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
¢. Test results were proven at a higher success rate i.e. higher % of
scripts run and passed
* Test conditions were identified prior to the cycle and tracked
during the cycle
¢ Incident management was resourced adequately, which assisted
all parties to monitor the current position at'any given time
¢ Incident management processes had an improved structure, which
included the involvement of Horizon Product Management for
Business impact assessment
* Reconciliation of transactions across different Business boundaries
was possible,. including POCL and. BA back end systems e.g.
CBDB (POCL), PACS (BA) and BSU (Pathway).
Throughout the final pass issues were identified by all parties. Some
issues where remedied and re-tested’ within the cycle ie. POCL
reference data drop to change the Cash Account type from London to
Provincial. It was necessary to apply fixes to the counter environment
to either move forward, or to improve the quality of the test results
ie. the incorrect cash account mapping for a stock item would have
caused mis-balancing Cash Accounts in-all offices.
In all, the final pass of End to End was successful, in that, the ‘key’
tests contained within the test plan were executed as planned, and
incidents have been raised for failed tests. The incidents which have
been assessed by the partners including Horizon Product
Management, and a greater impact on the live environment during
the ‘live trial’ period have been planned for targeted testing.
2.2 Conclusion
End to End Testing final pass achieved the test phase objectives as
defined in the Testing Approach Document.
.The ability to maintain day for day running was achieved by careful
management and communication between all parties.
Ongoing reviews of incidents-throughout the cycle have enabled -
decisions to be made with regard to the status of each incident i.e.
when a fix or change will be required.-This process has led to a short
cycle of targeted testing which will witness those incidents regarded
by each sponsor organisation as a risk to the live trial. Outstanding
_ incidents are under discussion for inclusion on the Known Problem
Register (KPR).
Version Draft 0.1 Page 7 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
3 INTRODUCTION
3.1 Background
End to End Testing was originally scoped from tests that were
required for inclusion in the Model Office Test, but would have
increased the cycle length beyond that previously agreed with BA
(CAPS).
The plan for End to End was for two rehearsal cycles and a final pass.
Each rehearsal incurred slippage, as the system functionality, test data
and scripts did not fully support the test. Between the second
rehearsal and the final pass, time was used for the application and
testing of PinICL fixes, by Pathway, pre-proving of some of the fixes,
by Horizon and CAPS. There was also an opportunity for the
Horizon test team and CAPS to revisit the test script, with a view to
improving the quality of the tests and in particular the expected
results. :
3.2 Purpose
The purpose of this report is to provide details of the tests performed,
the results achieved, and conclusions drawn from the phase.
3.3 Scope
The scope of this report is Nile Release 2, End to End Testing, Final
pass only.
3.4 Test Objectives
As described in the Horizon Testing Approach document [1], the
objectives of the End to End Final pass are as follows:
“E2E will be planned for a low volume of transactions, which
specifically test End to End business processes, which are too lengthy
and complex to be performed within the timeframe and structure of
“MOT. Whilst ensuring that the integrity of the data remains intact
when all systems interface on the same environment.”
Version Draft 0.1 Page 8 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
4 SYSTEM UNDER TEST
41 Parties and systems involved in Nile 2.0 End to
End Testing
The following areas were involved in the End to End Test:
* BSU - Pathway Business Support Unit - performed reconciliation
liaison activities with BA and POCL
¢ CAPS - Customer Accounting and Payments Strategy - provided
input data required at the counter to perform BES related tests.
Received encashed payments from Pathway and tracked against
the expected results. Supplied data to PACS to enable
reconciliation of BES encashments.
“e DeLaRue- Supplied Benefit Payment Cards and PUNs
¢ HAPS - Host Automated Payments System - POCL AP
transaction distribution system - received AP transactions from
Pathway and hybrid platform (APT) and passed the data to
APACHi for reconciliation in CBDB.
¢. Horizon Test.Team - Planned and scripted the counter related _
tests with input from the other parties involved. Executed the tests
at the counter throughout the cycle and reported results.
¢ OBCS (PRCS) - BA Order Book stop notice control system
¢ PACS - BA Benefit payment/encashment reconciliation system -
received and reconciled BES transaction data with BSU and TIP
¢ Pathway - Managed the Pathway Central Systems, incoming and
outgoing data, incident analysis etc. _
¢ POCL RDP - Provided Pathway with required reference data to
enable transactions to be performed at the counter, along with
drops of data contains details of product changes.
¢ TIP - Received transaction data from Pathway and validated it
before processing Cash Account information within CBDB.
Verified data integrity with input data information from the
counter activities.
42 Environment
This section describes the environment used for End to End Final
pass.
I Version Draft 0.1 Page 9 of 73 Date 29/03/99
po
POL00028419
POL00028419
End’to End Testing Evaluation Report for Nile Release 2.0
4.21 Pathway Domain
The. test environment within the Pathway domain comprised of a
Release 2 datacentre with links to all external systems.
Gateway PC's, for the transmission of data to remote sites, were
located at Farnborough, Huthwaite, and de La Rue, Tewkesbury.
Access to the Payment Card Helpline was made via a Helpdesk PC
simulator located at the Pathway site rather than via telephone to
Girobank.
4.2.2 Test Office Configurations
The Test Offices used during End to End final pass comprised of 8
Post Offices, of these:
¢ 1non-automated - for BES Helpdesk transactions only
¢ 2 were migrated from ECCO+ using the MiECCO migration tool,
and also had electronic scales attached
¢. 5 were migrated from manual offices using the MiMAN migration
tool.
¢ Offices were connected to the Correspondence Server via:
¢ LAN connection (3)
e ISDN (2)
¢ Frame Relay (2)
e A variety of Regions were included in the configurations including
Welsh and Northern Ireland office types.
The test counters comprised of Pentium II processors, with 64 Mb
RAM and a combination of Flatscreen and standard touchscreen
monitors. Full security lock-down was not applied, as agreed, to
enable Pathway to manage the day to day running of the
environment.
43 Software baseline
The software release was the MOT baseline (9 increment 7.2) [3], with
_ some additional changes made to this baseline during the cycle (See
[2] for details). The changes were agreed by the relevant testing
partners prior to being applied.
44 Summary of system functionality
The following applications formed part of the testing baseline:
Version Draft 0.1 Page 10 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
° BPS
« EPOSS
e APS
¢ OBCS
e RDMC
e TPS
4.4.1 Areas covered within End to End
In conjunction with the system applications noted above, the
following ‘key’ areas of functionality were included within the tests
performed during the final pass:
¢ Migration from manual accounting and ECCO offices, using the
relevant migration tools. Tests included both ‘clean’ Cash Account
and ‘mid-week’ Cash Account migrations.
e Extended Cash Account period - using the option of 3 weeks
¢ . BES Recovery
¢ OBCS stops and recalls
Use of the counter when the LAN connection has failed
¢ Long term Office closure - the movement of cards and payments
to a different ‘nominated’ office.
¢ Temporary Tokens and Urgent Payments
¢ Multiple benefit types -. Child Benefit (ChB), Job Seekers
Allowance (JSA) and Income Support (IS). This area included a
combination of payee roles i.e. Standard Beneficiary, Permanent
Agent, Appointee, Card and Uncarded Casual Agents. It should
be noted that the tests relating to multiple benefit types were
outside the scope of the release being tested. The decision to
include Child Benefit as the only benefit type was made shortly
before the commencement of the first rehearsal. As it would have
taken too long to amend the test packs of both Horizon and CAPS,
it was agreed by all parties for the scope to remain as originally
planned. ‘
e POCL Reference Data changes - these tests were included to test
the reaction of the changes at the counter, including the
revaluation of products, and also the reaction of the changed
reference data between Pathway and TIP i.e. changes sent to both
systems from POCL RDP are aligned when implemented.
Version Draft 0.1 Page 11 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
4.
¢ Removal of the ISDN line for more than 10 days - this test was to
ensure that BES transactions, held on the counter for a period
longer than the 10 day reconciliation statement can account for,
are placed on the relevant reports and can be reconciled by BSU,
TIP and PACS.
¢ Losses and Gains, including error notice processing at the counter.
¢ Standard EPOSS, AP, OBCS and BES transactions being keyed to
counter throughout the cycle to populate daily, weekly, stock unit
and office reports arid client summaries, including the Cash
Account.
¢ Cash Accounts were produced at various times throughout the
cycle. These were planned specifically to test the integrity of Cash
accounts when produced at unexpected times i.e. not aligned with
the Cash account calendar which determines when Postmasters
should produce the office weekly account. Such tests included:
e the Cash Account calendar file containing a short week and a
long week
¢ 3-week cash account period from week 52 to week 03
e rolling over the office from week 52 to week 01
¢ producing a Cash account when the LAN between 2 counters
is disconnected
¢ producing a Cash account when the ISDN line is disconnected
¢ Postmaster does not produce a Cash Account for 2 weeks
e All Cash Accounts were processed by CBDB, including the 2
week 04 cash accounts which were produced as a result of re-
planned tests. These were produced by agreement of the
relevant parties
All data was passed to the relevant systems each day for
processing, using usual business processes to achieve expected
results.
4.2 Areas not covered within End to End
Datacentre migration
Training mode
Testing of counter procedures ~ although the procedures were used
for functional areas which were only covered by End to End
Use of ‘live’ Helpdesks
7
Version Draft 0.1 Page 12 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
« Use of PLU’s for selection of products
© Nosecurity ‘lock down’ on the counters i.e. POLO
¢ Invoicing via the Pathway datacentre
Version Draft 0.1 Page 13 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
5 TEST CONDUCT
5.1 Timescales
5,
5.
1.1 Planned Schedule
End to End final pass was scheduled to run across the following ‘key’
dates:
08/12 Feb - System set-up and loading of input data, including
delivery of BES cards
13 Feb - Migrate 3 manual offices to Release 2 using MiMAN
14 Feb - Perform BES and OBCS transactions which had been
scheduled for Days 1 - 5 in a previous plan. These days were
subsequently removed along with the datacentre migration activity,
however, the transactions were required to be executed before Day
8 to keep the expected results aligned.
15 Feb - 12 March - Execution of the test plan at the counter,
including transmission of data to external systems.
13 March - 17 March - Final processing of data and reconciliation at
the ‘back end’ systems, and system clear down where applicable.
1.2 Actual Schedule
The schedule was executed as planned, with no slippage incurred.
Version Draft 0.1 Page 14 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
6 OBSERVATIONS
6.1 Training Issues
The Horizon training event was attended by all members of the
Horizon Test Team and all test operators who executed the test
scripts during the final pass. There is a unanimous view that the
training event, as presented to the End to End team, will not be
sufficient to equip ‘real’ end users in readiness for their offices
receiving the Horizon system.
The course was thought to be too short, with too little time to reflect
on areas being demonstrated. The course handout booklet was not
referred to enough to sufficiently familiarise the user with the book
for when they return to their office.
More time should be allowed for the more complex areas of Stock
Unit Balancing, and office accounting, as the concept of an automated
system will be new to many users.
The trainers will require a deeper knowledge of POCL processes,
including those that require the interaction of POCL users, Customers
and BA i.e. when Customers should be referred to the local BA office
etc. This knowledge will be necessary to deal with the variety of
questions they will be asked.
6.2 Counter processes
Throughout End to End testing, the following observations were
made in relation to the counter.
6.2.1 Shared Stock Unit Balancing
The concept of shared stock unit balancing will be new to most of the
users. Although the system functionality works as designed, it is nota
user friendly process to follow and could lead to a confused state at
the counter.
The procedures and training will need to be clear with regard to
backing out of problems and best practices to follow for ease of use.
6.2.2 Losses and Gains
Again, the system functionality does support the process of
accounting for losses and gains between stock units and the suspense
account. However, use should be made aware that, in posting a loss
or gain to suspense, there will be a subsequent loss or gain visible on
Version Draft 0.1 Page 15 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
the stock unit for the next accounting week. This does clear following
a stock unit balance, but it could lead to confusion.
6.3 Support Throughout the Cycle
Lessons learnt from the rehearsal cycles led to changes in
communication and support mechanisms. These played an important
part in achieving a cleaner cycle, and it is worth noting what the
changes were.
« Pathway provided full time support at the counter to resolve
issues and queries. This helped with the analysis of incidents
when raised, as the Pathway support person was close to the
problem when it occurred. It also reduced the amount of incidents
being raised when there was no fault.
¢ CAPS provided two members of their team to support End to End
final pass. This level of support improved the management of the
tests cases, and the communication between Horizon and CAPS
when issues arose.
¢ The Horizon testing team had spent time reducing the volume of
transactions throughout the test plan. Expected results were
tighter, and the communication between Horizon and TIP during
the preparation of the scripts assisted in the checking of expected
results both at TIP and on the counter.
¢ Finally, the daily progress meetings were invaluable for keeping
all parties together on the schedule, but also for providing
continuous updates on outstanding incidents, which gave the
entire group a better understanding of the serious issues, and the
status of the cycle at that time.
Version Draft 0.1 Page 16 of 73 Date 29/03/99
POL00028419
POL00028419
I
End to End Testing Evaluation Report for Nile Release 2.0
7 TEST RESULTS
The following section details the statistics obtained during the E2E
cycle. This includes;
e Anassessment of performance against pre-defined test conditions
¢ Areview of the 82 incidents raised during previous test cycles, that
were declared for retest within E2E Final.
© Details of new incidents raised during E2E Final.
The following pages breakdown this information, by Product Area
and then by System or Interface.
Asummary of the test condition results is as follows;
100
HHI THI
HITT
HLT
ILLIA]
HLT {III
HHI
APS: oBcs Migration = FieTd. Helpdesk = Fatback ‘EPOSS ACUA BES Rol. Dota
Total
Conditions Passed 418
Conditions Failed 9 96.3 %
Conditions Not Run 7 Passed “*
Conditions Planned 434
** This figure does not imply that 3.7 % of conditions failed.
Version Draft 0.1 Page 17 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
The results of the incident retesting activities are as follows;
400 100 100
400 as GPassed %
50 J—
80 I—
70 j—
co I—I
so I—
40 I—I
30 i—I
20 I—I
10 4—
o
ACUA oscs ™!? —POss
High I Medium I Low I Closed I Total
Retests failed 0 1 0 1
Retests not covered 0 1 5 0 6
Retests cleared 4 40 22 9 75
Retests outstanding 0 0 0 0 0
Retests declared 4 42 27 9 82
** This figure does not imply that 8.5 % of retests failed. Some retests
were not covered.
91.5 %
passed **
Version Draft 0.1
Page 18 of 73
Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
‘ An overview of new incidents raised during E2E Final (as at
17/03/99);
Outstanding
A. .
ACUA —OBCS
Poss. TP BSU Migration CAPS. APS —Re.Data
High I Medium I Low I Unclassified I Total
Raised during E2E Final 12 78 105 15 210
New Incidents Closed 31 51 15 102
Outstanding New 7 47 54 0 108
Incidents
Version Draft 0.1 Page 19 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
71 Horizon End to End
7.1.1 Access Control / User Administration (ACUA)
7.1.1.1 ACUA Test Conditions
Test Conditions Planned : 28
Test Conditions Passed : 27
Conditions Failed/Not Run: 1
7.1.1.1.1 Details of Conditions failed / Not Run
Description Reason.
Deleting an Individual Stock Unit IThe system identified the stock unit as having stock!
levels and transactions in the current CAP, therefore]
we were unable to delete the stock unit.
7.1.1.2. ACUA Retests
High I Med I Low I Total
Retests Passed - - 1 1
Retests Not Covered - - - -
Retests Failed - - - -
Retests Planned 0 0 1 1
711.21 Details of failures
None
7.1.1.3 New ACUA Incidents
High I Med I Low I Total
New Incidents Raised - 1 1 2
New Incidents Closed. - 1 - 1
New incidents Outstanding 0 0 1 1
7.11,3.1 Details of Outstanding ACUA Incidents
Issue Ref. I PinICL I Description Priority
IR390 (*) 21726 I Cannot delete a stock unit - When attempting to delete I LOW
a stock unit the message ‘cannot delete stock, still has
stock' appeared. A snapshot was produced which
confirmed that the stock levels were Nil. The stock
levels were adjusted to zero in the previous CAP.
Version Draft 0.1 Page 20 of 73 Date 29/03/99
POL00028419
POL00028419
7 : ‘
End to End Testing Evaluation Report for Nile Release 2.0
7.1.1.4 Observations
(*) Denotes outstanding incidents currently scheduled for Target
Testing.
7.1.1.5 Overall Testing Status of Product
GREEN
Version Draft 0.1 Page 21 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
7.1.2 Automated Payment Service (APS)
7.1.2.1 APS Test Conditions
Test Conditions Planned : 3
Test Conditions Passed : 3
Conditions Failed/Not Run: 0
7.1.2.1.1 Details of Conditions failed / Not Run
None
7.1.2.2 APS Retests
High I Med I Low } Total
Retests Passed - - - 0
Retests Not Covered - - - 0
Retests Failed - - - 0
Retests Planned 0 0 0 0
7.1.2.2.1 Details of failures
None
7.1.2.3 New APS Incidents
High I Med I Low I Total
New Incidents Raised - 2 3 5
New Incidents Closed yo- 1 1 2
New incidents Outstanding 0 1 2 3
7.1.2.3.1 Details of Outstanding APS Incidents
Issue Ref.
PinICL
Description
Priority
IR 415 (*)
21742
Stock Unit APS Transaction List does not report a
transaction entered onto Horizon (British Gas Trading
Ltd) -
APS Transaction List produced with a missing Magcard
transaction, APS No 010009, Client: British Gas Trading
Ltd, Ref: 9826103220000009695 for £21.03. Bar-coded
Bill transaction for £51.28 is also printed out of line.
Could be similar to IR 389,
Medium
IR375
CP 1716
APS Transaction Summary prints out of line - Produced
an APS Transaction Summary containing 2
transactions, Client details printed correctly but the 2nd
transactions Type and Value were mis-aligned.
LOW
Version Draft 0.1 Page 22 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
IR 436 (*) I 22137 Reversal of an AP transaction Increases the volume on I LOW
the Stock unit Snapshot -
Processed an AP transaction and then reversed it by the
AP reversal method. Produced a Stock Unit Balance
Snapshot which reported a volume of 2 and a value of
£0.00 for BG pymt and Welsh Water Bill under
Automated Payments.
7.1.2.4 Observations
Reconciliation throughout the environment was successful.
(*) Denotes outstanding incidents currently scheduled for Target
Testing.
7.1.2.5 Overall Testing Status of Product
GREEN
Version Draft 0.1 Page 23 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
7.1.3 Benefit Encashment Service (BES)
7.1.3.1 BES Test Conditions
Conditions Planned : 220
Conditions Passed : 208
Conditions Failed/Not Run: 12
7.1.3.1.1 Details of Conditions failed / Not Run
CAPS Description Notes
Reference
CAPS-027 IAnswer first customer verification _ questionISee IR 411
incorrectly, followed by answering the second
customer verification question incorrectly.
CAPS - 425 IOne-off payment(s) due same day received from HBS ICAPS Dialogue error, Urgent!
on-line. payment failure, payment!
picked up by batch.
CAPS-558 ICustomer with Alternative Payee and Permanent Problems with a date of death!
Agent (Alt Payee and Agent are same person / have being input and removed onI
same NINO): Alternative Payee attends NPO and the case, caused this condition
attempts to collect customers CHB and other benefits _Ito fail.
when customer has been recorded as being deceased.
CAPS -591 IContact the helpdesk when the batch of cards has been ISee IR 481
stopped.
CAPS-81 {Customer has an uncarded casual agent who collects +ICAPS incident F990300041
customers payment and milk token.
CAPS - 048 IDuplicate Payments. (Customer and other payee cash INot Run
(*) same payment at different Post Offices
simulataneously or while one of the PO's is
disconnected (e.g. during ISDN failure).
CAPS -011 INON-URGENT - Scan bar-code on batch identifier slipINot Run
lon jiffy bag/sealed tray to receive batch of cards.
CAPS - 286 IStanding Agent (A) attempts to collect own payments INot Run
(*) which have already been collected by Standing Agent
(8) ;
CAPS-66 ITemporary Tokens - Ensure BES transactions are Not Run
Precommitted.
CAPS -594 ICustomer attempts to make an encashment but their {Not Run
card has expired.
CAPS-010 IURGENT - Scan bar-code on batch identifier slipon {Not Run
jiffy bag/sealed tray to receive batch of cards.
CAPS-54 ICustomer at foreign post office, previous foreign INot Run
encashment limit reached. New period starts.
Version Draft 0.1
Page 24 of 73
Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
7.1.3.2 BES Retests
High I Med I Low I Total
Retests Passed 1 4 3 8
Retests Not Covered - - - -
Retests Failed - 1 - 1
Retests Planned 1 5 3 9
71.3.2.1 Details of failures
Record No
Incident I Brief Description Priority
counter.
IR312 [BES Payment available at Helpdesk, but not at} Medium
7.1.3.3 New BES Incidents
High I Med I Low I Unclassified
Total
New Incidents Raised 4 6 29 3
New Incidents Closed - - 15 3
18
New incidents Outstanding 4 6 4 0
7.1.3.3.1 Details of Outstanding BES Incidents
Issue Ref. I PinICL
Description
Priority
mR411(*)_ I 21921
Missing EVP questions during card activation -
On activating this card we were supposed to answer
two EVP questions incorrectly resulting in a PUN
impound. EVP was not invoked and the card was
activated. All the data required to enable EVP was
witnessed as correct at the Helpdesk. As a further test
we used the same card to begin a change of NPO ata
foreign office, which should invoke EVP. EVP was not
invoked which suggests a localised problem with
card."
High
TR 458 (*) I 22357
Payments available at the PCHL, not accessible at the
counter -
Case E6, NINO ‘On swiping this customers
card and attempting to encash payments AP1 & AP2
(total = £119.40) the message "No payments
available..." was displayed. The PCHL was checked
and the payments were shown as being available. As
the card had only just been activated as part of the
same script, a priority message was sent to eliminate
the possibility that the payments were not available
because the card activation had not been harvested at
the PCHL. This had no affect and the payments had to
High
Version Draft 0.1 Page 25 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
Issue Ref.
PinICL
Description
Priority
be encashed via the PCHL.
IR 469 (*)
22580
Payments available at the counter, not showing at the
PCHL-
Case A6, NINO & : There have been various
problems attached to this Case stemming from a D.O
D being. -input, and temoved for the
two Child’ Benefit Payments totalling £22.10 available
at the Counter (2 @ £11.05, due dates 01/04/97 &
08/04/97) and only one of these payments (due date
08/04/97) available at the PCHL.
High
IR 46 (+)
22494
Extra payments available during BES encashment.
When attempting to encash a payment for £11.05 ata
foreign office (E), a payment that was collected on day
16 at office A for £11.05 was also payable, making the
total encashment £22.10.
High
IR 445 (*)
22245
Not all transactions are reported to the Office Weekly
BES Reconciliation report -
When obtaining a BES Office Weekly Reconciliation
Report only transactions that have been input
normally before the ISDN Line was removed report to
the Summary. None of the recovered transactions
report to the Summary.
The office has rolled BP once following migration.
Medium
21054
Could not produce a BES Weekly Encashment Report
for a previous CAP - After rolling stock unit BA into
CAP 01 the system would not produce a report for
BES weekly for CAP 52. There is a screen in which a
different CAP can be selected but if any other than the
current CAP to which it defaulted was selected, it
would not allow a report.
Medium
TR 430 (*)
17586
BES lock applied when Customer/Alt.Payee encashes
as one payee role, finishes the transaction and the
attempts to encash as another ‘payee role-
Case A12 (NINO! is a customer in their
ight and also an AltPayee for Case A11 (NINO
_}. The customers! card was swiped at foreign
‘office "EN, payments for the customer and for Case
A11 were visible on the stack. The payments for the
customer were encashed and the transaction finished.
We then swiped the card again and attempted to
encash the payments for Case All and the "No
payments available." message displayed. On
investigation it was found that a BES lock of 30-mins
had been applied to the payments and as a result we
were able to make the encashments after this time
period had elapsed.
Although this is how the system has been designed to
Medium
Version Draft 0.1 Page 26 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
Issue Ref. I PinICL I Description Priority
work, is this in the best interests of customer service?
1R437(*) I N/A Inability to perform BES mis-match recovery during I Medium
an extended Cash Account -
Office A has had its Cash Account extended to CAP 4,
which commences on 17/04/97. Therefore if a PCHL
encashment is made during this extended Cash
Account period and recovered incorrectly onto
Horizon at Office A using a current date, the system
will search for a date in CAP 4 and display the
message "The Date entered is not in the current
CAP...".
E.G. PCHL encashment made today 02/04/97,
recovered incorrectly and today’s date input
(02/04/97), the system will search for a date from the
17/04/97 onwards as this is the CAP it believes the
Office to be in.
This has already been discussed with Pathway.
IR 470 23086 E2EFP - Contingency File Error Reporting Medium
08/03/1999 15:57:04 - By Peter Ashley
On Day 25 of End to End Final Pass a Contingency file
was produced by
Pathway, for Service 2 (CPD5) and sent to CAPS.
Pathway's Outward Control
log shows successful validation by CAS and CAPS,
with a status 40 (File fully
accepted) being issued by CAPS on 04/03/99 at 15:49.
CAS has since updated
the status 40 to 99 (Entry complete, awaiting deletion
by CAS Housekeeping).
On 08/03/99 Pathway received an error file (Type 20)
for the Service 2
Contingency file. The error file contains the following
CAPS errors: 14026,
14027, 14028 and 14029; all relate to reconciliation
failures.
The type 20 file is unexpected. Errors are reported
following the status 30
entry in the control log.
IR 478 23097 During End to End Final Pass an examination of the I Medium
PASCMS database prior to the contingency
highlighted an Authorised payment for) _
Further investigation showed that the following
scenario had taken place in relation to this case:
1. Payment made to beneficiary and permanent agent
/ 2. Beneficiary made EOI / 3. Contingency payments
Version Draft 0.1 Page 27 of 73 Date 29/03/99
End to End Testing Evaluation Report for Nile Release 2.0
POL00028419
POL00028419
Issue Ref.
PinICL
Description
Priority
made in CAPS fallback
In this case the Contingency payments process would
have decided that an authorised payment would be
created for the agent but not for the beneficiary (since
they were EOI). This would result in the beneficiary
not being present in the CAPS payments contingency
file. A CAS validation failure would result. The
original rules dictated that payments were invalid if
the beneficiary could not encash and did not have an
appointee (as in this case). No authorised payment
should therefore have been made to either the
Beneficiary, or any payment_payee.
The matter was passed to Tony Haywood for
comment and he responded with the following:
1, Payment made to beneficiary (encash_by_ben = 'Y')
and permanent agent, (which I believe is an invalid
business scenario). The beneficiary can encash but
has decided they want a Permanent Agent who can
encash on their behalf.
2. Beneficiary made EOI. Beneficiary is made CMS
EOI for two main reasons - either death or an
Appointee is set up. In both cases CAPS will
immediately recall (Stop) any uncollected payments
for both Beneficiary and the Permanent Agent. The
payment stops will remove the payments from the
mandate table.
3. Contingency payments made in CAPS fallback. The
payments have been removed from the mandates
table, thus there will be no Contingency payments to
either the Beneficiary nor to the Permanent Agent.
The scenario was invalid simply in that when the
Beneficiary is made CMS EOI, all outstanding
payments are stopped.
IR 464
N/A
BES lock when attempting to use the same card to
make simultaneous encashments at two separate
offices -
Case A1, NINO The encashment process
was started at Office "A", the payment left on the
stack but not finished. The same card was then used
to attempt to encash the same payments at Office "E".
As expected the payments were not available at Office
"E" as the payment had already been locked at "A".
Previously when testing this scenario the user was
then able to return to "A" and make the encashment.
Now on attempting to "Finish" the transaction at"A" a
caption bubble is displayed stating "Warning.The
status of this payment has changed. Card ID...Please
remove this transaction before settling and perform
the payment again."
This message would be more user friendly if the word
Low
Version Draft 0.1 Page 28 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
Issue Ref. I PinICL I Description Priority
"remove" was replaced with "void", also, if the
customer at "A" was making encashments in more
than one payee role which payment would have to be
removed or would all pyments be affected.
Finally on attempting to "perform the payment again"
we found that a BES lock had been applied to the
payment, as a result the payment could not be
encashed for a further 30-mins. This is not customer
friendly.
TR 446 19959 What message should the counter/receipt display I Low
when a BA customer with a GROI in place attempts to
encash their payments at an office not within their
territory -
Case A16, NINOI.GRO__! NPO "A" 004 038: On
attempting to make an encashment for this customer
at Office "D" which is a Northern Ireland office, the
system displays the usual "No payments available..."
message as does the BES receipt produced. Should
these not give more information relating to the fact
that the customer is in the wrong territory?
This also happens when the same scenario i:
performed at the PCHL (Case C12, NINO: GRO
NPO "C" 007 261). ‘ “
IR 481 23125 A previously stopped batch of cards not showing as I Low
"Stopped" when received at the counter -
Batch No. DT000000408GB, Cases D5 (A,B & C): This
batch was previously stopped via the PCHL on Day
19 (04/04/97). On attempting to receive the batch
today we were expecting the system to display a
message prompting that "This batch of cards has been
stopped..." at the point of the batch code being input.
This did not happen, but on reconciling the cards the
system did prompt that the individual cards had been
stopped.
We were informed that the system was working as
designed, but after further reflection, and having
spoken to the BES Product Manager, we would still
like the batch to be displayed as "Stopped" at the
point of the batch code being input.
An example of why we would like this change to be
made would be: The time wasted by a stopped batch
containing 50 cards arriving at an Office and the clerk
having to receive the cards.
IR 472 22614
The inbound CAPS data files for End to End Final I Low
Pass (Day 24) have been checked against the plan. The
following errors were identified: .
1. Case AI2i GRO I Uncarded Casual Agent
Version Draft 0.1 Page 29 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
Issue Ref.
PinICL
Description
Priority
details missing (inserted as
an amendment 9/2/99).
2. CAse B07 {I GRO__} Customer details/Card
request not expected.
IR362(*)
21632
Card Impounded at the counter not harvested to the
Helpdesk -
During the activation of this card, the PUN details
were entered manually (due to earlier issues
surrounding batch numbers). This worked OK. EVP
was answered successfully and the card was then
swiped to activate it. At this point the message "The
card swiped differs from that expected. Check the
card and reswipe to correct mistake or press impound
to impound the card" was displayed. The card was
reswiped with the same result and then impounded.
The following day it was noticed that the status of the
card on the attached batch printout was "rec" instead
of "stp". This was checked at the helpdesk and
confirmed on day we attempted to issue this card to
make an encashment and after entering the card
details manually the system informed us that the card
was already impounded and then impounded the
Low
TR473
23003
Temporary Token not able to arrive at the Horizon
counter -
Case A12, NINO I I.A Temporary Token was
due to be available at the counter for this Uncarded
Casual Agent on Day 24 (09/04/97), but it was not.
The test was first deferred to Day 30, then Day 31 and
finally Day 32. When the TT was again unavailable on
Day 32 the decision was taken to stop attempting to
send the file.
The problem appears to be with the issuing of the TT
by CAPS.
Low
TR 426 (*)
22257
When attempting to encash a BES encashment, system
crashed -
After swiping a BES card to obtain payment a
Windows dialog box appeared ststing: ‘HEAP
MANAGER CLICK OK TO CONTINUE’. When OK
was pressed the desktop crashed and returned to
Windows. The system was then restarted and the
payment was obtained.
Low
IR412
21920
Previously stopped card still able to be received as
part of a batch -
This card was stopped by CMS, due to the customer
changing their NPO, before the batch containing the
card was received. The batch report produced daily
Low
Version Draft 0.1 Page 30 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
Issue Ref.
PinICL
Description
Priority
shows the card as "Stopped". On receiving the batch
containing this card we WERE able to receive the
card, the system should display a message stating "
that the card has been previously stopped, please
retain the card..",
IR477
23013
Failed Precommittal of a scanned Temporary Token
after enforced Lock Out -
Case D4(A), NINO {. The TT was scanned
and the payment of £11.05 viewed on the BES
encashment screen. The system was then left on this
screen for a minimum of ihr 29mins to invoke the
enforced Lock Out process. On returning to the
system the Lock Out had been enforced, but, after
producing a BES Daily Encashed report it was found
that the payment had not been "forced committed".
On scanning the TT again we were then able to encash
the payment again.
Low
TR 402
21853
An examination of the Pathway Acceptance File
(AF19970327006) for day 11
indicated that the file contained the following
exceptions:
See PinICL - 21853
Low
IR 400
21867
BES Reconciliation Report is not reporting the correct
Tokens - There is a nil value against the word Tokens
on the Office BES Reconciliation Report. If this means
milk tokens the figure should be 3.
Low
IR367
19439
Carded Casual Agent details do noy appear on screen
or on the ATP receipt - A casual card agent
Transaction was performed using the above cards.
Both cards were swiped correctly. When the
encashment screen was displayed no reference to the
CCA details were shown, therefore unable to verify.
When the BES receipt was printed CCA details were
also missing.
Low
TR 443
17341
E2EFP - Pathway 39 rejected by CAPS with 59
See PinICL - 17341.........Fix in Live
Low,
IR 482
22981
A contingency file was sent on Service 2 (CPS320.
The OCL shows a status 10,
20 and 30 but the status 40 remains outstanding.
It is understood that the Contingency file was
processed successfully.
Version Draft 0.1 Page 31 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
7.1.3.4
7.13.5
Observations
This area currently contains more than 50% of the outstanding
number of HIGH incidents, of which all are included within Target
Testing.
However the success rate of the planned test conditions along with
the complexity of the tests within E2E, and the inclusion of multiple
benefit types ie. JSA, IS and ChB, have proved this area of
functionality to be sufficiently stable to support a single benefit
release.
(*) Denotes outstanding incidents currently scheduled for Target
Testing. .
Overall Testing Status of Product
AMBER - Pending results of Target Testing.
Version Draft 0.1 Page 32 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
71.4 Electronic Point Of Sale Service (EPOSS)
7.14.1 Test Conditions
Test Conditions Planned : 122
Test Conditions Passed : 120
Conditions Failed/Not Run: 2
7.14.1.1 Details of Conditions failed / Not Run
Description Reason
Produce an Office Weekly P&A P2311MAJThis report did not display theI
Summary. appropriate information.
Produce a counter Daily APS Transactions]When producing this report there}
Summary. were various problems, where the
report did not total all the
transactions or that it did not
include transactions on the report
itself.
7.1.4.2 EPOSS Retests
High I Med I Low I Total
Retests Passed 1 7 9 17
Retests Not Covered - 2 3
Retests Failed - - - 0
Retests Planned 1 8 Bu 20
7.14.21 Details of failures
None
7.1.4.3 New EPOSS Incidents
High I Med I Low I Unclassified I Total
New Incidents Raised 18 31 11 60
New Incidents Closed 4 14 11 29
New incidents Outstanding 4 7 0 31
7.14.31 Details of Outstanding EPOSS Incidents
Issue Ref. I PinICL Description Priority
Version Draft 0.1 Page 33 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
IR 358 (*)
21865
Fees on Giro Deposits Daily Summary, printed in a
smaller font to the rest of the report - When producing
a counter Daily Summary for Giro Deposits, the fees
total font, was smaller than that of the amounts total
font. This was not what had been produced in previous
cycles or ata recent Peritas training event.
Medium
IR356 (*)
21599
Counter printer ‘locked' when paper was low, with the
only means of escaping, to re-boot the terminal - After
selecting to print a receipt, the device lock message was
shown on the screen, this was due to the paper being
low. Having changed the paper, the receipt was
automatically shown on screen, after escaping from this
screen and trying to reprint the receipt, nothing
happened. The 'Desktop' Icon was now 'No Entry’,
leving the only option to reboot the terminal.
Medium
IR 395 (*)
21573
Office Balance report prints incorrect details - When
producing an Office Balance report after invoking a 3
week Cash Account option it showed 7 times the
amount of Stock and MOP compared to that on the
Stock Unit report and Office Trial. There were also
transactions appearing that were not processed in this
CAP.
Medium
IR 398 (*)
21864
Wrong line number recorded on Redeemed Stamp
Summary for British Gas Stamp - Cash Account line
code for British Gas should be 10 - 05, but it was
recorded as 10 - 61 on Redeemed Stamp Summary. the
format of the summary is different than the one shown
on Horizon OPS reports and receipts.
Medium
IR 476
22200
Trial cash account was entitled ‘SNAPSHOT’
After producing a cash account snapshot at 11:15, we
then produced a trial and rolled over, this trial cash
account was headed ‘SNAPSHOT’.
Medium
TR 438 (*)
21573
The Trial and Final Office Balances report different
figures -
Produced a Trial Office Balance for Office B which
reported correctly.
Produced a Final Office Balance ‘which reported an
amalgamation of Week 52 and Week 01 figures.
The cash account balance reports correctly.
Medium
IR 447 (*)
22230
Volumes for P & A Allowances is not correct on the
Cash Account -
The volume for P & A Allowances on the P2311ma is 6,
the volume for Allowances on the Cash Account is 5,
the correct figure is 6. The volume for Pensions is 5
which is reporting correctly to the Cash Account.
Medium .
Version Draft 0.1 Page 34 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
R448 (*)
22244
P & A Summary P2311(MA) does not report all P & A
groups -
P & A Summary P2311(MA) only reports P & A groups
that have transactions against them. All P & A groups
should report to the P2311(MA) summary with or
without volume and value.
Medium
IR 449
22149
When attempting to obtain a Cash Account during a
printer failure the system does not automatically offer a
preview -
- Produced a Cash Account Snapshot via the printer
- Disconnected the printer
- Attempted to produce a Cash Account Trial Report
- System invoked Windows dialogue box: Pressing
cancel system returns to print screen.
- Manually invoked preview.
Medium
TR 453 (*)
N/A
When Attempting to produce a cash account snapshot,
the system hung...
Attempted to produce the Ist cash account snapshot
after balancing the office the previous night, the system
displayed the cash account preperation screen, then
hung. The desktop was taken down, rebooted, then
attmpted again, the same result was achieved. The
system was then switched off, rebooted, an office
balance report was produced, and then attempted to
again produce a cash account snapshot, the system once
again hung.
The system was then taken down while the ISDN line
was re-connected and a copy of the message store was
taken. This was examined by Pathway development, a
fix was implemented and the ISDN line was
disconnected. The system was then re-booted, and the
cash account was produced..
Medium
IR 455 (*)
22326
When producing a Suspense Account Report, system
processing time is too long and only limited
information produced -
When attempting to print a Suspense Account Report
on the Ad printer the system takes 20 minutes to
produce a report, whereas at another office it only takes
a few minutes. The screen message during printing
stated that it is printing the Uncharged Receipts, this is
all it printed, the Unclaimed Payments were missing.
Medium
Version Draft 0.1 Page 35 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
IR 456
22327
When attempting to reverse a non-reversable product
the system remains on the reverse screen after
accepting the non-reversable message -
Entered a non-reversable Game License Occassional
onto the system and then attempted to perform an
existing reversal. System invoked a screen message
advising that this was not reversable. Accepted this via
the green tick icon and only one of the two messages
disappeared leaving a message ‘screen check for
reversals complete’. The system does not automatically
return to Desktop.
Medium
TR 468
N/A
According to the Reports and Receipts OPS the
"Discrepancies Table" should appear on page 1 of the
Cash Account but it actually appears at the bottom of
Table 5.
Medium
1R396 (*)
21671
Event Log reporting Customer Session receipts as
"Report Office Snapshot" - Customer Session receipts
for scripts 3101, 3113, 3095, 3089 and 3119 which have
the Ref numbers 1-1625, 1-1635, 1-1640, 1-1648 and 1-
1655 were reported to the Event Log but appeared as
"Report Office Snapshot"
Medium
IR365
21644
Extended CAP option does not appear to work from
CAP 52 onwards - On requesting an extended CAP
from Week 52 for a 3 week period the following screen
message was displayed "You cannot extend the rollover
because the requested week is in a different cah account
week",
Low
TR 385 (*)
21771
BES summaries not reporting to the event log
IR383
21776
Wrong volumes appear on transaction log following
‘I stock adjustment - On examination of the transaction
log, it was found that during stock adjustment, when
entering adjustments to transactions with no volumes
the system asigns the volume from the previous
adjustment instead of a volume of 1.
Low
IR381 (*)
21671
Event Log does not display the production of Rem In
Report - Printed Event Log, expected it to display ‘Rem
In Report Printed' but it did not. 'Report was not
produced! .
Low
IR374
21674
Missing and Mis-leading options when producing a
Transaction Log using 'CAP' Icon - When selecting a
Transaction Log via the CAP Icon the system invoked a
pick-list of options. Options CAP52/BP01 worked
correctly, CAP52 worked correctly but Next CAP was
mis-leading and produced all the current CAP
transactions. The icon to select the current BP was
missing.
Low
Version Draft 0.1 Page 36 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
IR 410
20205
When producing Counter Daily Summaries when no
transactions have been processed withdrawals and
Deposits print different results - No Giro Deposit and
Withdrawal transactions performed. Produced Giro
Deposit and Withdrawal Counter Daily Summaries. On
the Counter Daily Giro Withdrawal Summary the cash
value box is completely blank. On the Counter Daily
Giro Deposit’Summary the cash value box has 0.00.
This is inconsistant.
Low
IR 364 (*)
21671
Event log displays multiple entries for “Report
Transaction Log" - Produced an Event log at end of day.
On examination found that there were 9 entries for
"Report transaction Log" when only 1 had been printed.
Low
IR376
21012
On Stock Unit Snapshot ‘First Class Self Adhesive
Stamps' is mis-aligned - After producing a Stock Unit
Balance Snapshot all products except the ‘First Class
Self Adhesive Stamps ' title are aligned.
Low
IR 404
21904
Session number on Counter Weekly Rems In Report is
incorrect -
Counter Weekly Rems In Report displays session
number as 7261 - 1 - 2047, with Date/Time underneath.
Horizon OPS Reports and Receipts states that the
session should be e.g. 1 - 15578 with the Date/Time on
the same line.
Low
R409
21913
After an enforced log out whilst still having a
transaction on the stack the session receipt indicated an
amalgamation of the last 2 customer sessions -
Processed an Error Notice Giro Withdrawal, settled the
sesson and produced a receipt. Entered a BES
encashment onto stack, activated the temporary lock,
left system for an additional hour, system enforced log
out, logged back onto the system and produced a copy
receipt (could not produce an original receipt). On the
copy receipt both the Giro Error Notice and the BES
encashment were present and the settlement was the
net of the 2 transactions.
Low
IR417
21039
During log on, when a revaluation message is printed,
the system will repeat the message if 'OK' Icon is
selected -
When the 'OK' Icon has been selected another
revaluation message is printed and the screen message
reappears. The only way tostop this from reoccuring is
to select desktop. This is now the second occurrence of
this problem, as it happened on day 13 at office B.
Low
Version Draft 0.1 Page 37 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
IR 420
21979
When logging on after a non-testing day the system did
not envoke an ONCH declaration -
When logging onto Stock Unit BA, which is a
individual stock unit, for the first time, but not the first
activity that had been carried out on counter i.e.
another stock unit had processed transactions. There
was not an ONCH declaration for 30/03/97 enforced.
All other stock units were required to declare there
ONCH figures during initial log on. The 2 other stock
units were both the first to log on at each node of the 2
nodes,
Low
IR 421
21978
UKPA PO Chge description on the Stock Unit Daily
UKPA Summary is incorrect -
UKPA Daily Summary recorded the UKPA Post Office
Charge as 'UKPA acc charge’, should be 'UKPA PO
Chge' as stated in the OPS reports and Receipts.
Low
IR425
22050
Entering an ordinary P & A foil transaction onto the
Horizon system, was not possible as there were no
Icon's to complete this transaction.
There should be a means of entering normal P&A foil
transactions onto the Horizon system, in order for
correct reporting to both reports and Cash Accounts.
THIS TRANSACTION HAS NO LINK TO OBCS
TR429
18754
Following a system enforced log out the items on the
transaction stack were not commited -
Postage stamps and AP transaction were on the
transaction stack and at the settlement screen the
system was left to time out. When the system was
logged back on a receipt was produced but only the
previous transaction was available. Produced a
transaction log which did not contain the postage and
AP transactions.
TR 439 (*)
20537
After balancing the office and rolling into the next CAP,
(02) the DEF Stock remains in CAP 01-
Produced an Office Balance Snapshot
Produced an Office Balance Report
Rolled office into next CAP to CAP 02
Produced a Cash Account Snapshot
Produced a Cash Account Balance Report
Rolled over Cash Account to CAP 02
Checked Stock Unit status - DEF Stock still shows CAP
01.
Low
Version Draft 0.1 Page 38 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
IR 405 19808 Parcel traffic print out on Counter displays I Low
unneccessary additional details -
Parcel traffic Report produced by a Stock unit contains
volume and value figures but it also displays a single
item value which is incorrect and not required.
However it does not affect Table 12 on the Cash
Account.
7.1.4.4 Observations
In general the EPOSS functionality performed well throughout the
E2E final pass. The main areas where incidents occurred are in the
reports and summaries, the incidents deemed to have the highest
impact on Live Trial are scheduled for Target Testing.
(*) Denotes outstanding incidents currently scheduled for Target
Testing.
7.14.5 Overall Testing Status of Product
GREEN
Version Draft 0.1 Page 39 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
71.5 Fallback & Recovery
7.1.5.1 Test Conditions
Test Conditions Planned : 23
Test Conditions Passed : v2)
Conditions Failed/Not Run: 0
715.11 Details of Conditions failed / Not Run
None
7.1.5.2 Fallback & Recovery Retests
High I Med I Low I Total
Retests Passed - 1 - 1
Retests Not Covered - - - 0
Retests Failed - - - 0
Retests Planned 0 1 0 1
7.15.2.1 Details of failures
None
7.1.5.3 New Fallback & Recovery Incidents
High I Med I Low I Total
New Incidents Raised - - 0
New Incidents Closed. - - 0
New incidents Outstanding t') 0 0 0
7153.1 Details of Outstanding Fallback Incidents
None
7.1.5.4 Observations
None
7.1.5.5 Overall Testing Status of Product
GREEN
Version Draft 0.1 Page 40 of 73
Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
71.6 File Transfers
7.1.6.1 Test Conditions
Test Conditions Planned : 2
Test Conditions Passed : 2
Conditions Failed/Not Run: 0
7.1.6.1.1 Details of Conditions failed / Not Run
7.1.6.2
None
File transfer Retests
High I Med I Low I Total
Retests Passed - - - 0
Retests Not Covered - - - 0
Retests Failed - - - 0
Retests Planned 0 0 0 0
7.1.6.2.1 Details of failures
7.1.6.3
None
New File transfer Incidents
High I Med I Low I Total
New Incidents Raised - - - 0
New Incidents Closed - - - 0
New incidents Outstanding 0 0 0 0
7.1.6.3.1 Details of Outstanding File transfer Incidents
7.1.6.4
7.1.6.5
None
Observations
In the final pass the file transfers were consistently successful,
enabling day to day running and data reconciliation on a daily basis.
Overall Testing Status of Product
GREEN
Version Draft 0.1 Page 41 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
7.1.7 Helpdesks
7.1.7.1 Test Conditions
Test Conditions Planned : 28
Test Conditions Passed : 28
Conditions Failed/Not Run: 0
7.1.7.1.1 Details of Conditions failed / Not Run
None
7.1.7.2 Helpdesk Retests
High I Med I Low I Total
Retests Passed - - - 0
Retests Not Covered - - - 0
Retests Failed - - - 0
Retests Planned 0 0 0 0
7.1.7.2.1 Details of failures
None
7.1.7.3 New Helpdesk Incidents
High I Med I Low I Total
New Incidents Raised - - - 0
New Incidents Closed - - - 0
New incidents Outstanding 0 0 0 0
71.73.1 Details of Outstanding Helpdesk Incidents
None
7.1.7.4 Observations
None
7.1.7.5 Overall Testing Status of Product
GREEN
Version Draft 0.1 Page 42 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
7.1.8 Migration
7.1.8.1 Test Conditions
Test Conditions Planned : 5
Test Conditions Passed : 5
Conditions Failed/Not Run: 0
7.18.1.1 Details of Conditions failed / Not Run
None
7.1.8.2 Migration Retests
High I Med I Low I Total
Retests Passed - - - 0
Retests Not Covered - - - 0
Retests Failed - - - 0
Retests Planned. 0 0 0 0
7.1.8.2.1 Details of failures
None
7.1.8.3 New Migration Incidents
High I Med I Low I Total
New Incidents Raised - 1 7 8
New Incidents Closed - - 1 1
New incidents Outstanding 0 1 6 7
7.18.3.1 Details of Outstanding Migration Incidents
Issue Ref. I PinICL I Description Priority
IR389 21742 Only Pre-Migrated figures showed on AP summary, I Medium
none of the current days transactions appeared - After
processing 3 AP transactions in the current day, an AP
daily summary was produced only the Migration
amount was shown on the summary. The transactions
that were performed on that day were missing. The
report was cut off and then a NIL receipt was produced.
IR380(*) I 21784 All Weekly Summaries for CAP 52 BP 02 includes BP 01 I Low
transactions - Weekly Stock Unit summaries P&A,
MVLs, and Green Giros for BP 02 have included
transactions (migrated transactions) performed in BP 01
but do not appear on Stock Unit Balance Snapshot for
CAP 52 BP 02.
Version Draft 0.1 Page 43 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
IR378 (*)
21784 Counter Daily Summaries includes Day 6 transactions - I Low
Counter Daily Summaries produced on day 8 includes
migrated transactions. These migrated transactions do
not appear on the Stock Unit Balance Snapshot as
expected,
1R377 (*)
21784 UKPA transactions appear on Counter Daily Report for I Low
pre & post migration, also on the Office Daily Report but
fees report correctly - The Counter Daily UKPA Report
shows transactions and fees for pre and post migration
when it should only report post migration. The Office
Daily UKPA report also shows transactions for pre and
post migration incorrectly but the fees are reported
correctly as post migration only.
IR 369 (*)
21784 Transactions from pre-migrated BP appear on reports I Low
after migration - When producing reports for Giro
Deposits and Giro Withdrawals it was found that figures
that were migrated from either manual or Ecco offices
appeared on these reports.
IR 360 (*)
20115 Number of Giro transactions recorded on the office I Low
snapshot is different to the number of transactions
entered during Migration - 18 Giro personal withdrawal
transactions were keyed in during migration in Table
10f, but 19 were recorded on the snapshot produced
after migration.......4 Giro change giving transactions
were entered during migrtion, with 4- now reporting to
the snapshot........1 Gas/ Utility transcash and 4 ordinary
transacash are now reporting as just 4 Giro
deps/transcash,
IR353
17649 System could not migrate 30 E111 transactions that were I Low
performed in a manual office - In table 10g, lines 9172,
9179, 9178 and 9182 were not available for data entry
during migration. In order to make sure these
transactions report to the first cash account, they had to
be keyed into Horizon via serve customer, instead of
Migration.
7.1.84
7.1.8.5
Observations
The migration activities performed during final pass were successful.
It should however be noted that the input data used was targeted at
avoiding the known migration issues which are fixed in ‘Live’
reference data.
(*) Denotes outstanding incidents currently scheduled for Target
Testing.
Overall Testing Status of Product
GREEN
Version Draft 0.1 Page 44 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
71.9 Reference Data
7.1.9.1 Test Conditions
Test Conditions Planned : 9
Test Conditions Passed : 8
Conditions Failed/Not Run: 1
7.19.11 Details of Conditions failed / Not Run
IDescription Reason
(Change of Multiple selling volume I Attempt at changing the multiple selling volume on
£2 BT stamps failed, however this was later
confirmed by product management as an
inappropriate test.
Changing the multiple selling value of a fixed value
item, is currently a Release 2, exception
7.1.9.2 Ref. Data Retests
High I Med I Low I Total
Retests Passed - 1 2 3
Retests Not Covered - - 3 3
Retests Failed - - - =
Retests Planned. 0 1 5 6
7.1.9.2.1 Details of failures
None
7.1.9.3 New Ref. Data Incidents
High I Med I Low I Total
New Incidents Raised 1 0 2 3
New Incidents Closed 0 0 0 0
New incidents Outstanding 1 0 2 3
7.1.9.3.1 Details of Outstanding Ref. Data Incidents
Issue Ref. I PinICL Description Priority
Version Draft 0.1 Page 45 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
IR457(*) I 22062 System allowed shared stock unit to balance while High
holding vouchers in stock -
During a shared stock unit balance declaration,
vouchers were entered and the stock unit was balanced
and rolled into the next CAP. No warning message was
displayed that vouchers 'should not’ be declared within
a stock unit balance.
TR 462 N/A Insufficient product description on Rem In By Product I Medium
report~
- Stamp Book Cartoon is displayed as Stpbk Other
- DWS 2nd x 10 Stamp Book is displayed as DW Stmp
Bk
- DWS Stamp Book Cartoon is displayed as DW Stmp
Bk
R433 N/A The Icons for posting and redeeming Rem Surplus to Low
Suspense are incorrectly labelled -
The Icon Rem Surplus (F8) which is in Housekeeping is
the Icon used if a Rem Surplus is to be redeemed from
Suspense,
The Icon Rem Dec Surplus (F5) is the Icon to use to post
Descrepancy to Suspense,
According to the Horizon Menu Hiarachy Document:
F5 is labelled Rem Surplus
F8 is labelled Rdm Rem Surplus.
7.1.9.4 Observations
None
(*) Denotes outstanding incidents currently scheduled for Target
Testing.
7.1.9.5 Overall Testing Status of Product
GREEN
Version Draft 0.1 Page 46 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
7.1.10 Order Book Control Service (OBCS)
7.1.10.1 Test Conditions
Test Conditions Planned : 9
Test Conditions Passed : 9
Conditions Failed/Not Run: 0
7.1.10.1.1 Details of Conditions failed / Not Run
None
7.1.10.2 OBCS Retests
High I Med I Low I Total
Retests Passed - 2 - 2
Retests Not Covered - - - 0
Retests Failed - - - 0
Total 0 2 0 2
7.1.10.2.1 Details of failures
None
7.1.10.3 New OBCS Incidents
High I Med I Low I Unclassified I Total
New Incidents Raised 1 jI1 1 1 4
New Incidents Closed 1 0 1 1 3
New incidents Outstanding 0 1 0 0 1
7.1.10.3.1 Details of Outstanding OBCS Incidents
Issue Ref. I PinICL I Description Priority
IR397 21937 When encashing more than 13 OBCS foils the message I Medium
advises to encash in 2 sessions - The system correctly
informs the user that the maximum allowable amount
is 13 foils then advises to encash the 14th foil in a
different session.
7.1.10.4 Observations
None
7.1.10.5 Overall Testing Status of Product
GREEN
Version Draft 0.1 Page 47 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
7.2 External Systems
7.2.1 Business Support Unit (BSU)
7.2.1.1 BSU Retests
None
7.2.1.2 New BSU Incidents
High I Med I Low I Total
New Incidents Raised 2 14 1 17
New Incidents Closed 2 6 1
New incidents Outstanding 0 8 0
7.2.1.2.1 Details of Outstanding BSU Incidents
Issue Ref. I PinICL Description Priority
BSU 17 22966 3 Unmatched encashments were reported on PMSR100 I Medium
and PMSR103 (dated 15/04/97), after they were re-
input (unchanged) on SUPF138 the previous day.
<<< Full details available on original incident >>>
BSU 16 22959 PSR115 for transaction on 7/4/99 reports various 320 I Medium
exceptions. These are known as recovered EPOSS
orphans because they have not been matched to a
corresponding BES orphan created during fallback. In
every case on this report the 320 exceptions have date
entered in the fallback field of the report. How can this
be if an unmatched EPOSS orphan should only have a
date in the recovery field? (BES orphans are reported
correctly as in their case the recovery field is blank and
Fallback field does have a date in it.)
BSU 15 22796 On SUPF138 (maintain adjusted encashments screen), I Medium
encashment number 5050380100001260 has no
encashment details. The PAS exception code is 18, and
there should be encashment details returned from the
counter, together with encashed payments.
There is also an encashed payment on SUPF138
(6050380100001269) which is not reported as suspended
on PMSR105 or PMSR100/101. This needs to be
investigated.
Version Draft 0.1 Page 48 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
BSU 14
22730
PMSR116 (dated 12/04/97) reported as cleared all the
fallback and recovery exceptions which were
previously on PMSR115. However, the following errors
were detected: -
1- Where the PCHL encashment was voided, PMSR116
included a value. this is incorrect as the value should be
Zero (as itis on PMSR115)
2- For EPOSS orphans and BES orphans, BAD records
should be sent to TIP once the exceptions have been
cleared, yet in the column 'BAD to TIP' on PMSR116, all
of the indicators are set to 'N'. However, Linda Austin
has confirmed that BAD records were received by TIP
for these exceptions, so it appears to be a reporting
problem.
Medium
BSU 13
22534
SUPR100 (from 07/04/97 to date) reports an EPOSS
duplicate (325) in the section named ‘Exceptions
Brought Forward’, but it does not include this exception
in the Exceptions Carried Forward today' section. The
EPOSS duplicate was (correctly) automatically cleared
along with the corresponding EPOSS orphan on
07/04/97. However, only the EPOSS orphan was
reported as cleared on PMSR116 on 07/04/97. There is
no evidence of the EPOSS duplicate being cleared, and
there is still a discrepancy on the SUPR100 being
carried forward.
Medium
BSU 10
22744
PMSR 105 dated 8/4/97 for transactions on 7/4/97
reports one suspended encashment
(44000YG020035C001, 5050380100001260) for the
amount of £11.05. This suspended encashment should
also be reported on PMSR 100 and PMSR 101 under
section 3 of those reports entitled "ENCASHED
PAYMENT VALIDATION FAILURES" but it is not
reported there under activity for 7/4/97, or any other
date in that report.
Medium
BSU 07 (*)
19789
The APS Reconciliation report (National Totals) report
with report date 07/04/99 shows 11 dates in the Date
Entered / Date Harvested columns. The report is meant
to be a ten day rolling report in which case the row of
data with the date of the 4/03/97 should have come off
the report.
Medium
BSU 02
20204
The APS transaction summary report still appears to be
incorrectly structured: a. I was led to beleive that the
Giro/Non-Giro split was to be abolished and replaced
with a simple ‘Client’ column? and b. The ‘Total value
of Normal Transactions' is still in a non-monetary
format i.e. £20.00 as opposed to 2000 (which could be
misinterpreted).
Medium
Version Draft 0.1 Page 49 of 73
Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
7.2.1.3 Observations
BSU performed BES and APS reconciliation as per ‘Live’ procedures
and although anomalies still exist on the PMSR reports, the process
itself was reported to have been successful.
(*) Denotes outstanding incidents currently scheduled for Target
Testing.
7.2.1.4 Overall Testing Status of Product
GREEN
Version Draft 0.1 Page 50 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
7.2.2 Customer Accounting and Payments System (CAPS)
7.2.2.1 CAPS Retests
None
7.2.2.2 New CAPS Incidents
High I Med I Low I Total
New Incidents Raised 0 3 7 10
New Incidents Closed 0 1 5 6
New incidents Outstanding 0 2 2 4
7.2.2.2.1 Details of Outstanding CAPS Incidents
Issue Ref. I PinICL Description Priority
CAPS 140 I 23073 This TT was rejected by Pathway with 55118 - Card I Medium
(*) type invalid. The card type field was blank as the TT
was for an Uncarded Casual Agent. The DIDVR
describes this field as optional and therefore CAPS
believe that this rejection is inappropriate.
CAPS 123 I 21697 IPTE2E(R2) - CAPS Codes files produce 199 rejections I Medium
(*) when processed by Pathway
CAPS 133 I 19962 An urgent payment was attempted but PW responded I Low
(*) with error 52021 = Declaration type given does not exist
on database. The declaration type given was "000" but
page 16 of the R2 DIDVR states that this field is only
applicable if the ENC by beneficiary suggests that "000"
should be acceptable when the ENC by Beneficiary flag
is"N".
This incident has been given a LOW priority. However,
if Live Trial included a second benefit then this would
bea HIGH.
CAPS 127 I 17699 Carded casual agent cashed AP3 £20.05 at NPO, I Low
counter receipt shows payment cashed by customer
rather than carded casual agent.
7.2.2.3 Observations
None
(*) Denotes outstanding incidents currently scheduled for Target
Testing.
7.2.2.4 Overall Testing Status of Product
GREEN
Version Draft 0.1 Page 51 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
7.2.3 Host Automated Payment System (HAPS)
7.2.3.1 HAPS Retests
None
7.2.3.2 New HAPS Incidents
High I Med I Low I Total
New Incidents Raised 0 0 4
New Incidents Closed 0 0 4
New incidents Outstanding 0 0 0
7.2.3.2.1 Details of Outstanding HAPS Incidents
None
7.2.3.3 Observations
None
7.2.3.4 Overall Testing Status of Product
GREEN
Version Draft 0.1 Page 52 of 73
Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
7.2.4 Transaction Information Project (TIP)
7.24.1 TIP Retests
High I Med I Low I Closed I Total
Retests Passed 2 2 7 9 43
Retests Not Covered 0 0 0 0 0
Retests Failed 0 0 0 0 0
Retests Planned 2 Pa) 7 9 43
7.24.11 Details of failures
None
7.2.4.2 New TIP Incidents
High I Med I Low I Total
New Incidents Raised 4 28 2B 55
New Incidents Closed 2 4 13 29
New incidents Outstanding 2 4 10 26
7.24.21 Details of Outstanding TIP Incidents
Issue Ref. I Pin[CL I Description Priority
TIP 743 (*) I 22534 E2EF: BES encashments performed at Tottenham I High
(23578) on (03/04/97), encashment __ref.
505038/01/00000220 for amount £24.10. The exception
for this transaction on PMSR 115 (07/04/97) was
missing from PMSR 115 and PMSR 116 on (08/04/97).
Should have received a code 120 (EPOSS no BES) on the
BARSF (08/04/97).
TIP 738 (*) I 22744 E2EF: BARSF subfile W_097066 contained a value of I High
£763.10 against 'Total Encashments'. The ‘adjusted’ total
of encashments for this date as reported on the PMSR
101 is £729.95, a difference of £33.15. The two should
always be the same.
TIP 697 (*). I 22214 E2EF: Upon transmission file creation at Pathway, file I Medium
W_093009 was found to contain a negative session
sequence number in an OTX record for Org unit 23579
(Rhyll - non-automated). the item id within this record
was 852 (milk token). The file was edited prior to
transamission to TIP and was therfore not rejected.
TIP 665 (*) I 21809 E2EF - Newport, org unit code 23573, cash account I Medium
week 52, Electronic Cash Account record receive (CAC)
and Final Balance Office Report cash figure values
agree: £56540.43, Electronic Stock Holdings record
received (STX) = 356545.09. Difference = £4.66
Version Draft 0.1 Page 53 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
TIP 672
20212
E2EF: BARSF file W_088066 contains a BAT record for
29/03/97, with a value of £3279.60 against the
‘reconciled encashments' field. TIP expected this value
to be £1093.20, the reconciled figure appears to be 3
times expected.
Medium
TIP 683 (+)
BES E2EF - PCHL authorise BES encashment of £11.05
(NINO YA011053A). Amount recovered to EPOSS
£21.05. BAD record received. However Date of
transaction expected 20.04.96, Date of transaction
received in OTX Additional details 31.03.97. The date
sent to TIP was the date the transaction was recovered
to EPOSS (31.03.97). The date which TIP should have
been sent was the date that was keyed which was
(20.04.96).
Medium
21970
E2EF: Cash Account received for Week 1, Org Unit
23574 (Aston Villa) misbalances by £2.92 i.e. line 0700
(Receipts total) = £89,589.87 and line 1700 (Payments
total) = £89,592.79,
Medium
TIP 691 (*)
22229
Stock Holdings report Man Utd C/A Week 1
received the following record that was not on the office
printout
Name = Cheque Value =1.82 Quantity =6
Medium
TIP 705 (+)
22230
E2EF: Cash account for week 01, Office 23576 (Man
Utd), Line 4011 shows a quantity of 5. Transactions
received by TIP indicate that this line should show a
quantity of 6.
Medium
TIP 733 (*)
N/A
E2EF:BES Encashment performed at Tottenham (23578)
on (26/03/97), encashment ref. 505038/01/00001260
for £11.05 was not reported on the PMSR reports .
(ISDN Link down 10 days).
This encashment was expected to be reported on the
PMSR 104 on 07/04/97.
Medium
TIP 763
22634
E2EF: File W_101030 contained OTRAN subfile for org
unit 23576 (Man Utd) dated 09/04/97. This subfile
contained 2 OTX records with item = 914 (Produce
Final Cash Account Event) and cash account week
number = 2, There can only be one record with this item
per org unit per cash account week.
Medium
TIP 734 (*)
22477
E2EF:BES Encashment performed at Tottenham (23578)
on (26/03/97), encashment ref. 505038/01/00001218
for £11.05 was voided at PCHL and recovered as
completed transaction for £6.05. 2 BAD Records have
been received by TIP; 140 (status mismatch) with zero
values (correct), and a 100 (amoumt mismatch)
showing authorised £11.05, encashed £6.05. In this
scenario the authorised amount should have been 0,
because PCHL voided the encashment.
Medium
Version Draft 0.1 Page 54 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
TIP 711 (*)
22435
E2EF: File W_097011 received by TIP on 02/03/99
contains numerous OTRAN subfiles for org unit 23578
(Tottenham). This outlet has an ISDN failure from
26/03/97 to 06/04/97. The first subfile within the file
contains OTX records from 08:14:38 on 26/03/97 to
23:59:59 on 27/03/97 with only one EOD marker dated
27/03/97. The OTX records must be split into two
subfiles with an EOD marker at the end of each subfile.
Medium
TIP 726 (*)
22477
BES Encashment performed at Tottenham (23578) on
(03/04/97), for amount £11.05, encashment ref.
505038/99/00000214 was voided at PCHL but
recovered to EPOSS as completed. As the ISDN link
was down at the time of recovery expected exceptions
are a 320 for £11.05 and a 330 status void for £0. When
the system matched these two orphan transactions two
new exceptions should have been generated- a 310
status mismatch with zero values and a 300 value
mismatch showing zero authorised and £11.05
encashed (NB: at this point the 320 and 330 would
transfer to the PMSR 116 as cleared). 2 corresponding
BAD records should have been sent to TIP for the
exception code 300 and 310. TIP has received a BAD
record for code 310(BAD140) but not 300(BAD100).
The exceptions received on PMSR115 were 320 and 310.
Medium
TIP 722 (*)
N/A
E2EF: Session sequence 1259 for Org unit 23578
(Tottenham), Stock unit GA contains two records, i.e.
item = 37 (Stamp Book 1st x10), Txn mode = 1 (sell),
Amount = 7.80 and item = 1 (cash), Txn mode = 1 (sell),
Amount = -3.25. The session does therefore not balance.
Medium
Version Draft 0.1 Page 55 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
TIP 718 (*)
22251
BES Encashment performed at Tottenham (23578) on
(02/04/97), encashment ref. 505038/99/00000209 for
amount £11.05. (recovered to EPOSS as £15.05) has
generated two exceptions on the PMSR115. 1st is for
exception code 300 (amount mismatch); 2nd is for
exception code 320 (EPOSS no BES). Only one
transaction was recovered, therefore only one exception
expected.
The following ‘text has been added from Incident
TIP724, and 724 has now been closed.
BES Encashment performed at Tottenham (23578) via
PCHL on (03/04/97), PCHL encashment ref.
505038/99/00000223 amount £22.10 was recovered to
EPOSS with encashment ref.
teammannmennnmmanst794 amount £18.10. Which Postmaster
confirmed at end of week. Two exceptions expected. 1st
an exception code 320 (EPOSS no BES) for encashment
ref, "224 for amount £18.10 and a 2nd exception code
330 (BES no EPOSS) for encashment ref. "223 for
amount £22.10. However, three exceptions were
received for encashment ref "224 (300, 310, 320).
Medium
TIP 658
N/A
E2EF: OTRAN subfile (W_081035) for Org unit 23572,
contains a number of invalid item transaction mode
combinations: Items 340, 685, 691, 692 and 693 were all
received with transaction mode 1 (sell). The only
transaction mode applicable for all these items is 15
(housekeeping).
TIP 769
N/A
E2EF: Cash account for Tottenham (23578) Week 2
Table 2(a) Line 46 has a value of -100. Negative values
should not be allowed on this line.
TIP 698
N/A
E2EF: during E2EF OTX records have been received by
TIP for Org Units 23573 and 23575 where the method of
data captur has been set to 5 (Scales). Howeve, neither
of these Org units are equipped with scales in the E2EF
test environment
TIP 688 (+)
22224
E2EF: BARSF file W_092066 contains a BAD record
with exception code 130 (BES no EPOSS) which has no
value in the ‘authorised value’ field. TIP did not expect
to receive BAD records for BES no EPOSS where the
authorised amount was zero.
TIP 670
21499
E2EF - Aston Villa wk 52 - STX quantity record of 25
with a zero value for Discount Wholesale Stamp Books.
Quantities without values shouldn't be generated.
Version Draft 0.1 Page 56 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
TIP 669
21499 E2EF: During the test phase TIP has received many I Low
transactions with transaction modes 16 & 18 (Stock
adjust +/-) where the quantity value has been incorrect.
After investigation it appears that on occasion the
quantity is involved in the previous stock adjust is
being carried through to the next current. Exampl: Day
06, Org Unit 23574, Amount £675.00 Tran mode 18,
Quantity received as 20. The quantity was scripted as 1.
21952 File W_085058 ORG Unit 23573 Session Sequence I Low
1587 Start Time 1305383 The OTX record
has the wrong Transaction mode code, the received I-
code is 1 and it should be 15. Session Sequence 1583 is
displaying the correct Transaction mode Codes session
sequence 1587 should follow the same rules for
reversal,
TIP 710
N/A E2EF: During this phase TIP has received several I Low
transaction records for Item ID 188(Postal Order
Cashed Stam) , Tran mode 1 with quantity 0, value 0.
For a specfic example of this error please see file W_
082047.
Org Unit - 23573, Item ID -188(Postal Order Cashed
Stam) Transaction mode - 1, quantity 0, value 0.
N/A E2EF: OTRAN subfile (W_083051) for Org unit 23575, I Low
contains an invalid item. Transaction mode
combination: Items 341 was received with transaction
mode 1 (sell). The only transaction mode applicable for
this item is 15 (housekeeping)
TIP 680
22001 E2EF: Session sequence number 1845 for Org unit 23574 I Low
(Aston Villa), Stock Unit 'CA’, till id '1' on 23/03/97
(Day 7) contains two transactions. The two transactions
carry different transaction modes i.e. 1 (sell) and 14
(bulk input). A single session must only contain 1
transaction mode. The 2 transactions also have different
employee id's and Fallback mode flags which must be
consistent within a single session.
7.2.4.3
7.244
Observations
Of the 26 outstanding TIP incidents, 14 have been scheduled for
Target Testing.
(*) Denotes outstanding incidents currently scheduled for Target
Testing. 7
Overall Testing Status of Product
GREEN
Version Draft 0.1 Page 57 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
8 CLOSED INCIDENTS
Issue Ref. I PinICL Description Priority
BSU08 IN/A PMSR115 (dated 07/04/97) reports several fallback and I High
recovery exceptions, due to the ISDN line for office
505038 being connected for the first time. PMSR115 has
not reported these exceptions correctly. The following
errors have been detected: -
Some encashments have resulted in an EPOSS orphan
(code 320) as well as a status mismatch (310) and an
amount mismatch (300). Codes 300 and 310 mean that
both the EPOSS and the BES transactions have been
found with corresponding encashment IDs, the only
difference being in the amount and/or the status of the
transaction. we would therefore not expect to see an
EPOSS orphan in this case, as it suggests that the BES
encashment has not been sent to the counter, thus
contradicting a code 310 and 300.
There is a case of a 310 being reported without a 300.
The transaction ID for the 310 is 5050389900000214, and
the PCHL status is void, while the counter has
recovered the transaction as cashed. This should have
also resulted in an amount mismatch.
A series of BES and EPOSS orphans have been received
. Some can be matched by the NINO, the amount and
the status. The only field that differs is the fallback date.
This suggests that the fallback dates which have been
reported are erroneous.
There are three EPOSS orphans reported on PMSR115
on 07/04/97, and they are also reported as cleared on
PMSR116 on the same day. This should not happen and
requires investigating.
This incident must be given the 1 - Highest priority as
the above problems have prevented us form reconciling
TIP with CBOS, and this is not acceptable to ICL
Pathway or our sponsors.
Version Draft 0.1 Page 58 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
BSU 09
N/A
Four fallback and recovery exceptions which were
reported on PMSR115 on 07/04/97, have been removed
from the following day's PMSR115, yet they are not
reported as cleared on PMSR116. The transactions that
hae been removed are as follows:-
ExceptionCode Transaction ID
320 5050389900000230
320 5050389900000226
320 5050389900000220
325 5050389900000220
These exceptions should remain on PMSR115 until they
are cleared by BSU. Once they have been cleared by
BSU, they should be reported on PMSR116.
High
TR 444
19459
OBCS book status displayed as Encash but should have
Impound -
Scanned OBCS book M38, expecting an Impound
message to be displayed but instead the book was
encashable. Did not make payment and escaped from
screen.
Sue Bollom confirmed that the stop notice for book M38
was sent on 26/03/97.
High
TIP 717
N/A
BES Encashment performed at Tottenham (23578) on
(26/03/97), encashment ref. 505038/01/00001269 for
£22.10 not received by TIP. (ISDN Link down 10 days).
High
TIP 732
N/A
E2EF:BES Encashment performed at Tottenham (23578)
on (26/03/97), encashment ref. 505038/01/00001260
for £11.05 not received by TIP. (ISDN Link down 10
days).
High
BSU 01
N/A
Section 2 of PMSR 114 (dated 23/03/97)does not report
any files being produced and issued by ICL Pathway,
yet PMSR 100 confirms that 26 encashments took place.
PMSR 114 should have shown that these encashments
had been sent to CPCS.
Medium
BSU 04
N/A
On the APS transaction Summary reports for test dates
30/03/97 and 31/03/97 the second entry in the client
name column does not exist ('E2E Electricity'?). Should
it not be part of yorkshire Electricity (Client code 114)?
Medium
Version Draft 0.1 Page 59 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
BSU 05
N/A
The APS Transactions Transferred total on the APS
Reconciliation report (National Totals) for the test day
04/04/97 is 55 transactions for a value of 3903.79
The Total number of Normal Transactions on the APS
Transaction Summary report for test day 04/04/97 is 49
transactions for a value of 3728.67
The transaction numbers and values on these two
reports should match,
Medium
BSU 06
N/A
PMSR 114 dated 04/04/97 for transaction on 03/04/97
reports a total of 99 payments received for an amount
of £2986.40. PMSR 100 for the same date reports 99
payments received but for an amount of £296.35.
There were no payments reported on PMSR 112. The
values of payments received on PMSR 112 + PMSR 114
should = PMSR 100 but in this case they do not.
PMSR 114 also reports one stop processed by Pathway
for an amount of 11.05, but this does not show on
PMSR 100 as it should. No stops were reported on
PMSR 100 atall.
Medium
BSU 11
N/A
According to Iain Blood at POCL Farnborough, HAPS
‘was expecting to receive NO APS transaction files for
the date entered 9/4/97. However the APS
reconciliation report (National totals) reports 4
transactions at £267.99 as transferred.
Should there not be an entry of 4 transactions for
£267.99 in the APS delayed column?
Medium
BSU 12
N/A
PMSR 100 for transactions on 10/04/97 reports 91
payments from CAPS for an amount of £2773.60. There
is not a single payment reported as received on PMSR
114. Why is this so?
Medium
CAPS 14:
2 IN/A
IPTE2E(R2) - Duplicate encashment by Alt payee and
Customer.
On 01/04/97 Alt Payee (YA 011016D) cashes AP3
01/04/97 @ £11.05 at Restricted NPO (A).
On 09/04/97 Customer cashes AP4 08/04/97 @ £11.05
and AP3 01/04/97 @ £11.05 is also available again at
Resricted NPO (E). AP3 has been encashed twice..
Medium
HAPS 107 I N/A
Service ID mismatch
Medium
HAPS 108 I N/A
No control file on PCS PC for PCSOIL
Medium
HAPS 109 I N/A
Transaction in lower case
Medium
HAPS 11
0 IN/A
Validation Failure
Medium
IR354
20183
System enforces 'ONCH! declaration after log on -
Following log on the system enforced an 'ONCH'
declaration, this also happened on the second and third
occasions when the user logged on. The incident was
repeated on both the master and the counter positions.
Medium
Version Draft 0.1 Page 60 of 73
Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
IR 387 21773 Cannot enter item 365, Anglia Water Smart Card - It is I Medium
not available on the Horizon picklist in this office.....It
should have been as it is a core product
IR393_— I 21845 Office daily reports do not display transaction or stock I Medium
unit / BP details - After printing counter daily reports
for Giro deposits and withdrawals, Bt bills, NS deposits
and withdrawals and cutting off. The office daily
reports did not show the transctions that were reported
on the counter dailys
IR423 I 21970 The Cash Account mis-balanced by twice the amount of I Medium
. the revaluation completed on Day 13 -
When producing the Cash Account:
- The Stock Unit snapshot and report balanced
- The Office Snapshot and Report balanced
- The Cash Account Snapshot mis-balanced by £2.92
between the receipts and payments
- The revaluation figure of £1.46 did not report to the
revaluation line of the Cash Account
- The revaluation figure reported to the postage figure
- The post Cash Account Stock Unit and Office
Snapshot both report the correct figures.
R424 I N/A Office Daily Reports for Day 13 include Day 11's I Medium
transactions -
Office Daily Reports:
- Giro Deposit Summary
- Giro Withdrawal Summary
-B/T Bill Summary
- NS Deposit Summary
- NS Withdrawal Summary
Include Day 11's transactions.
R463. I N/A Product list produced has included Product Change I Medium
Listing -
On the Product List a Product Change Listing appears
at the end of the report. The changed products appear
on the Product List with the new details. Therefore is it
neccessary for the Product Change Listing to be printed
and how long will a product remain on this list after the
date of change.
Version Draft 0.1 Page 61 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
TIP 666
N/A
E2EF: Cash ‘Account for org unit 23573 (Newport) for
week 52 has entries against Cash Account lines 0021,
0034, 0044, 0048, 0053, 0062, 0072. These lines relate to
stock received from Hemel Hempstead, as Newport is a
‘provincial’ office it should not receive stock from
Hemel Hempstead, these entries should have been on
lines 6037 / 77 / 07 / 05 / 06, 6035, 6034, 6039, 6039 /
73 / 41 / 42 / 40, 6043, 6052 and 6033 respectively in
Table 6 (ie stock from other offices). The incorrect
transactions for this office type should have been noted
at the Horizon counter, the equivalent Horizon incident
has been covered by this TIP incident to avoid
duplication.
Medium
TIP 692
N/A
Newport Stock Holding Records Received CA Week 1
Cash = 81834.34 and on the Office Printout = 81829.44.
Medium
TIP 712
N/A
E2EF: During the test phase there is an ISDN failure re.
org unit 23578 (Tottenham). In files W_097003 and
W_097011, TIP received 8 EOD markers with an
incorrect time. i.e. 27/03 = 23:59:59, 28/03 = 22:13:20,
30/03 = 23:59:59, 01/04 = 23:59:59, 03/04 = 20:30:30,
04/04 = 19:01:07, 05/03 = 23:59:59 and 06/04 = 23:59:59,
End to End reference data identifies 17:00 as the closing
time for this outlet on all days of the week, therefore
these EOD markers should all have been written at
17330.
Medium
N/A
E2EF: Session sequence 1270 for Org unit 23578
(Tottenham), Stock unit GA contains only one record,
ie, item = 1 (cash), Txn mode = 1 (sell) and Amount = -
22.10, The session does therefore not balance.
Medium
22251
BES Encashments performed at Tottenham (23578) on
(03/04/97), encashment refs. 505038/99/00000230
annmnnnnnenannnnnnnnny] 6
AnnanmnmnMnAMMAMNNN DDG
AuHnaMAMMARANANAANEHE DDE
Each generated a 1st exception code 320 (EPOSS no
BES) on PMSR115. 2nd exception code 330 (BES no
EPOSS) for these encashment refs. and amounts was
expected but is missing from the report. In this scenario
either both exceptions should appear or none at all.
Medium
TIP 724
22251
BES Encashment performed at Tottenham (23578) via
PCHL on (03/04/97), PCHL encashment ref.
505038/99/00000223 amount £22.10 was recovered to
EPOSS with encashment ref.
SnHRAHANEABARRENENEER??g amount £18.10. Which Postmaster
confirmed at end of week. Two exceptions expected. Ist
an exception code 320 (EPOSS no BES) for encashment
ref, "224 for amount £18.10 and a 2nd exception code
330 (BES no EPOSS) for encashment ref. "223 for
amount £22.10. However, three exceptions were
received for encashment ref "224 (300, 310, 320).
Medium
Version Draft 0.1 Page 62 of 73 Date 29/03/99
End to End Testing Evaluation Report for Nile Release 2.0
POL00028419
POL00028419
TIP 727
N/A
Aston Villa(23574) CA Week 2: Received the following
Stock Holding record that was not on the Final Balance
Office Report:
qty: 71 Name: Rail tkt
Portadown (23575) CA Week 52: Receieved the
following Stock Holding record that was not on the
Final Balance Office Report:
qty:318 Name: Rail tkt
Medium
TIP 728
21809
E2EF: Newport Stock Holding Records Received CA
Week 2 Cash = 83062.18 and on the Office Printout =
83057.52
Medium
TIP 731
N/A
E2EF: Tottenham (23578) CA Week 1
CA Lines 1004 and 4081 on paper Cash Account: the
values do not match the number of transaction records
received from TIP.
Linked to Incident numbers 721 and 722
Medium
TIP 735
E2EF:BES Encashment performed at Tottenham (23578)
on (26/03/97), encashment ref. 50538/01/0001218 for
£11.05. Exceptions expected on PMSR115 were 320 for
amount £6.05 and a 330 with status of void. The system
should have matched these clearing the two exceptions
to PMSR116, creating two new exceptions of; 300
(amount mismatch) and 310 (status mismatch) the next
day. The exceptions reported were 300, 310, 320 all
same day.
Medium
TIP 736
22251
E2EF:BES Encashments performed at Tottenham
(23578) on (26/03/97), encashment __refs.
505038/01/00001232
anannnnnnnnnnnnniny 3,
have created spurious exception on PMSR115 code 320
for zero values.
Medium
TIP 747
N/A
E2EF: No OTRAN subfile for org unit 23573 (Newport)
for day 24 (system date 09/04/97) sent to TIP with
transmission of day 24 files.
Medium
TIP 750
N/A
E2EF: No OTRAN subfile for org unit 23579 (Rhyl, non-
automated) for day 24 (system date 09/04/97) sent to
TIP with transmission of day 24 files.
Medium
TIP 753
N/A
E2EF: Aston Villa Week 2 Cash Account Cash Account
line 5010
Value displayed on Cash Account is £3159.47
Value by adding OTX records for week 2 is £3160.93
N.B. Brought forward figure from week 1 is £2294.20
There is a difference of £1.46
Medium
Version Draft 0.1 Page 63 of 73
Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
BSU 03
N/A
PMSR114 (section 4) reports a rejection received from
DSS. However, the ‘transaction ID' column is populated
correctly. It contains the word 'CHECKSUM'! rather
than a genuine transaction ID. it also does not report
the NINO of the rejected transaction.
Low
CAPS 125
N/A
IPTE2E(R2) - Encashment file received with keyed
cards at BES machines
Low
CAPS 126
21632
Encashment of AP1 & AP2 total £22.10 due to be made
on day 7 at PO A have not been made. Card
impounded at HD not the counter
Low
CAPS 131
N/A
Customer was in the process of collecting card at NPO.
EVP was expected but user was not prompted by the
counter. As a result, test condition 27 - "Customer gets 2
EVP questions wrong - PUN and card Impounded" was
not tested.
Low
CAPS 132
N/A
Temp Token requested in CP610 for SPO (POB),
replacement card requested, no change made to NPO,
replacement card has been sent to SPO (POB) in error
rather than NPO (POE) NB. Priority of stir only L as
multi benefit which does not impact CHB go-live
Already covered in IR 416
Low
CAPS 144
N/A
All weekly JSA cases within the test pack have not had
contingency payments produced. All these cases are
JSA weekly paid.
IR355
N/A
Transaction ID differs between customer receipt and
transaction log - Performed a BES transaction and
received an Impound message, Produced a customer
receipt for the transaction with the ID of 01-2122 (Script
No. 2401).....Produced a transaction log which
displayed the’ NIL BES transaction with the transaction
ID of 01-2124 (Script No. 124)
IR357
N/A
A batch of BES cards failed to be received into the
office, due to an error in the ordering process - When
trying to receive a batch of BES cards into the office, the
numbers were not recognised, causing two of the cards
to be impounded. This has been traced to the fact that
the batches were incorrectly setup...
Low
IR359
N/A
Printout formats appear differently with NSB
withdrawals and ‘deposits - When printing NSB
withdrawals summary a sub heading of NS Ord A/C
special withdrawal appears, even though no entry is
made against this - Also on NSB withdrawals there are
sub totals for each different group, on the deposits there
is only a total.
IR361
N/A
Transaction log does not report migrated Table 5 and
Discrepancies figures - During Migration stock was
entered in Table 5 and a loss entered in Discrepancies.
Printed a Tramsaction Log at the end of day and these
items did not report.
Low
Version Draft 0.1 Page 64 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
IR 366
N/A
Unable to activate OBCS Receive screen - After
accessing Token Management attempted to activate
OBCS receive book icon. Icon turned grey but the
screen did not change. Other icons on this screen
invoked their associated screens. The receive book icon
can be accessed on other offices.
Low
IR368
I 21680
Temporary Tokens unable to be cashed at the counter
in Offices A, B & C - On attempting to perform manual
Temporary Token encashments the system displayed
the message "This card cannot be used at this
Office.......". Checked with CAPS and the elpdesk and
these Temporary Tokens have all been set-up correctly.
Low
1R370
N/A
Could not produce a transaction log when no
transactions had been entered - When a user attempted
to produce a transaction log (when no transactions had
been entered onto the Horizon system) on a shared
stock unit with both users logged on, by selecting the
‘By User' option the report was not produced.
Low
IR371
N/A
The Grand Total is not displayed on Counter Rem In
Summary - After producing a Counter Rem In
Summary, 2 sessions for Rem In were reported and the
addition was correct but there was not a Grand Total
shown.
Low:
~ IR372
N/A
Cannot migrate V10/V62 Transactions (Item 119) -
During migration there is not a line in the Receipts Data
Entry Table to input V10/V62 transactions. V10/V62
(item 119) is included in E2E Reference Data
Requirement for Nnon-core products in this office.
Low
IR373
21871
Cannot produce a BES Weekly Cards Impounded
Report - When attempting to produce a BES Weekly
Cards Impounded Report following inputing CAP date
a message is invoked stating date is not a valid CAP
resulting in the report not being produced.
IR379
N/A
Transaction ID (Ref) differs between the Transaction
Log and the Rem In Slip ~ Following Rem In session
Rem In Slip was produced with Ref 02-589 but on the
Transaction Log it appears as 2-590.
Low
IR382
21666
The e2e test plan shows that the customer details for
YC012005B should have been sent to Pathway on Day
8, 24/03/97. No customer details record was found in
the files received by Pathway.
Low
IR384
N/A
Tables on cash account do not have totals - The
following tables do not display a total...... Table 2, 29, 3,
6,8 and 9.
IR391
21783
Enforce ONCH problem when an incorrect figure is
entered - If an incorrect Daily Cash declaration is
entered when enforced during log on there is no way to
enter a correct one.
Low
Version Draft 0.1 Page 65 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
IR392
21783
Enforced ONCH declaration uses current cash holding
to compare amount entered - On an individual stock
unit the discrepancy check is being made against the
current cash holding other than the cash held
overnight.
Low
R394
21843
Migration . Verification Report, Suspense Account
Report do not report to the Event log - Migration
Verification Report produced at 09:47 25/3/97 and the
Suspense Account Report produced at 09:58 25/3/97.
Both reports are not included in the Event Log
produced at 14:42 25/3/97.
Low
IR399
21814
When processing a Cash Account and rolling into the
next CAP, a message indicated that the year was 1996 -
After rolling the Cash Account from week 52 to week
01 the next CAP end date was in 1996. The date was
confirmed by obtaining an Office Weekly Pé&A
Summary that has the next CAP printed on it.
IR401
21811
The inbound CAPS Data files for End to End Final Pass
Day 9 have been checked
and the following errors have been identified:
See PinICL - 21811
Low
IR 403
21863
The inbound CAPS Data files for End to End Final Pass
Day 10 have been
checked against the plan and the following errors
identified:
See PinICL - 21863
Low
TR 406
N/A
System enforced Log Out did not activate after 90
minutes -
Attempting to test if the system would enforce a lock
out, the system was left for 90 minutes but the
temporary lock did not even activate. The temporary
lock eventually activated after 105 minutes . The system
was not left after this due to time restraints. The
temporary lock did however activate after the 30
minute mark on office C ‘Aston Villa’.
Low
R407
20115,
Cash Account Week 52 reporting incorrect volumes for
Giro transactions -
Cash Account week 52 is reporting 1 more Giro
inpayment and Giro outpayment: Giro inpayment
should be 29 not 30, Giro outpayment should be 4 not 5.
Could be connected to IR 360 (PinICL - 20115) incorrect
giro volumes on Office snapshot.
Low
Version Draft 0.1 Page 66 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
IR 408
21874
The inbound CAPS Data files for End to End Final Pass
Day 11 have been
checked against the plan and the following errors
identified:
See PinICL - 21874
Low
IR 416
21910
Batch receipt via Helpdesk failed due to batch setup
with incorrect office details -
On attempting to receive a batch (DT000000204GB) via
the Helpdesk using the FAD code for Office "G" 505038
(containing 2 cards NINO's:¥G020035 & YG020035
which had TT's assigned for FAD code 501680 instead
of the correct FAD code of 505038) the Helpdesk
prompted that the batch was not recognised at this
office. On investigation it was found that the batch had
been incorrectly setup against office "B" 501680. This
could be related to the existing issue whereby assigning
TT's to a SPO other than the NPO changes the NPO to
the SPO.
“Low
IR418
N/A
Following a Réference Data drop APE2E117 did not
change Client name -
AP card APE2E117 'Yorkshire Electricity’ was expected
to have changed Client name to 'E2E Electricity’
following Reference Data Drop (28/03/97). Performed
Magcard APE2E117 transaction for £25.00, Client name
still displayed as ‘Yorkshire Electricity',
Low
IR 432
22014
E2E FP - Missing or unexpected CAPS data
See PinICL - 22014
Low
TR 434
22075
E2EFP - Missing or unexpected CAPS Data.
See PinICL - 22075
Low
IR 441
N/A
Product Listing Report different from the example in
the Receipts and Reports OPS -
Product Listing Report generated by Horizon contains
Version, Unit Price and From but does not include PLU
number. This report differs from the example in the
Receipts and Reports OPS.
Low
IR 442
22170
E2EFP - Missing or Unexpected CAPS Data Files
See PinICL - 22170
Low
Version Draft 0.1 Page 67 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
IR459
22535
BES recovery transaction not appearing in the "Mis-
match" screen during Cash Account rollover -
Case G6,NINQ. } On Day 18 payments API &
AP2 (total = £41 re encashed via the PCHL. This
was then recovered twice at the counter.
The first recovery was performed using the correct
transaction ID and the correct payment value, the
second recovery was performed using the correct
transaction ID but the incorrect payment value (£24.10).
When attempting to roll the Cash Account into the next
CAP, the BES "Mis-match" screen was displayed. As the
ISDN line was still out at this Office, every recovered
BES transaction was displayed with the exception of the
£24.10 encashment.
This encashment did appear on the relevant "Daily BES
Recovered" report.
Low
IR 460
122389
E2EFP - Missing or unexpected CAPS Data (Day 22)
See PinICL - 22389
Low
IR 461
22385
E2EFP - Missing or unexpected CAPS Data
See PinICL - 22385
Low
IR471
22617
On attempting to activate a card using an obsolete PUN
the system displayed the message "Invalid PUN. Refer
the customer to the office that deals with their claim...".
I would have thought that a system invoked PUN
impound would be required in order to remove the
PUN from circulation.
Low
‘TIP 657
N/A
E2EF: BARSF subfile (W_081066) dated 22/03/97,
contains BAM records for Org units 23575, 23576,
23577, 23578. These Org units are not yet automated
and therefore should not have been reported as
missing.
Low
TIP 659
N/A
E2EF: Chelsea (23572) day 6, TIP received OTX records
for day 6 with item 932 "Log on Fail P/word Event".
this event is not on the relevant event log.
Low
N/A
E2EF: Office B, day 8, Event logs, the event transactions
received by TIP show various events for item ID 913
(benefit books OBCS event). In the event logs for these
are not shown.
Low
‘TIP 667
14681
E2EF: During the test phase TIP has received various
transactions for item IDs 121 (Giro Transcash Fee) and
233 (Gas / Utility Transcash Fee). The problem with
some of the records is that the quantity and value are
nil. This indicates that there was no fee to be paid, so
TIP should not receive these records.
Version Draft 0.1 Page 68 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
TIP 671
22039
E2EF: File W_088003, Org Unit 23574, Date 29/03/97.
This file contains 2 invalid item transaction modes, i.e.
Items 259 (Giro E/N Receipts) and 349 (Giro E/N
Withdrawal) received with a transaction mode 1 (Sell),
the only appropriate transaction mode for these two
items is 15 (Housekeeping).
TIP 678
N/A
E2EF: Cash Account for Org unit 23576 (Man Utd) for
week 52 has no entry against line 4016. 1 transaction for
item id 188, transaction mode 1 (Postal Order cashed
stamps) was received by TIP and according to the E2E
referemce data this maps to line 4016.
TIP 679
N/A
E2EF:No OTRAN subfile for Org unit 23576 (man utd)
sent to TIP overnight at the end of day 14 (system date
30/03/97). A subfile for this Org unit was scripted to be
sent on this day.
TIP 682
N/A
E2EF: File_09003019 contains OTRAN subfile for Org
Ub=nit 23576 (Man Utd) for 30/03/97. The EOD
marker within this file has an end time of 19:31:010, the
latest time for an EOD marker is 19:00.
TIP 714
N/A
E2EF: During this phase TIP has received transaction
records for Item ID 852, Tran mode 1 with quantity 0,
value 0.
For a specfic example of this error please see file W_
094015
Org Unit - 23574, Item ID - 852 (BES Milk Token)
Transaction mode - 1, quantity 0, value 0.
TIP 716
N/A
E2EF: File W_092041 contains the records for office
23576 (Man.Utd) on the 02/04/97, The session
sequence number 1521 shows 2 records which have the
transaction mode of 19. One record is for Item 222 (Loss
System) and the other is for item 1. The value of these
transactions is £262.90, The script for these transactions
shows that the value should be £157.90. This problem
has been discussed with the Horizon test team at
Feltham who, after investigation, thought that we
should receive the scripted amount of £157.90. This
means that there is a differnce of £105.00 which is
unexplained. 7
TIP 719
22251
PMSR115 for 07.04.97 shows an exception code 320
(EPOSS no BES) for encashment refs,
505038/99/00000230 for £11.05
AnamnannmnanmnnnMHND?6 For £49.10
AnnnAMnnnnnARAEEHEHDDD For £11.05
Aumunannnnnmnnnenntyo9 for £40.10
The "Fallback Date" on the report is (02/04/97) but
these encashments were performed at the PCHL
(03/04/97).
Low
Version Draft 0.1 Page 69 of 73 . Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
TIP720 I N/A E2EF: During this phase TIP has received 2 transaction I Low
records for Item ID 2334, Tran mode 4 with quantity 0,
value 0.
For a specfic example of this error please see file W_
088003
Org Unit - 23573, Item ID - 2334 (SIPBK Greet
Rupert), Transaction mode - 4, quantity 0, value 0.
TIP725 I N/A E2EF: During this phase TIP has received a transaction I Low
record for Item ID 2334, Tran mode 5 with quantity 0,
value 0.
For a specific example of this error please see file W_
091020
Org Unit - 23573, Item ID - 2334 (SIPBK Greet
Rupert), Transaction mode - 5, quantity 0, value 0.
IR413 N/A Revaluation up slip reporting the wrong volume - Unclassified
Revaluation up slip reporting a volume of '0', should be
'320'
IR414. IN/A Cannot encash OBCS foil (holiday payment) in I Unclassified
Northern Ireland -
OBCS is not available in Northern Ireland, but there is
no method on the system to enter a foil of an English
book making a temporary encashmenmt whilst on
holiday. Also there is no method of encashing any P&A
other than with BES cards,
IR419 N/A No Beneficiary details when a Permanent Agent I Unclassified —
attempts to make encashments on the Beneficaries
behalf -
NINO:.. who is a beneficiary in his own Fight I
and a Permanent Agent for NIN
attempted to encash payments for NINO} GROI
payments available...", but there
this as the details for NINO:
available in the stack.
IR 422 N/A No log out event between 2 log ons - Unclassified
On the Event Log, user ABA007 logs on at 08:10 and
Logs on again at 08:21, without a record of logging out.
The 'User Logon/Logout History' also does not have a
record of the log out.
Version Draft 0.1 Page 70 of 73 Date 29/03/99
POL00028419
POL00028419
t
i
End to End Testing Evaluation Report for Nile Release 2.0
1R427 N/A Stock unit balance snapshot shows summary of P & A I Unclassified
transactions, even though none have been done -
Stock unit EB has no transactions for pensions and
allowances, but a summary has appeared on the
‘Payments’ section of the stock unit balance snapshot,
although this was a nil summary it is not required.
This stock unit did 1 Pé&A Grp 11 for £11.08, but this
was reversed out.
IR428 I N/A Also includes script no.s 3007 and 3008 Unclassified
Desktop Icons names do not match up with the reports
that they produce.
Stock receipts - should be counter weekly Rem in
Stock return - should be counter weekly Rem out
Stock receipts and returns should be Rem summary
IR 431 N/A Produced a Cheque Listing which did not report I Unclassified
previous days cheques -
Produce a Cheque Listing (only current days cheques)
= £107.50
Remmed out total amount of cheques = £153.93
Produced another Cheque Listing = £46.43-
IR435. I N/A UKPA Office Daily Report missing transactions for that I Unclassified
day -
On the Office Daily UKPA report, it reported nil
transactions for day 15 (31/03/97), but on the Counter
Daily Report Day 15, 1 transaction reported for £21.00 +
fee £2.00 which is correct.
The Stock Unit Balance Snapshot does report the
transaction.
Version Draft 0.1 Page 71 of 73
Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
IR450
19003
Should the system invoke card impounds for both cards
during a Carded Casual Agent transaction if one of the
cards has been previously stopped?-
Case C2 NINO
On attempting to perform a CCA ‘encashment using
these cards, one of the cards had been previously
unknowingly impounded (due to the same problem
being raised now). When this card was swiped the
system displayed the card impound screen and allowed
the user to print a receipt and/or continue. On selecting
"Continue" it was noticed that the system then displays
acard impound screen showing the details for the other
card (this was missed previously because the screen
changes quite quickly and the user thought that they
had not selected "Continue" originally".
The question is, should the fact that one of the cards
had been previously impounded result in the other
card being impounded?
The only scenario I can think of that should result in
both cards being impounded is if EVP is invoked and
failed.
Unclassified
IR 451
N/A
Should presenting an obsolete PUN result in a system
invoked PUN impound?-
Case E15 NINO On attempting to activate a
card using an obsolete PUN the system displayed the
message "Invalid PUN. Refer the customer to the office
that deals with their claim...". I would have thought that
a system invoked PUN impound would be required in
order to remove the PUN from circulation.
Unclassified
IR 452
N/A
Cash Account receipts table, line 0081 "Instant Win
Acvtivate" is reporting "Rem in from Client" National
lottery instants £1
Unclassified
IR 454
N/A
Daily office summaries, reportind previous CAP's
transactions.
Summaries produced on 5/4/97 in CAPS 02 have
reported transactions from day 15 31/3/97, which is in
CAP 01. :
Summaries produced :-
Giro Deposit
Giro Withdrawal
BT Bill
NS Deposits
NS Withdrawals
Unclassified
IR 467
N/A
Cash Account Payment Table has included the line 10
86 "Final Account Deficiency" which is not displayed in
the Reports and Receipts OPS.
Unclassified
Version Draft 0.1 Page 72 of 73 Date 29/03/99
POL00028419
POL00028419
End to End Testing Evaluation Report for Nile Release 2.0
IR 474
N/A
The AP recovery screen is not envoked after a system
crash,
Following printing problems which envoked a system
crash, the system was re-booted. When the operator
logged on the system did not envoke the AP recovery
screen.
Unclassified
IR475
N/A
Volume of postage stamps sold is different than the
volume recorded on the transaction log.
The customers receipt is reporting a volume of 1 with a
value of £4.60
The transaction log is reporting a volume of 3 with a
value of £4.60
Unclassified
Version Draft 0.1 Page 73 of 73 Date 29/03/99