Skip to main content

Testing strategy for compliance with remote gambling and software technical standards

Procedure for testing

We maintain and publish a list of approved test houses authorised to perform third party testing. Licensees and their chosen test house will need to agree the scope of testing, which must be sufficient to ensure that testing will adequately assess compliance with our standards and meet the level of testing required under this strategy. This primarily applies to the RTS requirements outlined in rows 2 and 3 of Table 1.

Level and scope of testing required 

RNG testing:

  1. Review of RNG documentation to understand the implementation of RNG in the gaming system.
  2. Research about RNG algorithm/hardware to ensure there is no publicly known weakness or vulnerabilities associated with the RNG under evaluation.
  3. Review of source code to verify the implementation of RNG is in accordance with the RNG documentation.
  4. Statistical testing of raw output of RNG and scaled/shuffled decks data.
  5. Any issues or non-compliance are reported to the supplier. Once resolved, these issues are re-evaluated to confirm the non-compliance has been addressed adequately.

Game testing:

  1. Verification of game design – Maths, artwork/rules as displayed to players, and theoretical RTP.
  2. Software testing - This involves verifying the software implementation of the above game design, artwork, maths and theoretical RTP through testing of the game on an environment which reflects the intended live environment; verification of game rules, actual RTP using simulation (Simulation (output) testing – setting the game up to play automatically for a high number of games (actual number will depend on volatility of the game as per the game maths) to verify that the actual RTP is within an acceptable range of the expected RTP. Sample data should be tester generated, unless supervised in a controlled environment for the purposes of meeting specific regulatory requirements. Software modified from the original to enable rapid play is permitted provided the tester has confidence that the modifications do not impact on the assessment of game fairness), emulation (Emulation testing is used to replicate certain rare game outcomes (such as jackpot triggers, special features and maximum prizes)) and manual  testing (Manual game play - actually playing the game to verify all activity observed works as expected (eg playing a game for one hour would allow the tester to see most of the common prizes and determine whether pay lines are implemented correctly etc); any scaling and mapping used to convert raw RNG output to game outcomes.

We support and participate in the International Association of Gaming Regulators (IAGR) Multi-Jurisdictional Testing Framework. This framework aims to standardise technical standards and testing requirements between participating jurisdictions in order to reduce testing duplication for products deployed internationally. Further details are available on the IAGR website

Any additional integration testing required (for example when the game will be utilised with a different RNG or platform to the original game testing) is covered in the Gambling Platform/RNG changes below. Testing in these instances will be determined by the licensee in conjunction with the test house and will depend on the changes made to integrate the software as well as the amount of previous testing that can be relied on. 

For games, the testing report should include at least:

  • test house details including the test supervisor that signed off the testing
  • licensee name
  • date of testing
  • certificate reference
  • game details – including game name, return to player (RTP), software number and digital signature
  • scope and approach to testing and a description of all tests applied
  • platform supplier and platform version
  • channels (game clients) covered by testing 
  • result of testing
  • details of games/versions of games that the game supersedes
  • where a limited scope of testing has occurred due to changes within a previously tested game, an updated games test report must be provided to the Commission, making reference to the original games test report, changes made, testing completed and new digital signatures.

For RNGs, the testing report should include:

  • test house details including the test supervisor that signed off the testing
  • licensee name
  • date of testing
  • certificate reference
  • RNG details – brief description of the RNG and its use including RNG version, whether it is hardware and/or software and digital signature
  • scope and approach to testing and a description of all tests applied
  • platform supplier and platform version
  • Any limitations on the use of the RNG should be cited. This might include but not be limited to: 
    • the acceptable degrees of freedom (DOF) permitted for the RNG, 
    • whether it is suitable for use with / without replacement, and 
    • any dependency on operating system functionality that if modified could impact on the operation of the RNG (eg Java SecureRandom).
  • results of testing.


Licensees (the following categories of licences require games and RNG testing by an independent test house (subject to a best practice declaration):Remote general betting (standard) (virtual events), remote betting host (virtual events) remote pool betting, remote casino, remote casino (game host), remote bingo operating, remote bingo (game host) and remote lottery licences(entries greater than £250,000 per year) must send the results of testing (Where a licensee relies on a B2B for the provision of games they should receive a games register reference number from the B2B to upload the relevant game to their games register, therefore alleviating the need to re-submit the same report) (ie a test house’s game/RNG report) to the Commission on completion of satisfactory testing (but prior to release). All new games and RNGs can only be released once the testing has been completed and the report provided to the Commission. 

The games/RNG reports should be uploaded to the licensees games register via the eServices portal.

B2C licensees who utilise the services of a B2B for the provision of gaming content must still maintain their own up to date games register for any games offered directly or via the B2B. 

Game updates

For the purposes of this document, an update that does not impact game fairness is referred to as a minor update and can be released without the need for external retesting. For illustrative purposes, a non-exhaustive list of major/minor updates is provided in Annex A.

Licensees in conjunction with their test houses will be expected to use their own judgement as to those changes that do not affect game fairness and for all updates will need to ensure they: 

  • adhere to the minimum change control standards (In-house development, testing and release - good practice - sets out the minimum change control requirements that licence holders will be expected to adhere to. Licence holders may adopt alternative approaches those set out if they have actively taken account of the requirements and can demonstrate that an alternative approach is reasonable in the particular circumstances or that to taken an alternative approach would be acting in a similarly effective manner) 
  • maintain a record of all updates in change control documentation, which must be available upon request for inspection 
  • ensure a relevant personal management licence (PML) holder (or in the case of a small scale licensee, the relevant qualified person), is responsible for the process.

All of the above will be subject to an annual audit by an approved test house (In-house development, testing and release - good practice). 

These provisions do not affect the requirement for licensees to submit software for external testing for all new games (or updates to existing games when changes affect game fairness) and to submit the test reports (via the games register on the eServices portal) to the Commission prior to release.           

Testing environment and gambling platform/RNG changes

We expect game testing to occur using the software and environment intended for live operation. Test houses would need to perform some integration testing where there are differences in the live environment compared to the test environment which could affect the fairness of games. 

There are a number of games and RNGs brought under Commission regulation via transitional arrangements from other jurisdictions. Where previous testing was deemed satisfactory (previously known as level 3 testing) these games could continue to be used without need for further testing. Where the games had not been level 3 tested then further testing was required to be completed by 31 October 2015. Updates to any transitioned games should be assessed in accordance with this testing strategy (that is updates which may impact fairness need to be externally retested as per the game updates section above).

In some instances an update will be made to a remote gaming system (RGS) or an RNG which could affect the functionality, and therefore fairness, of hundreds of games served by the updated RNG or residing on the updated RGS. In this scenario licensees must ensure a representative sample of games are retested to ensure the RGS/RNG change has not affected their operation. 

The sample should be wide enough to include each game type and generation (and not be restricted to RNG functionality or games with similar characteristics). The nature and size of the representative sample and the full scope of the integration testing should be decided by licensees in conjunction with an approved test house. 

Details of this testing may be captured in a single test report and evidence retained by the license holder. The Commission expects testing to have been completed prior to launching the updated RNG or RGS.

New channel testing

Where a licensee wants to release a new channel for an existing game they must ensure that channel has been tested by an approved test house. Normally, when a game is first tested for release, it will be tested using the intended channel(s) it will be offered via, for example HTML 5 and native mobile app. Over time, and as newer channels become popular, existing games may be ported across to those new channels. As the channel represents the main player interface it is important that its operation is tested. 

The subset of tests for a new channel will generally be limited to the user interface and player display aspects of a game, such as a manual test to see how the game client displays results. If the backend game design and functionality have not been altered to accommodate the new channel, as is usually the case, then these aspects will not need retesting. Submission of test reports for new channels added to existing games is required, as above. Reference should be made to the original game test report.

Where third party client operating systems and browsers (for example, updated versions of the mobile operating system provided by Apple or Google for mobile devices; or the version of the internet browser software increases)  are updated this generally won’t require external retesting. We would expect the licensee’s own testing to confirm satisfactory performance of existing games when new client operating systems and browser versions are released (note this is different to updates for the RGS or RNG, which underpins the game engine. Such updates may require games to be retested as per gambling platform/RNG changes in the above section).

Where a game is designed to work on a variety of devices or browsers testing should be of the most commonly used devices and browsers, these should be identified within the test report.

Testing and audit requirements for remote lottery licensees

This section sets out the criteria that applies to remote lottery licensees (by lottery licensees we mean, remote lottery operating licensees, converted lottery operating licensees (but only those licensees that run remote lotteries themselves or via a lottery manager) or remote lottery managers’ operating licensees (also known as external lottery managers) licensed under the Gambling Act 2005) (including external lottery managers) when determining specific testing and audit requirements. 

Holders of remote lottery licences that accept no more than £250,000 worth of entries per year by means of remote communication will not be required to submit their RNG for testing by a Commission approved test house or undertake a third party annual security audit. 

Instead, and in terms of RNG testing, such licensees will need to demonstrate that:

  • their RNG has been tested or verified as being fair and random by an independent and suitably qualified third party. This must be supported by documentary evidence
  • they have policies and procedures in place which set out how they ensure the lottery draw is fair and open and can produce evidence that these procedures are followed.

In terms of the third party security audit requirement, such lottery licensees will instead be required to demonstrate to the Commission on request that they comply with the RTS security requirements as set out in Section 5 of the RTS. 

Holders of such licences that accept more than £250,000 worth of entries by remote means per year will be required to meet the full RNG testing and third party security audit requirements as set out in Table 1.
 

Back to contents list

Also see

Testing strategy for compliance with remote gambling and software technical standards

387 KB Download

Annual games testing audit template

90 KB Download