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

13�2 Synchronized and asynchronous testing mode testers records events, and a data set can contain all
The following variants of testing, and respective events (T1 to T7) defined in the modelling of the use
terminology, are defined to take care of these situ- case.
ations. The FTL may select from these variants In situations where teams are separated, the team
according to his assessment of the situation and the in A Party role records events T1 through T6 in one
requirements of KPI to be produced. data set, and the team in the B Party role records T7
Both modes are still assuming paired teams sending in another one (optionally, T1 can also be recorded
money to each other. in this set, indicating the point in time from where
Synchronized testing: In this mode, A and B party reception of a notification is expected). Respective
roles are exchanged cyclically. The B-party role data are then combined during post processing.
is ended with reception of a T7 event, or when a The principal flow in synchronized testing is shown in
pre-defined time-out is reached. the figure below.
In situations where teams are working in the same
location or have real-time communication, one of the

Figure 9 – Principal action flow for synchronized testing

Asynchronous testing: In this mode, testers on both tion, or where KPI using T7 are considered to be not
teams act independently in the respective A Party required.
role. This means that Team 1 and Team 2 generate In comparison to synchronous testing, the amount of
transactions independently towards each other. In money to be held in credit on each device has to be
this mode, T7 is not recorded, and KPI containing T7 higher, as in the extreme, only one team may send
will not be computed and reported. money for an extended period of time.
The asynchronous testing makes sense where teams
have different working hours, frequency of opera-

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