Академический Документы
Профессиональный Документы
Культура Документы
Version 1.0
03/10/2014
Page 1 of 84
03/10/14 V1.0
DCC Public
Document Location
The source of this printed document can be found in Smart DCCs Programme Management Office, or with the author if in an
unapproved status.
Associated Documents
This document is associated with the following other documents:
Ref
Source
Release
Date
Version
[1]
ISTQB
Oct 2012
v2.2
[2]
[3]
[4]
[5]
[6]
[7]
DSP
DECC
DCC
DCC
DCC
DCC
Feb 2014
v2.3
[8]
[9]
[10]
[11]
[12]
[13]
DCC
DECC
DSP
DSP
DCC
DSP
v .1
v .1
Consultation publication
Consultation publication
Aug 2014
Jan 2014
Sept 2014
Not published
SEC3
v0.9
v0.13
Not published
V0.8
Page 2 of 84
03/10/14 V1.0
DCC Public
Conten
Table of Figures..................................................................................................................... 7
1
Introduction..................................................................................................................... 8
1.1
Context...................................................................................................................... 8
1.2
Change Forecast.....................................................................................................10
1.3
1.4
Terminology............................................................................................................. 11
Scope............................................................................................................................. 14
2.1
Overview.................................................................................................................14
2.2
Out of Scope............................................................................................................14
Objectives..................................................................................................................... 15
Introduction..............................................................................................................16
4.2
DSP-led testing........................................................................................................16
4.2.1
4.2.2
4.2.3
4.2.4
CSP Regions....................................................................................................17
4.2.5
Non-Functional Testing.....................................................................................17
4.3
5
UEPT....................................................................................................................... 18
Deliverables.................................................................................................................. 19
5.1
5.2
Notes on Deliverables..............................................................................................19
Test Procedure.............................................................................................................. 21
6.1
Requirements traceability........................................................................................21
6.2
6.2.1
6.2.2
Technical Readiness................................................................................................21
6.3.1
Service Providers.............................................................................................21
6.3.2
SEC Parties......................................................................................................22
6.3.3
RDPs................................................................................................................22
6.4
Testing Principles.....................................................................................................22
6.4.1
Non-discrimination............................................................................................22
6.4.2
6.4.3
6.4.4
Testing by Region.............................................................................................23
6.5
Release management..............................................................................................23
6.6
Configuration management.....................................................................................23
6.7
Timetable.................................................................................................................24
6.7.1
IT Test Initiation................................................................................................24
6.7.2
IT Test Execution..............................................................................................27
6.7.3
IT Test Completion............................................................................................28
6.8
Dependencies..........................................................................................................30
6.9
6.9.1
Entry Criteria....................................................................................................31
6.9.2
Exit Criteria.......................................................................................................31
Introduction..............................................................................................................33
7.2
7.3
7.4
7.5
TSP environment.....................................................................................................33
7.6
7.7
SEC Parties.............................................................................................................33
Page 4 of 84
03/10/14 V1.0
DCC Public
7.9
7.10
Test Data........................................................................................................................ 37
8.1
8.2
8.3
Principles.................................................................................................................40
9.2
9.3
9.4
9.5
9.6
10
10.1
Introduction..............................................................................................................45
10.2
10.2.1
General............................................................................................................. 45
10.2.2
10.2.3
10.3
11
11.1
General.................................................................................................................... 48
11.2
11.2.1
11.2.2
Reporting structure...........................................................................................51
11.2.3
11.3
Governance.............................................................................................................52
Page 5 of 84
03/10/14 V1.0
DCC Public
Communication........................................................................................................53
11.4.1
Progress meetings............................................................................................53
11.4.2
11.5
Test Assurance........................................................................................................54
11.5.1
Introduction.......................................................................................................54
11.5.2
11.5.3
Test Witnessing................................................................................................55
11.5.4
11.5.5
Product inspections..........................................................................................56
11.5.6
Documentation review......................................................................................56
12
Test Scenarios......................................................................................................... 59
i.
ii.
Change of Supplier (On-Demand) Test Scenario for EIS SEC Party Role..........................62
Change of Supplier (On-Demand) Test Scenario for GIS SEC Party Role.........................64
Self Service Interface Test Scenarios.................................................................................66
Billing Test Scenario........................................................................................................... 69
Reporting Test Scenario.....................................................................................................70
Volume Test Scenarios.......................................................................................................71
B.
Documentation RTM................................................................................................73
C.
Page 6 of 84
03/10/14 V1.0
DCC Public
Table of FiguresY
Figure 1 DCC Solution
10
Figure 4 - Abbreviations
13
16
19
27
28
29
31
34
36
39
42
43
43
45
46
50
51
52
Figure 22 - IT Governance
53
55
73
74
Page 7 of 84
03/10/14 V1.0
DCC Public
Introduction
1.1
Context
This document sets out the manner in which Interface Testing (IT) will be conducted for the
Smart Metering eco-system, which is depicted in the following diagram. Readers are
expected to be familiar with the Joint DSP/CSP Test Strategy1 (Reference [2]).
The following diagram illustrates the documentation set for Interface Testing. Note that the
documents in the diagram also apply to E2E Testing and Enduring Testing.
Page 9 of 84
03/10/14 V1.0
DCC Public
1.2
Change Forecast
This document will be assessed and, where applicable, updated by the DCC when approved
versions of the following documents are available:
Device Selection Methodology [6] (due mid-November);
Common Test Scenarios Document/SMKI and Repository Test Scenarios Document
(CTSD/SREPTSD) [7] (due end November);
Testing Issue Resolution and Disputes Process [12]; and
further versions of the Smart Energy Code, specifically SEC4.
1.3
Following consultation, the DCC will submit the document to the TAG for review prior to
submission to the SEC Panel for approval. This document will be presented to the SEC
Panel in timescales such that it can be published at least 6 months prior to the start of the
Interface Testing stage.
If the SEC Panel decides not to approve the IT Approach and the DCC is required to do rework, it will follow the process laid out in SEC T3.11.
If the SEC Panel decides to approve the IT Approach, the DCC will follow the process laid out
in SEC T3.12.
Page 10 of 84
03/10/14 V1.0
DCC Public
1.4
Terminology
In this document the term Service Provider includes all of the following:
the DSP;
both CSPs;
the Trusted Service Provider (TSP), supplier of the SMKI solution element; and
the DCC Enterprise Service Provider (DCC Enterprise), i.e. the DCC in its role as supplier
of Enterprise systems such as Billing and BI/MI.
The term User Integration Testing (UIT) refers to the test phase that comprises Interface
Testing and End to End Testing.
The term Test Stub means systems and actions which simulate the behaviour of Devices
and User systems.
The term Testing Issue means in respect of any tests (a) anything that is preventing the
execution of the test or (b) once commenced or executed, the test has an unexpected or
unexplained outcome or response.
The term Registration Data Provider (RDP) means
(a) in respect of each Electricity Distributor, the person nominated in writing to the DCC from
time to time by that Electricity Distributor; or
(b) in respect of each Gas Transporter, the person nominated in writing to the DCC from time
to time by that Gas Transporter,
on the basis that more than one Party may specify the same Registration Data Provider, and
that the Electricity Distributor or the Gas Transporter shall be deemed to have so nominated
itself in the absence of any other nomination.
The term RDP Systems means any Systems:
a) which are operated by or on behalf of an Electricity Distributor or Gas Transporter
responsible for providing (or procuring the provision of) Registration Data in
respect of a particular MPAN or MPRN; and
b) which are used wholly or partly for the collection, storage, Back-Up, processing or
communication of that Registration Data prior to, or for the purposes of, its
provision to the DCC over the Registration Data Interface.
This document uses standard testing terminology, a glossary (Reference [1]) of which can be
found on the International Software Testing Qualification Board website, www.istqb.org.
Abbreviations used in this document are listed in the following table.
Page 11 of 84
03/10/14 V1.0
DCC Public
Abbreviations
Full Title
BI
Business Intelligence
CI
Configuration Item
CoS
Change of Supplier
CPA
CSP
CTSD/SREPTSD
DAB
DCC
DCC KI
DECC
DLMS
DSP
DSM
DUGIS
E2ET
GBCS
HAN
IHD
In Home Display
iGT
IRB
IT
Interface Testing
MI
Management Information
MPRS
OAT
PIT
Pre-Integration Testing
RDP
RTM
SEC
SIT
SMKI
SP
Service Provider
SREPT
SSI
SSMI
S/W
Software
TAG
TBDG
Page 12 of 84
03/10/14 V1.0
DCC Public
Abbreviations
Full Title
TSP
UAT
UEPT
UIT
Page 13 of 84
03/10/14 V1.0
DCC Public
Scope
2.1
Overview
In its role as Systems Integrator, the DSP will manage Interface Testing (IT) with support from
SEC Parties, the Registration Data Providers (RDPs) and Service Providers (SPs).
IT will verify that SEC Party, SP and RDP system elements integrate together to form a
working system that meets the agreed functional and non-functional requirements defined in
the SEC and the SP contracts. The system consists of the whole Smart Metering eco-system.
IT will be undertaken on a CSP Region by CSP Region basis, with CSP Regions being tested
in parallel where practicable. It will use the Devices the DCC successfully used as the basis
of testing in SIT. Should Devices not be available, then Device Stubs will be used.
Large Supplier Parties (and Network Parties if so required by the Secretary of State) are
obliged to be ready to begin their User Entry Process Tests (UEPT) during IT. Other SEC
Parties can also conduct their UEPT during IT.
2.2
Out of Scope
certification of Meter Device Models (energy Suppliers are responsible for ensuring that
any meters they install at consumers premises are SMETS compliant, including a
requirement that they are protocol certified);
certification of Communications Hubs (the CSPs, in conjunction with their Comms Hub
manufacturers, are responsible for this activity);
testing of Meter Device Models, other than the interaction of those Devices that are
installed in CSP Test Labs, for the purpose of conducting User Entry Process Tests, with
the DCC solution (energy Suppliers are responsible for ensuring that any Meter Device
Models that they install are interoperable with the DCC and are SMETS compliant);
testing of the Home Area Network (HAN) other than its interaction with the DCC solution (it
is the responsibility of energy Suppliers to ensure that a SMETS compliant HAN is
established in each consumer premise);
testing of Hand Held Terminals other than their interaction with the DCC solution (energy
suppliers are responsible for ensuring that any Devices that they use are compliant with
the relevant technical specifications);
testing the inter-changeability2 of Devices connected to the Home Area Network (this is not
a requirement under the provisions of the SEC);
testing of Service User Business Processes (Service Users can test their back office
systems against the DCC during the End to End Test stage on a voluntary basis).
Objectives
The objective of Interface Testing is to demonstrate that the DCC and the DCC Systems
together with the Communications Hubs interoperate with User Systems in order that the
DCC is capable of complying with its obligations under Sections E (Registration Data), G
(Security) and H (DCC Services) (in each case) at levels of activity commensurate with
the relevant Volume Scenarios.
This Test Approach document sets out the manner in which the IT objective will be achieved
and includes the requirements that are set out in Section T3 of the SEC.
Page 15 of 84
03/10/14 V1.0
DCC Public
4.1
Introduction
4.2
DSP-led testing
The primary focus of IT is on the dynamic interaction between the Service Provider and
Service User systems. The key elements of the testing that will be undertaken are:
the DCC User Message Gateway (item 1 on the diagram below), which was stubbed in
PIT and SIT: integral to this is Parse & Correlate;
the DCC Self Service Interface (item 2), which was tested in PIT and SIT by imitating the
behaviour of Service Users over a local connection.
The other External Interfaces that are shown in the following diagram will already have been
verified during PIT and SIT. Regression testing of these interfaces will be conducted to the
extent necessary as part of the Additional Functionality tests.
Page 16 of 84
03/10/14 V1.0
DCC Public
Resilience Testing
As with Performance Testing, full Resilience Testing is not feasible in IT and will instead take
place on the production environments connected together with the production
communications links as part of OAT. SEC Parties are not expected to participate in
Resilience Testing. Where practical to do so, OAT testing will be conducted in the same
timescales as IT and the results provided in the IT Stage Completion Report to the SEC
Panel. Otherwise the results will be reported separately to the SEC Panel for information.
4.3
UEPT
SEC Parties will undertake User Entry Process Testing as described in the CTSD/SREPTSD
[7]. The DCC will facilitate UEPT as described in the CTSD/SREPTSD.
Prior to starting UEPT, the DCC requires SEC Parties to undertake a Connectivity Test in
order to verify that the Service Users system can connect to the DCC. This comprises the
sending of a DCC-only Service Request and the receipt of a Response.
Page 18 of 84
03/10/14 V1.0
DCC Public
Deliverables
5.1
The responsibilities of each Test Participant with respect to each IT deliverable are set out in
Figure 6 RACI Matrix showing Deliverables.
Key:R Responsible
A
Accountable
C
Consulted
I
Informed
Test Participant
Deliverable
DCC
DSP
CSP
DCC
Enterprise
TSP
RDP
SEC
Party
Test Infrastructure
(hardware &
Communication)
Test Environments
(software & configuration)
A/R
Test Tools
Executed Tests
IT Preparation Progress
Reports
IT Execution Progress
Reports
IT Stage Completion
Report
5.2
Notes on Deliverables
The DSP, in its role as systems integrator, is responsible for the overall planning,
management and delivery of Interface Testing. The DCC, in its overarching assurance role, is
accountable.
The DCC (together with Device manufacturers) is responsible for provision of the Devices for
use in CSP Test Labs and any related technical support which is necessary. These Devices
will be selected in accordance with the Device Selection Methodology [6]. The CSPs are
responsible for provision of the physical environment of each Test Lab, the communications
Page 19 of 84
03/10/14 V1.0
DCC Public
Page 20 of 84
03/10/14 V1.0
DCC Public
Test Procedure
6.1
Requirements traceability
The Requirements Traceability Matrix (RTM) output from SIT will be updated with tests added
in IT and the revised version will be supplied to the DCC.
6.2
6.3
Technical Readiness
built
configured
Page 21 of 84
03/10/14 V1.0
DCC Public
loaded with the required solution elements (including Test Stubs, tools and
devices)
smoke tested
that the base test data required to commence IT has been loaded to the relevant data
stores
that the Test Management tool has been set up and made available to the relevant
personnel
that guidelines for the Test Management tool have been developed and that the relevant
SP and supporting SEC Party personnel have been made familiar with its use.
6.3.3 RDPs
The Technical Readiness assessment will consist of verifying that each has supplied the data
necessary to support the testing.
6.4
Testing Principles
6.4.1 Non-discrimination
The DCC will support SEC Parties performing UEPT in IT and the DCC will facilitate the
concurrent testing of these SEC Parties to the extent reasonably practicable. To facilitate this,
SEC Parties are required to notify the DCC of their intention to participate in IT five months
ahead of the start of IT execution so that Test Lab facilities and support resources can be
expanded where necessary.
Should unexpected problems be encountered, Energy Suppliers will be given priority to test in
their gas supplier and electricity import supplier roles in order that IT can complete in a timely
manner. See Section 7.1 - Introduction, for details on current assumptions made regarding
the number of Users who will participate.
Page 22 of 84
03/10/14 V1.0
DCC Public
6.5
Release management
Releases of fixes and configuration changes will be scheduled for each week during IT,
unless otherwise agreed by the DCC (frequency to be reviewed in the light of experience).
The UIT Issue Manager will agree the contents of these releases with the SP IT Managers
and the DCC Service User Integration Test Manager. Should an emergency Release be
required (e.g. because testing is seriously impeded or halted), the UIT Manager will decide on
the timing after consulting with the SP IT Managers and the DCC Service User Integration
Test Manager.
Each Release into the IT environment will be accompanied by a Release Note describing the
contents of the Release. All fixes and configuration changes included in a Release will
undergo PIT and SIT with the relevant SPs, which includes an appropriate degree of
regression testing according to the principles laid out in the PIT and SIT Approaches. Once a
Release has been installed in the IT environment, it will be subject to:
a smoke test, that will be undertaken by the DCC;
testing of the constituent fixes and configuration changes, that will be undertaken by the
relevant SPs and SEC Parties; and
an IT regression test, based on assessment of the risks that the new release will cause
features previously working in IT to stop working that will be undertaken by the DCC.
6.6
Configuration management
The DSPs Configuration Manager owns the master Configuration Plan which defines a) the
Configuration Items (CIs) comprising the DCC Solution and b) the inter-dependencies
between these CIs. This configuration management process is part of the test preparation
activities. See Figure 7 Timetable for test for the timeline of this.
Page 23 of 84
03/10/14 V1.0
DCC Public
Page 24 of 84
03/10/14 V1.0
DCC Public
6.7
Timetable
The high level timetable for IT can be divided into the following sections:
Test Initiation
Test Execution
Test Completion.
The tables below list the activities that must be undertaken in each section. They do not duplicate the information relating to UEPT activities in
the CTSD/SREPTSD but describe additional activities.
IT Test Initiation
The table below sets out the steps that must be undertaken by either the DCC or relevant Test Participant seeking to undertake IT and the
timeframes within which such steps must be completed.
Ref
By When
Action
From
To
23/07/2014
DCC
SEC Parties
6 months prior to
the start of IT
Publish IT Approach
DCC
SEC Parties
DCC website
6 months prior to
the start of IT
Publish
CTSD/SREPTSD
DCC
SEC Parties
DCC website
6 months prior to
Publish
DCC
SEC Parties
SMKI
Information Required
Method
DCC website
DCC website
Page 25 of 84
03/10/14 V1.0
DCC Public
Ref
By When
Action
From
To
the start of IT
Interface Specification
6 months prior to
start of IT
Publish
Interface
Testing Plan
DCC
SEC Parties
DCC website
6 months prior to
start of IT
DCC
SEC Parties
DCC website
6 months prior to
start of IT
Publish
Plan
DCC
SEC Parties
By secure email
5 months prior to
the start of IT
Confirm intention to
participate in IT
SEC Parties
DCC
By email
6 months prior to
the start of IT
Order
Connection
SEC Parties
DCC
10
4 months prior to
start of IT
P&C software
available
V2
DCC
SEC Parties
DCC website
11
2 months prior to
start of IT
DCC
SEC Parties
DCC website
12
2 month prior to
start of IT
Publish Schedule of IT
execution
DCC
SEC Parties
DCC Website
13
2 months prior to
start of IT
DCC
SEC Parties
DCC website
Environment
Network
Information Required
Method
Page 26 of 84
03/10/14 V1.0
DCC Public
Ref
By When
Action
From
To
DCC
SEC Parties
Information Required
Method
Disputes Process
14
2 months prior to
start of IT
15
30 working days
prior to the start of
IT
16
30 working days
prior to the start of
IT
17
25 working days
prior to the start of
IT
Configure
and
connect Interfaces
18
19
DCC website
ALL
Completed Checklist
DCC
Inventory list
DCC
ALL
Completed Checklist
Populate
test
environments with test
data
SEC Parties
DCC
Confirmation
SEC Parties
DCC
Confirmation
20
DCC
SEC Parties
Completed Checklist
21
Set up Configuration
Management Process
DCC
SEC Parties
Completed Checklist
Page 27 of 84
03/10/14 V1.0
DCC Public
Ref
By When
Action
From
To
Information Required
Method
DCC
SEC Parties
Completed Checklist
DCC
SEC Parties
Completed Checklist
SEC Parties
DCC
By email
DCC
ALL
Completed Checklist
DCC
ALL
Completed Checklist
SEC Parties
DCC
by email
& Tool
22
Provision
Connection
Network
23
24
25
15 working days
prior to the start of
IT
Validate eco-system
26
5 working days
prior to the start of
IT
Complete Readiness
Verification
27
Satisfy
Criteria
28
Start of IT
Commence IT
IT
Entry
ALL
One of the key events in the above section is Confirm intention to participate in IT (Ref 8), which is when SEC Parties planning to participate
in IT must declare their intention to do so. Declaration of intention to test must be accompanied by a plan, against which the Users
preparation progress will be monitored. The date of declaring intention to test is when the Service Providers need to know whether or not the
Page 28 of 84
03/10/14 V1.0
DCC Public
planned Test Lab and support facilities will be adequate for the expected demand: for further details of this and the assumptions made, see
Section 7 - Environments, Networks and Test Labs.
IT Test Execution
The table below sets out the steps that must be undertaken during test execution by either the DCC or Testing Participant and the timeframes
within which such steps must be complete.
Ref
By When
Action
From
To
Information Required
Method
User
Connectivity
Validated
(first
2
users)
DCC
North
Region
:
Connectivity
Test
completed
SEC Parties
DCC
SEC Parties
DCC
North
Region:
Additional
Functionality
Tests
completed
DCC
Central
&
South
Region : Connectivity
Test completed
SEC Parties
DCC
Central
&
Region:
completed
SEC Parties
DCC
South
UEPT
Page 29 of 84
03/10/14 V1.0
DCC Public
Another key milestone is User Connectivity Validated (first 2 users) (Ref 1). This is where it has been demonstrated that two SEC Parties in
each Region can successfully connect to the DCC System, by the successful sending of a Service Request and subsequent receipt of a
Response. (All SEC Parties will conduct Connectivity Testing, but for the purposes of milestone planning, the DCC will assume that user
connectivity is validated when two SEC Parties have demonstrated they can successfully connect to the DCC system.)
IT Test Completion
The table below sets out the steps that must be undertaken during test completion by either the DCC or Testing Participant seeking to
undertake IT and the timeframes within which such steps must be completed.
Page 30 of 84
03/10/14 V1.0
DCC Public
Ref
By When
Action
From
To
Information Required
Method
10 working days
before the end of IT
Draft IT Completion
Report
DCC
SEC Panel
End of IT
Final IT Completion
Report
DCC
SEC Panel
DCC website
Page 31 of 84
03/10/14 V1.0
DCC Public
6.8
Dependencies
There are a number of dependencies within IT preparation and execution, which are
described in the following tables. In each case, the milestones and activities listed in the
tables are taken from the above Timetables: Figure 7 Timetable for test initiation and Figure
8 Timetable for test execution.
Milestone
Interface Test Approach
Published
Dependent on
Notes
Completion of industry
consultation
SEC Panel approval
Definition of data
Page 32 of 84
03/10/14 V1.0
DCC Public
6.9
Page 34 of 84
03/10/14 V1.0
DCC Public
7.1
Introduction
The DCC test environment for IT comprises a set of networked environments provided and
supported by each Service Provider, and Test Labs at each of the CSPs premises furnished
with communications hubs and Devices.
The environments, Test Labs and support have been designed on an assumed number of
testing participants (a SEC Party conducting testing for a particular Role) taking part in
Interface Testing. The assumption is that there will be 120 testing participants, of which 90 will
be assigned to test in CSP Central/South and 30 assigned to CSP North.
Should the number of SEC Parties wishing to test simultaneously exceed these numbers,
then the requirements will be assessed, the technical feasibility validated, the relevant
approvals sought, the delivery planned and then the Test Labs and technical support can be
increased accordingly. The long lead times involved mean that an early date for notification of
intention to test has to be given (see section 1 - for the relevant date).
7.2
DCC Enterprise will provide a test environment which contains Billing and Reporting
functionality.
7.3
The DSP will provide a test environment containing all the DSP-delivered components,
including the Self Service Interface (SSI), as well as the network connections used by the
SEC Parties.
7.4
Both CSPs will provide a test SMWAN network, together with test systems connected to the
DSP. If SIT Solution Test has exited with Device stubs and physical smart Devices are still
not available in time to use in IT, CSPs will also provide the Device stubs used in SIT.
7.5
TSP environment
The TSP will provide a test environment containing all the TSP-delivered components.
7.6
The Parse & Correlate software will be provided to the SEC Parties, for installation on their
test environments.
7.7
SEC Parties
SEC Parties will provide and support their own test environments for use in IT, and are
responsible for establishing connectivity with the DSP network. The DCC will provide support
to the SEC Parties as requested and as appropriate.
Page 35 of 84
03/10/14 V1.0
DCC Public
7.8
Each CSP will provide a secure physical environment in which to house the relevant number
of communications hubs and Devices. The CSP will also provide the communications hubs
(Devices will be provided by the DCC in collaboration with the meter manufacturers as
described in the Device Selection Methodology [6]);
Each Test Lab will contain sets of devices, with a set consisting of a minimum of:
one communications hub
one electricity meter
one gas meter,
and other Devices or stubs as required to complete UEPT.
Network operators will be allocated 2 Device sets and all other SEC Parties will be allocated
5 device sets.
Details of support provided by the CSPs during testing are yet to be finalised 4, and the
intention is that the type and level of support offered by the two CSPs will be similar. It is
expected to include support for checking the Devices during testing, as well as facilities which
will allow SEC Parties to house a limited number of their own staff on site and allow them
controlled access to the test labs. The CSP-provided support for checking the Devices will be
via a call-logging system, which will operate two different support methods, using:
requests for support at a specified time in the future (following working day onwards); and
requests for immediate support.
Once a CSP support team member has started working on a particular request, then contact
will be directly between the CSP staff member and the relevant SEC Party staff member,
either by phone or by email. Email contact between the Test Participants will be secured by
TLS or an equivalent method.
Figure 11 Number of device sets shows the numbers of devices available:
Number of Device Sets
Initial Provision *
75
225
25
150
100
375
7.9
Where it becomes evident that a Device that is used in IT for the purpose of UEPT has a
defect, the DCC will de-select that Device in accordance with the Device Selection
Methodology [6].
In doing so, the DCC will first determine if the defect relates to one specific Device or to all
Devices of that specific model. Where the defect relates to one Device, that Device will be
substituted with one of the same type. If the defect relates to all Devices of that model, the
DCC will substitute Devices of that model type with another Device model according to the
Device Selection Methodology. In so doing, the DCC will undertake whatever testing it
deems appropriate to prove that the substitute Device model can communicate with the DCC
in respect of all relevant messages. If it is not possible to substitute the defective Device with
either another of the same model or of a different model, then the DCC will use a test stub in
place of the defective Device.
Page 37 of 84
03/10/14 V1.0
DCC Public
DCC Enterprise
Systems
DSP Systems/
DCC User
Gateway
TSP System
CSP Systems/
SMWAN
Parse &
Correlate
Test Labs
DCC/meter
manufacturer
08:00-18:00 on
working days
08:00-18:00 on
working days
08:00-18:00 on
working days
08:00-18:00 on
working days
08:00-18:00 on
working days
08:00-18:00 on
working days
08:00-18:00 on
working days
A working day is defined as Monday-Friday, excluding England & Wales Bank Holidays.
Page 38 of 84
03/10/14 V1.0
DCC Public
Test Data
8.1
Full details of the test data to be used will be specified as part of a separate exercise and
documented in the Test Data Plan (see Section 6.8.1 for the timeline for production of this
Plan).
The Test Data Plan will cover:
Principles
o
Dependencies
Test Data Management
o
Process
Tool
Data Specification - for each item of data needed for system set-up:
o
The production of this Test Data Plan and subsequent provision of test data for IT will be a
collaborative exercise between all SPs and the SEC Parties participating in TDEG. This will
ensure that SEC Parties have adequate and correctly-functioning data with which to test.
8.2
The principles stated in the Test Data Plan will include the following:
Data provided will be adequate to support the planned number of participating SEC Parties
Page 39 of 84
03/10/14 V1.0
DCC Public
Page 40 of 84
03/10/14 V1.0
DCC Public
8.3
Figure 13 High-level data types and responsibilities for provision shows the main types of
test data in the system and which Test Participant has the responsibility for defining, providing
and maintaining this data.
Data Type
Accountable Party
Service Requests/Responses
n/a
Registration
RDPs
SMS Inventory
DSP
SMKI Repository:
TSP
Organisation Certificates
Device Certificates
DSP
CSP
RDP list
DSP
Mapping:
DSP
DSP
DSP
Network configuration:
User Gateway
DSP
SMWAN
CSPs
SMKI
TSP
System configuration:
DCC Enterprise Provider
Billing
Reporting
Figure 13 High-level data types and responsibilities for provision
Page 41 of 84
03/10/14 V1.0
DCC Public
9.1
Principles
The DCC will provide licences for HP Quality Centre (HP QC), for use by all SEC Parties and
SPs participating in Interface Testing, for logging and resolving testing issues. A single
licence will be provided to each SP and SEC Party and they will be required to record testing
issues directly on the HP QC database.
HP QC is a test management tool, which has facilities to create and manage the following:
Business requirements
Test scenarios and detailed test scripts
Test Phase and Cycle execution details
Testing Issues.
It allows links to be established between the items listed, which facilitate the production of
quality assurance documentation such as Requirements Traceability Matrices (RTM) and test
execution progress reports. Its set-up will be done as shown in Figure 7 Timetable for test .
HP QC will be used to:
manage DSP-led testing
demonstrate traceability between SP Requirements, test scripts and issues.
SEC Parties will use HP QC only for logging testing issues.
The HP QC Issue Repository will comprise several different (and segregated) Projects:
Interface Testing Issue Repository (IT IR) testing s relating to DCC Systems uncovered
in any of the tests conducted as part of IT (i.e. Connectivity, UEPT, Additional Functionality
Tests)
SEC Party Issue Repository (SEC Party IR) one for each participating SEC Party,
containing testing issues relating to that SEC Partys systems (i.e. testing issues which the
SEC Party needs to resolve before exiting their UEPT)
Device Issue Repository (Device IR) one for each manufacturer with a device being used
in IT.
This segregation ensures that one SEC Party cannot see testing issues relating to the
systems of another SEC Party, and that one Device manufacturer cannot see testing issues
relating to the Devices of another manufacturer. However, all Test Participants involved in the
testing will have access to IT IR.
IT IR will be used to record only testing issues attributed to the DCC Systems, and the testing
issues in IT IR will be used to determine whether or not the IT Exit Criteria have been met.
Page 42 of 84
03/10/14 V1.0
DCC Public
9.2
The HP QC instance will be hosted and administered by the DSP. The DCC will ensure that
sufficient licences are available for use by the various Test Participants involved in IT. This HP
QC instance must be used for recording testing issues.
SEC Parties may be using their own HP QC systems for managing their testing issues
internally. In order to support this, IT IR will be set up so as to accept input of new testing
issues by either:
Online input - by being typed into the tool online directly by SEC Party/Service Provider, or
Excel import a template will be provided by the DSP to SEC Parties, to enable them to
capture testing issues once only in their own system, and then have them imported direct
into the DSPs central HP QC system (these templates will be transferred between the
SEC Party and the DSP via secure email).
9.3
A Terms of Reference5 will be created for the IRB, which will meet twice daily during test
execution to review testing issues recorded on the IT IR. Each new testing issue will:
be classified as one of:
o
testing issue:
duplicate
change
5________________________ This will include who can attend, what will be discussed, who
will be expected to attend (with reference to technical triage), what is the process including
outcome, what information is expected to be presented at the meeting to enable successful
triage and how confidential information is treated.
Page 43 of 84
03/10/14 V1.0
DCC Public
9.4
Description
Testing not completely blocked by the testing issue but the impact on test progress is
significant.
Testing can proceed but the work-around for the testing issue has moderate impact on
test progress.
Testing can proceed and the testing issue has little/no impact on test progress.
Figure 14 - Testing Issue Priorities
The following table lists the planned target response times for testing issues, to be measured
from the point at which the testing issue is logged in HP QC.
Page 44 of 84
03/10/14 V1.0
DCC Public
Page 45 of 84
03/10/14 V1.0
DCC Public
Priority
Initial
response
completed
Triage
completed
Assessed by
resolver group
Fix time
assessed
Target Release
identified
1 hour
4 hours
5 hours
13 hours
17 hours
1 hour
Next IRB
Next IRB +
1 hour
Next IRB +
8 hours
Next IRB +
8 hours
N/A
Next IRB
Next IRB +
1 hour
Next IRB +
16 hours
Next IRB +
8 hours
N/A
Next IRB
Next IRB +
1 hour
As required to
meet defect
thresholds
As required to
meet defect
thresholds
9.5
Figure 16 Outstanding testing issues and exiting IT, below shows the maximum number of
testing issues of each severity which are allowed in order to exit IT. Note that the numbers
are given on a per SEC Party per Service Provider basis.
Severity
15
30
Figure 16 Outstanding testing issues and exiting IT
9.6
Reporting of testing issues by SEC Parties in relation to UEPT will be undertaken as specified
in the CTSD/SREPTSD [7].
Reporting of testing issues relating to the DCC Systems will be done by the UIT Manager and
based on the information contained in the IT IR and also in the Device IR. The reports will
contain as a minimum:
Current Testing Issue Status:
o
Page 46 of 84
03/10/14 V1.0
DCC Public
For Severities 1+2 combined, the trend over time of number of testing issues,
shown by status:
o
Separately for each Service Provider (showing testing issues raised against
that Service Provider)
For all Severities combined, the trend over time, of number of testing issues,
shown by status:
o
Separately for each Service Provider (showing testing issues raised against
that Service Provider)
Page 47 of 84
03/10/14 V1.0
DCC Public
10
10.1 Introduction
Details on Test Tracking and Reporting for both test preparation and test execution activities
are described below.
SPs and SEC Parties responsible for documentation deliverables listed in Section 5 Deliverables will report on progress from the point at which this Interface Test Approach
document is published. During the last month of Preparation, the frequency of reporting
changes from monthly to weekly.
The progress report from each Test Participant will be addressed to the UIT Manager. The
UIT Manager will consolidate the information into a single report, which will be made available
to the DCC and all Test Participants (information will be anonymized where necessary). The
DCC will also make this report available to the SEC Panel. The report will be distributed via
email and its classification will be assigned according to the DCC Classification Standard; the
classification is likely to be either DCC CONFIDENTIAL or DCC CONTROLLED.
General
Frequency
From
To
Method
Test Preparation
Progress Report
Monthly
SEC Parties
SPs
RDPs
DCC
TBC
SEC Parties
SPs
RDPs
DCC
TBC
Weekly
From 40 working
days prior to start of
test execution
Test Preparation takes place from the date of approval of this document until test execution
commences.
This means that in the final 2 months before test execution starts, SEC Parties and the DSP
will need to provide both of these reports. There will be minimal overlap, given that the Test
Preparation Report is at a higher level than the Test Readiness Report.
10.2.2
The Test Preparation Progress Report will be delivered on the last Friday of each month. It
relates to the Test Participants preparation for the testing. The Test Participant may not be
Page 48 of 84
03/10/14 V1.0
DCC Public
Date Planned
Date Forecast
RAG Status.
A simple Excel spreadsheet will be made available to facilitate and standardise this reporting.
Each report will be discussed in a short (30 minute) bilateral meeting in the first week of each
month, chaired by the UIT Manager and attended by the reporting Test Participant as well as
the DCC. Any issues or risks of relevance to other SEC Parties that require escalation will
then be identified and discussed at the next TDEG. At this point, the TDEG meetings will be
held monthly.
10.2.3
Frequency
From
To
Method
Test Execution
Dashboard
Daily
SEC Parties
SPs
RDPs
DCC
TBC
Test Support
Progress Report
Weekly
DCC
DECC
By email and
published on DCC
Website
Test Completion
Report
End of Stage
DCC
DECC
By email and
published on DCC
Page 49 of 84
03/10/14 V1.0
DCC Public
Website
Figure 18 Test Execution Reporting
Page 50 of 84
03/10/14 V1.0
DCC Public
11
11.1 General
All parties involved in IT shall:
Comply with the SEC and follow Good Industry Practice when participating in IT i.e. the
exercise of that degree of skill, diligence, prudence and foresight which would reasonably
and ordinarily be expected from a skilled and experienced person engaged in a similar
type of undertaking as that Party under the same or similar circumstances
take all reasonable steps to facilitate achievement of the IT Objective.
Test Participant
DSP (Systems
Integrator role)
Role
Responsible for management and delivery of Interface Testing, (including its
planning, control and tracking)
Provision of test execution and environment usage schedules
Provision of Interface Test Plan
Provision of Test Data Plan
Management of testing issue resolution, provider of HP Quality Centre
Operation of the master Configuration Management Plan
Operation of the Environment Plan
Provision of test scenarios and test scripts for Connectivity and Additional
Functionality Tests
Provision of resource to carry out Additional Functionality Tests
Maintenance of IT RTM
DCC
Page 51 of 84
03/10/14 V1.0
DCC Public
SEC Parties
design and creation of test scenarios, test scripts, test data and test
environments
RDP
TSP
design and creation of test scenarios, test scripts, test data and test
environments
Page 52 of 84
03/10/14 V1.0
DCC Public
DCC Enterprise
Critical Software
design and creation of test scenarios, test scripts, test data and test
environments
Meter manufacturer
(together with DCC)
Supplier of meters to furnish the test labs, working with the DCC
Provision of support for Devices both in labs and when returned to factory
Provision of resource to triage testing issues
SEC Panel
DECC
Ofgem
Page 53 of 84
03/10/14 V1.0
DCC Public
Page 54 of 84
03/10/14 V1.0
DCC Public
11.2.2
Reporting structure
The reporting structure for IT is shown in Figure 20 IT main roles and structure, below:
The UIT Manager will maintain a list of the contact details of the person filling each role for each Test Participant.
Page 55 of 84
03/10/14 V1.0
DCC Public
11.2.3
Role
User Integration Test Manager
Responsibility
The User Integration Test Manager is the person responsible for overall
planning, preparation and execution of Interface Testing. This role
encompasses co-ordination, control, management and
tracking/progress reporting for the testing. It includes directing the
Connectivity and Additional Functionality Tests.
The UIT Manager is provided by the DSP, in its role as overall systems
integrator and reports via the Integration and Acceptance Test
Manager to the DCC Test Programme Manager.
The DCC will provide the DCC Service User Integration Test Manager
to manage UEPT. This role is described in the CTSD/SREPTSD
[7].
The SEC Party IT Manager is the person who has overall responsibility
for their Test Participants planning, preparation and conduct of the
testing, including responsibility for the successful and timely
completion of the testing.
The SP IT Manager is the person who undertakes the planning and
provisioning, and is responsible for providing support to those
executing the tests.
The SP and SEC Party IT Managers also have responsibility for the
tracking and management of all testing issues relating to their
organisation (alternatively they may delegate this to an Issue
Manager). This person attends the daily Issue Review Board and is
responsible for ensuring that testing issues observed by their
organisation are recorded in a timely manner and resolved as
agreed at the IRB.
The Subject Matter Expert (SME) from the SP and from the SEC Party
is available to support IT Manager in resolving testing issues. The
SMEs are able to pin-point the cause of a testing issue and to
collaborate with their counterparts in the Service Providers as well
as other SEC Parties in order to determine responsibility for a
testing issue (whether or not it is a testing issue relating to their own
system), as well as the best way to resolve it.
Figure 21 Roles of Test Management
11.3 Governance
The DCC will provide overall governance of IT and liaise with the following stakeholders:
Page 56 of 84
03/10/14 V1.0
DCC Public
Figure 22 - IT Governance
The Test Design and Execution Group (TDEG) consists of Service Providers, SEC Parties,
Ofgem and DECC. The UIT Manager will report plans and progress at each TDEG meeting,
thus keeping all stakeholders informed and receiving their input.
11.4 Communication
The DCC Programme Test Manager will report plans and progress at each TDEG meeting to
ensure that SEC Parties, SPs, Ofgem and DECC are kept informed. Communication of plans
and progress to the wider community will take place via a report at each Implementation
Management Forum meeting (presented by the DCC Implementation Manager).
The DCC will hold bilateral meetings with SEC Parties as part of the communication process.
Page 57 of 84
03/10/14 V1.0
DCC Public
11.4.1
Progress meetings
A regular progress meeting for DSP-led testing will be held by telephone, chaired by the UIT
Manager and attended by SP IT Managers and DCC Service User Integration Test Manager.
This meeting will review the consolidated progress report and discuss any testing issues
arising. The frequency will match the frequency of the progress reports:
Monthly during most of test preparation (in the first week of each month)
Weekly from one month prior to the start of testing and during the test execution itself
(each Friday).
Progress meetings for UEPT will be as described in CTSD/SREPTSD [7].
For the further details and the contents of the progress reports, see section 10 - Test Tracking
& Reporting.
11.4.2
The testing issue management process is described in general in Section 9 - Testing Issue
Management.
However, there may be urgent testing issues which require immediate communication with
the Test Participants involved in testing. For this reason, all SEC Parties and SPs are
expected to be available on email or the phone at all times during the hours of testing. If, for
example, the system has to be taken out of service, then this will be communicated by the
UIT Manager to the SPs and to the DCC Service User Integration Test Manager by both email
and text message. The email will be marked High Importance (with !) and will be sent to an
email address designated in advance. The text message will be sent to the designated
phone number. A response is required within 30 minutes (at least an acknowledgement) to
such communications. If there is no response, then the UIT Manager will place a phone call
to the designated phone number. If there is still no response, then the necessary action will
be implemented regardless. The UIT Manager will have a dedicated phone for this purpose.
Email exchange will be secured by TLS or an equivalent method.
Introduction
The UIT Manager will assure the test scripts for Connectivity and Additional Functionality
Tests.
The DCC will assure IT as described in the Joint DSP/CSP Test Strategy [2], using the
following methods:
Quality Gate Reviews
Test Quality Audits
Product inspections
Page 58 of 84
03/10/14 V1.0
DCC Public
11.5.2
There will be a Quality Gate Review between the Solution Test Stage of SIT and the Interface
Test Stage. This Review will be chaired by the DSP, approved by the DCC and attended by
the Service Providers.
As approver, the DCC will set the outcome of the Review as one of the following:
Solution Test Stage can close, Interface Test Stage can start, only minor (if any) remedial
actions required, or
Solution Test Stage cannot close until remedial actions have been completed, Interface
Test Stage can start, or
Solution Test Stage can close, Interface Test Stage cannot start until remedial actions
have been completed, or
Solution Test Stage cannot close, Interface Test Stage cannot start, until remedial actions
have been completed.
The Quality Gate Review meeting will be a short, checklist-driven event at which previously
assembled and validated evidence relating to the Exit and Entry Criteria is considered and
decisions made to close Solution Test and start Interface Test. It is expected that Quality Gate
Review meetings will be dry-run to enable testing issues to be identified and resolved in a
timely manner, and thereby avoid impacting the start date for Interface Test.
The Solution Test Stage will complete (and achieve its Milestone) on attainment of its Exit
Criteria. The Interface Test Stage will commence (and achieve its Milestone) on attainment of
its Entry Criteria.
Test Stage Complete certificates will be issued by the DCC as follows:
Item
No.
Resulting Certificate
Interface Testing
(Central) Test Stage
Complete Certificate
Page 59 of 84
03/10/14 V1.0
DCC Public
and
all other Stage Exit Criteria achieved
3
11.5.3
Test Witnessing
The DCC will agree with the DSP a witness execution schedule for the Connectivity and
Additional Functionality Tests.
The protocol for this witnessing is described in the Joint Test Strategy.
11.5.4
By prior agreement with the Service Providers on the timing, duration and scope, the DCC
may perform Test Quality Audits of Interface Testing.
The protocol for conducting these Audits and addressing queries/issues is described in the
Joint DSP/CSP Test Strategy [2].
Such Audits will include reviewing that the Exit Criteria for Interface Testing have been met.
Reviewing that Exit Criteria have been met may include a review of the IT Stage Completion
Report and the testing issues raised during IT. Upon issue of the IT Stage Completion
Report, the DCC will review it within 10 working days, or within a mutually-agreed period.
11.5.5
Product inspections
By prior agreement with the Service Providers on the timing, duration and scope, the DCC
may conduct on-site product inspections.
The protocol for conducting these product inspections and addressing queries/issues is
described in the Joint DSP/CSP Test Strategy [2].
11.5.6
Documentation review
The DCC may undertake a review of any documents (including Design documents) used in
testing by the Service Providers.
The protocol for conducting these reviews and addressing queries/issues is described in the
Joint DSP/CSP Test Strategy [2].
Page 60 of 84
03/10/14 V1.0
DCC Public
12
Operational Acceptance Testing (OAT) is a separate testing activity and will have its own
scope, Test Approach and Test Plan documents. Its purpose is to verify that the solution:
can be installed and configured in the production environment
can be operated by the Service Management function under normal and exceptional
conditions
complies with the non-functional requirements
will meet its Service Level Agreements.
Such verification includes but is not limited to:
installation and configuration testing
end to end security testing, including penetration testing and the Security Operation
Centres
service monitoring and reporting
BCDR testing:
o
performance testing
testing of the Service Management processes
functional testing of service management tools
backup and restore testing.
OAT will be performed in the production environment before go-live, in parallel with the SIT
and IT phases. Where practical, the test results will be provided in the SIT and IT Completion
Reports, otherwise they will be reported separately to the SEC Panel for information
purposes.
.
Page 61 of 84
03/10/14 V1.0
DCC Public
Appendices
Page 62 of 84
03/10/14 Version 1.0
DCC Public
A. Test Scenarios
i.
Connectivity to the DCC for EIS, EES, GIS or RSA SEC Party roles
Prerequisite:
Energy Relevant Party holds the role of EIS, EES, GIS or RSA
SEC Party completion of Registration and Enrolment of Organisations and their representatives to the DCC Registration Authority following the processes
described in the Registration Authority Policies and Procedures (RAPP) in order to acquire access to the SMKI using the SMKI Portal and also to the SMKI
Repository.
Step
s
Description
Objective
Device
Prenotification
Populate
Inventory
Smart
Metering
Actions
Acceptance Criteria
1.
The SEC Party will receive the read the response that
will contain all data item in the SMI for the device
performed in Step 1.
Read Inventory
1.
Page 63 of 84
03/10/14 Version 1.0
DCC Public
Description
Objective
Actions
Acceptance Criteria
Test verification
1.
ii.
Page 64 of 84
03/10/14 Version 1.0
DCC Public
Prerequisite:
Step
s
Description
Objective
Actions
Acceptance Criteria
Read Inventory
1.
The SEC Party will receive the read the response that
will contain all data item in the SMI for the device(s).
Test verification
1.
Page 65 of 84
03/10/14 Version 1.0
DCC Public
ii.
Page 66 of 84
03/10/14 Version 1.0
DCC Public
Change of Supplier (On-Demand) Test Scenario for EIS SEC Party Role
Test Scenario
Title:
Prerequisite:
Dummy DCC Supplier setup as old supplier for take on the specified Devices.
Registration Test Data setup to match test scenario for the CoS date.
Step
s
Description
Change
Supplier
request
of
Objective
Actions
Acceptance Criteria
1.
ii.
Update
Security
Page 67 of 84
03/10/14 Version 1.0
DCC Public
Description
Objective
Actions
Acceptance Criteria
Update tariff
1.
DUGIDS
SR
6.8
Update
Configuration (Billing Calendar)
Device
1.
2.
Update billing
calendar
Retrieval
of
Debt and Credit
Billing Data Log
Test verification
1.
1.
Device
Page 68 of 84
03/10/14 Version 1.0
DCC Public
Change of Supplier (On-Demand) Test Scenario for GIS SEC Party Role
Test Scenario
Title:
Prerequisite:
Dummy DCC Supplier setup as old supplier for take on of the specified Devices.
Registration Test Data setup to match test scenario for the CoS date.
Step
s
Description
Change
Supplier
request
of
Objective
Actions
Acceptance Criteria
1.
ii.
Update
Security
Page 69 of 84
03/10/14 Version 1.0
DCC Public
Description
Objective
Actions
Acceptance Criteria
Update tariff
1.
DUGIDS
SR
6.8
Update
Configuration (Billing Calendar)
Device
1.
2.
Update billing
calendar
Retrieval
of
Debt and Credit
Billing Data Log
Test verification
1.
1.
Device
Page 70 of 84
03/10/14 Version 1.0
DCC Public
1. A SEC Party wishes to request the Postcode Coverage Report via the SSI using the DCC IDP (Identity Provider).
Test Scenario
Title:
Self Service Interface CSP SMWAN Network Coverage Request for EIS, GIS, EES, ENO, GNO, RSA or OU SEC Party Roles.
Prerequisite:
Energy Relevant Party holds the role of EIS, GIS, EES, ENO, GNO, RSA or OU.
CSP Coverage Database to be populated with appropriate test data for each region.
Step
s
Description
Objective
Actions
Acceptance Criteria
1.
CSP SMWAN
Network
Coverage
Request
1.
2.
Page 71 of 84
03/10/14 Version 1.0
DCC Public
Description
Objective
Actions
Acceptance Criteria
Test verification
1.
2. A SEC Party wishes to request the Postcode Coverage Report via the SSI using their own IDP (Identity Provider).
Test Scenario
Title:
Self Service Interface CSP SMWAN Network Coverage Request for EIS, GIS, EES, ENO, GNO, RSA or OU SEC Party Roles.
Prerequisite:
Energy Relevant Party holds the role of EIS, GIS, EES, ENO, GNO, RSA or OU.
CSP Coverage Database to be populated with appropriate test data for each region.
Step
s
Description
Objective
Actions
Acceptance Criteria
1.
CSP SMWAN
Network
1.
Page 72 of 84
03/10/14 Version 1.0
DCC Public
Description
Objective
Coverage
Request
Test verification
Actions
2.
1.
Acceptance Criteria
3. A SEC Party wishes to confirm that they can access the Ordering of Communications Hubs and Auxiliary Equipment webpage via the SSI:
Test Scenario
Title:
Self Service Ordering of Communications Hubs and Auxiliary Equipment Request for EIS or GIS SEC Party Roles
Prerequisite:
SEC Party SSI login authentication via either DCC IDP or own IDP.
Page 73 of 84
03/10/14 Version 1.0
DCC Public
Description
Objective
Actions
Acceptance Criteria
Login to SSI
1.
Access
to
Ordering
of
Communication
s Hubs and
Auxiliary
Equipment
webpage via the
SSI
1.
Selecting
the
Forecasting
and
Ordering
of
Communications Hubs and Auxiliary Equipment option
will present SEC Party with all 3 CSPs buttons.
2.
Test verification
1.
Page 74 of 84
03/10/14 Version 1.0
DCC Public
1. DCC Enterprise System to receive for the billing for the Enrolled Smart Meter Report via the DCC Enterprise Systems Interface.
Test Scenario
Title:
DCC Enterprise System to receive for the billing for the Enrolled Smart Meter Report via the DCC Enterprise Systems Interface.
Prerequisite:
DSP to pass scheduled report to DCC Enterprise System via the FTP Server
Step
s
Description
Objective
Actions
Acceptance Criteria
DSP
report
1.
2.
trigger
DSP
to
initiate
scheduled
Enrolled Smart Meter Report
DCC to access
report
1.
Test verification
1.
Page 75 of 84
03/10/14 Version 1.0
DCC Public
Page 76 of 84
03/10/14 Version 1.0
DCC Public
1. The DCC creates the Monthly Service Provider Performance Statistics Report.
Test Scenario
Title:
The DCC creates the Monthly Service Provider Performance Statistics Report.
Prerequisite:
The CSPs to capture and then send performance data to the DSP via the CSP Management Interface.
The DSP to pass the performance data to the BI/MI System via the ESI.
Step
s
Description
Objective
Actions
Acceptance Criteria
Access BI/MI
1.
Producing the
Monthly Service
Provider
Performance
Statistics
Report
1.
Test verification
2.
Page 77 of 84
03/10/14 Version 1.0
DCC Public
1. Generating a volume of traffic over the DCC System, performed by EIS, GIS, ENO and GNO SEC Party Roles.
Test Scenario
Title:
Volume Test for EIS, GIS, ENO and GNO SEC Party Roles.
Prerequisite:
Energy Relevant Party holds the role of EIS, GIS, ENO, or GNO.
SEC Parties have test evidence that they are able to perform the DUGIDS SR 4.1.1 Read Instantaneous Import Registers Service Request on the specified role.
Time and date provided to participating SEC Parties by the DCC for start and duration of Performance Test. (the test duration is constructed to allow for
consecutive parallel execution of Service requests by each SEC Party role).
SEC Party resource allocation confirmed for supporting the performance testing.
System to be subject to load (using a stub) to a proportionate volume to the load used in SIT.
Step
s
Description
Objective
Actions
Acceptance Criteria
Read
Instantaneous
Import
Registers
1.
Page 78 of 84
03/10/14 Version 1.0
DCC Public
Description
Objective
Actions
Acceptance Criteria
Service
Request
verification
1.
2.
Page 79 of 84
03/10/14 Version 1.0
DCC Public
2.Generating a volume of traffic over the DCC System, performed by EES, RSA and OU SEC Party Roles.
Test Scenario
Title:
Prerequisite:
SEC Parties have test evidence that they are able to perform the DUGIDS SR 6.2.4 Read Device Configuration (Identity Exc MPxN) Service Request on the
specified role.
Time and date provided to participating SEC Parties by the DCC for start and duration of Performance Test. (the test duration is constructed to allow for
consecutive parallel execution of Service requests by each SEC Party role).
SEC Party resource allocation confirmed for supporting the performance testing.
System to be subject to load (using a stub) to a proportionate volume to the load used in SIT.
Step
s
Description
Objective
Actions
Acceptance Criteria
Read
Instantaneous
Import
Registers
1.
DUGIDS
SR
Configuration
6.2.4
Read
Device
Page 80 of 84
03/10/14 Version 1.0
DCC Public
Description
Objective
Actions
Service
Request
verification
Acceptance Criteria
2.
SEC Party.
Page 81 of 84
03/10/14 Version 1.0
DCC Public
B. Documentation RTM
This RTM will be revised each time a revision is made to this document.
The RTM is contained in the following Excel document:
Microsoft Excel
97-2003 Worksheet
Page 82 of 84
03/10/14 Version 1.0
DCC Public
UEPT
Additional Functionality
OAT.
If a statement is relevant to IT and is not covered elsewhere, then an Additional
Functionality test scenario is described for it. These scenarios are summarized in
Appendix A - Test Scenarios.
Section G Security is wide-ranging and is verified in different ways. During IT, a duty
of care with regard to the test environment will be exercised, to ensure that there are no
breaches of security. Some security-related testing will be carried out in PIT, which will
include, but is not limited to:
recording system activity in audit logs
ensuring backed up data is protected
checking that expired data is securely deleted
detecting Anomalous Events.
Other tests, which can only be carried out on the Production environment, will be done
during OAT and these include:
detecting unauthorised connections and software
identifying deviations from expected system configuration
identifying
service
unauthorised
network
port/protocol/communication/application/network
Page 83 of 84
03/10/14 Version 1.0
DCC Public
Microsoft Excel
97-2003 Worksheet
Page 84 of 84
03/10/14 Version 1.0
DCC Public