The Gambling Commission website uses cookies to make the site work better for you. Some of these cookies are essential to how the site functions and others are optional. Optional cookies help us remember your settings, measure your use of the site and personalise how we communicate with you. Any data collected is anonymised and we do not set optional cookies unless you consent.

Set cookie preferences

You've accepted all cookies. You can change your cookie settings at any time.

Skip to main content

Strategy

Testing strategy for compliance with remote gambling and software technical standards

Requirements for the timing and procedures for the testing of remote gambling products.

6 - In-house developing, testing and release - good practice

6.1 To be permitted to carry out their own testing of gambling products licensees will be required to adhere to the below good practice guidelines in development, testing and release control of gambling products and/or systems.

6.2 Table 1 details what testing can be carried out by licensees, where a licensee does not conform with these guidelines the required testing must be carried out by an approved third party test house.

6.3 The Commission may, on request, require evidence from the licensee that it complies with these good practice guidelines. Licensees in scope for the annual games testing audit will have their controls assessed as part of that.

6.4 Controls to address the below good practice guidelines would already exist in an organisation compliant with ISO27001.

6.5 Development process:

  • source code should be held in a secure environment
  • an audit log of all accesses to program source should be maintained
  • old versions of source code and the dates they were retired should be retained
  • access to source code by developers should be well controlled and based on a minimum access required for the job approach
  • Source code should be accompanied by appropriate technical documentation suitable for independent review
  • all source files should contain sufficient commenting to explain file/class/function purpose
  • source code should be sufficiently legible and structured to permit static code analysis and for the review of its functionality to be conducted with confidence
  • write access to platform source code should not be granted to those working only on game specific development
  • changes to critical modules need to be peer reviewed by appropriately skilled but independent developers to ensure all changes made are appropriate and in line with the change documentation. Any suspicious or unauthorised changes must be explained.

6.6 Testing process:

  • logically separate development and testing environments
  • separate staff to those that developed should perform the testing (in an agile development environment testing staff may be within the same team as developers testing iteratively alongside them)
  • an independent assessment of changes made by the developers should be performed to verify all changes are documented in the change documentation. This may involve the use of file comparison programs to quickly identify all changes.

6.7 Change management: All game and critical system changes (as defined in 7.7 as follows) should be supported by a change management plan which should:

  • be documented
  • be managed by someone with the necessary proficiency and expertise to oversee the change and make decisions
  • ensure adequate testing, change control mechanisms and authorisations are in place for the software migration into the operational environment.

Accompanying any RNG/game change, the change documentation must record:

  • unique change ID
  • game number/RNG identifier
  • delivery channel(s)
  • description of change
  • whether the modification is classified as major or minor
  • justification for classification
  • for minor changes: confirmation they have been internally tested and the changes documented
  • for major changes: confirmation of adequate external testing house
  • assessment
  • relevant manager’s authorisation for change
  • other particulars as required by the licence holder’s internal change management requirements.
Previous section
5 - Live RTP monitoring
Next section
7 - Third party annual security audit
Is this page useful?
Back to top