Testing strategy for compliance with remote gambling and software technical standards
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
- relevant manager’s authorisation for change
- other particulars as required by the licence holder’s internal change management requirements.
5 - Live RTP monitoring Next section
7 - Third party annual security audit
Last updated: 27 May 2021
Show updates to this content
No changes to show.