Page 20 - Methodology for inter-operator and cross-border P2P money transfers

time. Only then it is possible to create respective KPI are required to assign measurement data to the right
correctly. context.
For instance, assume Team 1 and 2 are running a Basically there are several types of electronic IDs:
national test between two DFS providers, and at the
same time, team 3 and 4 is running a cross-border • Fixed ID’s, such as IMEI or MAC addresses. In most
test on another set of DFS providers. For a given cases they can be read electronically by apps
transaction for the national test, timer flags T1 to through respective API’s. However, in recent years
T6, are taken by team 1, while T7 is taken by team 2. operating systems put restrictions on this type
For the cross-border test, T1 to T6 is taken by team of ID as they allow identification of devices and
3 and T7 is taken by T7. Likewise, network perfor- therefore – in case where devices are also used for
mance tests are also collected by respective devices personal purposes – may create privacy issues.
in different locations. • Dynamic ID’s which are created with every new
Assuming that all data is imported to the same data- installation and which are not lined to any static
base – which is the usual way to process data for attributes or properties of the platform.
best efficiency – allocation of respective device ID
to DFS service test scenarios has to be made, which In any case, suitable ID’s need to be unique, i.e., it
requires corresponding information about measure- must be made sure that no two devices or rather,
ment system allocation and testing schedules. Also, data sources, have the same ID to prevent mix-up
the process of data cleansing – removing of data data assignments.
which is considered to be not valid – requires respec- In the current case, it is assumed that devices are
tive information. sourced exclusively for testing purposes, so fixed ID’s
In many cases, it may be possible to deduct informa- are not problematic. The MSW provides, however,
tion which identifies the scenario under test by using dynamic ID generation and is therefore more versa-
information in the primary data source, e.g., GPS tile.
locations in the background-testing data. However, There are two central lists, maintained by the Field
as the methodology is supposed to work in a robust Test Lead (FTL) in co-operation with the entity
way under a wide range of conditions, it cannot managing the overall testing activities:
be guaranteed that these information sources will
always have sufficient information. For instance, if • The Device Assignment List (DAL) holds informa-
tests are done from within a building, a valid GPS tion about the assignment of devices and tool app
position fix may not be available. Therefore, frame or ID’s to teams.
top-level information should be provided. • The Team Assignment List (TAL) is holds infor-
Basically, such frame information can be provided mation about the time schedule of scenarios and
centrally or locally. As such tests are typically done respective team pairings (under the assumption
in a planned manner with a central management that each team runs one end of a two-way MoMo
entity, there should be a register of team, device, use case as defined in the Transaction Model).
and scenario allocations versus time. For maximum The TAL is used both for planning activities, as for
robustness, it is recommended to also collect this documenting them afterwards.
information again locally, i.e., using log sheets list-
ing what has actually been done by the teams. As Important note: If team assignments change, it is
this information is typically high-level, i.e., taken only especially important to keep good record of these
once per location or testing session, load on teams is assignments, to prevent data loss or artefacts due to
low and the extra redundancy improves the overall unclear or incorrect combination of data from differ-
robustness of testing. ent teams/data sources.
This methodology is designed to be robust in the Copies of the DAL and TAL are imported to the
sense that a certain degree of redundancy is main- post-processing database and serve as the source of
tained for information which is essential to proper assignment operations required to generate KPI and
data evaluation. The most essential information is other report information.
which teams are paired for a given test case, and In addition, each team uses log sheets (in paper or
about the assignment of electronic ID’s of respective electronic form) to document their activities local-
tool installations. ly. These log sheets provide an additional layer of
These electronic ID’s are the most essential single robustness by providing redundancy of information
elements of a test and measurement set-up, as they with respect to central lists.

18 Methodology for inter-operator and cross-border P2P money transfers