Un envío para certificar un juego de casino debe vincular un candidato de release exacto con el código, las matemáticas, las reglas, el arte, la configuración, el entorno y las evidencias de prueba que lo describen. Una carpeta con documentos correctos por separado no está lista si el laboratorio no puede demostrar que todos pertenecen a la misma versión del juego y al mercado objetivo.
Para un responsable de producto del estudio, responsable de cumplimiento, responsable de pruebas, equipo de onboarding del operador o comprador de procurement, la decisión es si el paquete está completo y es coherente antes de comenzar las pruebas independientes. El artefacto útil es un índice controlado del envío y una matriz de alcance que nombren cada elemento, versión, responsable, dependencia y requisito aplicable del mercado.
Elija el mercado y la vía de pruebas antes de cerrar el paquete
La preparación del envío comienza por la jurisdicción objetivo, el licenciatario responsable y la vía de pruebas autorizada. Esas decisiones determinan qué normas aplican, quién puede probar, qué informes deben presentarse y si puede reutilizarse una evaluación anterior.
El procedimiento de pruebas de la UK Gambling Commission exige que los licenciatarios y el laboratorio homologado elegido acuerden un alcance suficiente para las normas de la Comisión. La Comisión mantiene una lista de laboratorios homologados, pero esa lista se aplica a su propio marco de pruebas. No es un directorio universal para todos los mercados.
Ontario ofrece otro ejemplo. La política de certificación tecnológica de la Alcohol and Gaming Commission of Ontario asigna obligaciones a operadores y proveedores relacionados con el juego que ejecutan sistemas críticos, y exige que los juegos, generadores de números aleatorios y componentes de apuestas aplicables sean certificados por un laboratorio independiente registrado antes del despliegue. Las pruebas anteriores solo pueden considerarse cuando el laboratorio determina que siguen siendo relevantes para las normas de Ontario.
Redacte una declaración de alcance de una página antes de empaquetar archivos. Nombre las versiones de juego y tabla de pagos, canales, mercados objetivo, configuración del operador, dependencias de plataforma y RNG, tipo de envío, normas aplicables, contacto del laboratorio, responsable de presentación y límite previsto del release. Marque cada incógnita como una decisión abierta en lugar de ocultarla en una lista genérica.
Cree un único índice controlado del envío
El índice del envío debe ser el inventario autorizado de todo lo que recibe el laboratorio y de cada elemento pendiente. Conecta el alcance de negocio con las evidencias técnicas y evita que un hilo de correo o una carpeta de carga se conviertan en el registro accidental.
Asigne a cada elemento un identificador, título, revisión, responsable, ubicación fuente, nombre de archivo enviado, resumen criptográfico cuando corresponda, fecha de entrega, tratamiento de confidencialidad y relación con el candidato de release. Incluya código fuente, binarios compilados, instrucciones de build, firmas, documentos matemáticos, reglas, arte, configuración, entornos compatibles, utilidades de prueba, informes anteriores, registros de cambios y excepciones conocidas solo cuando pertenezcan al alcance acordado.
Los Requisitos compuestos de envío, versión 2.0 de GLI describen documentación y materiales que pueden solicitarse para evaluaciones y advierten expresamente que los requisitos específicos de cada jurisdicción pueden añadir elementos. Trátelos como una referencia práctica para preparar el envío, no como una promesa de que un solo paquete satisface a todas las autoridades.
Asigne un responsable único del envío y un responsable técnico para cada familia de evidencias. El índice también debe indicar quién puede responder preguntas del laboratorio, aprobar material corregido y decidir si una consulta revela un cambio de producto o solo una aclaración de las evidencias.
Vincule el código, los binarios y la identidad de la build
La identidad de la build debe permitir rastrear el ejecutable enviado hasta el código revisado y el candidato previsto para release. Un nombre de archivo o una versión semántica no demuestran por sí solos esa relación.
Registre la revisión del repositorio, estado del lockfile de dependencias, entorno de build, versiones del compilador o herramientas, comando de build, entradas generadas, resúmenes de artefactos y estado de firma. Conserve los binarios enviados como artefactos inmutables. Si el laboratorio realiza una compilación independiente o presenciada, registre el método y explique cómo se compara el objeto resultante con el candidato proporcionado.
Los requisitos de GLI solicitan código completo, archivos compilados, documentación arquitectónica, firmas de software y herramientas necesarias para las pruebas. También indican que el código debe ser completo y compilable, y que el objeto compilado debe ser idéntico o verificablemente equivalente desde el punto de vista funcional al medio enviado mediante un método acordado.
La guía de seguridad para proveedores de juegos de casino explica las evidencias adyacentes de SBOM y procedencia. La preparación para certificación usa esos controles para responder una pregunta más estrecha: ¿qué componentes y build exactos evaluó el laboratorio? Un SBOM apoya la respuesta, pero no sustituye la revisión de código, las pruebas del juego ni el proceso de aprobación del mercado objetivo.
Haga que matemáticas, reglas y arte describan el mismo juego
Las matemáticas, reglas para el jugador y arte deben usar un vocabulario controlado y señalar la misma tabla de pagos y configuración de funciones. El laboratorio no debería tener que inferir si el nombre de un símbolo, tabla de premios o condición de bonus de un archivo coincide con una etiqueta distinta en el cliente.
Envíe el modelo matemático aplicable, cálculos de retorno teórico, mapeo de entradas aleatorias, tablas de premios, lógica de funciones, instrucciones de emulación y métodos para resultados raros junto con las reglas visibles y todo arte que contenga reglas o información de pagos. Vincule cada regla material con su definición matemática, comportamiento en runtime y prueba esperada.
Los requisitos de GLI para envíos de juegos solicitan arte legible, descripciones completas, combinaciones ganadoras, pagos, esquemas de apuestas, detalles de bonus e instrucciones de emulación según el tipo de juego. El mismo documento indica que pueden requerirse traducciones independientes del arte. Son entradas para un envío a GLI, no un sustituto de las reglas de contenido e idioma del mercado objetivo.
Use la guía del modelo matemático para estructurar el PAR y las evidencias de prueba, y la guía de especificación de reglas para mantener la información al jugador alineada con código y matemáticas. El índice debe referenciar esas fuentes controladas en lugar de copiar valores en un resumen separado que pueda divergir.
Reproduzca la configuración operativa prevista
La configuración de pruebas debe reproducir cada elección de producción que pueda cambiar el comportamiento o la equidad del juego. Probar un paquete flexible sin la tabla de pagos, RNG, plataforma, canal y funciones reales del operador puede dejar el producto evaluado distinto del previsto para los jugadores.
GLI-19, versión 3.0 indica que debe comunicarse al laboratorio independiente la configuración de producción para crear un entorno de pruebas funcionalmente equivalente. El procedimiento británico también espera que las pruebas se realicen con el software y entorno previstos para operación, con pruebas de integración cuando las diferencias puedan afectar la equidad.
Cree un manifiesto de configuración con los ID de juego y tabla de pagos, versiones de RNG y RGS, canales y dispositivos compatibles, perfil de moneda y denominaciones, interruptores de funciones, paquete de localización, endpoints de servicios, fuente horaria, controles de seguridad y cuentas necesarias. Sustituya los secretos por un mecanismo seguro acordado con el laboratorio. Nunca incluya credenciales en el índice ordinario.
Documente las diferencias deliberadas entre pruebas y producción junto con su motivo y consecuencia. Puede ser necesario un stub, modo acelerado o herramienta de emulación de resultados, pero el paquete debe explicar su relación con la lógica de producción y lo que no puede probar.
Separe un envío nuevo de una modificación
Un envío de modificación debe identificar la versión evaluada anteriormente, el cambio exacto y las evidencias que siguen siendo válidas. Reenviar todos los archivos históricos sin un límite de cambio ralentiza la revisión y puede ocultar qué supuestos necesitan nuevas pruebas.
Los requisitos de GLI distinguen prototipos iniciales de modificaciones. Para cambios de software solicitan la versión anterior, una descripción comprensible con escenarios de prueba, módulos afectados y código nuevo, y permiten referenciar documentos sin cambios. El procedimiento británico usa otro marco: los cambios que afectan la equidad requieren nuevas pruebas externas, mientras todas las actualizaciones siguen sujetas a registros y responsabilidades de control de cambios.
No convierta ninguno de los marcos en una etiqueta universal de cambio mayor o menor. Cree una matriz de impacto según el mercado y vía de laboratorio reales. Para cada cambio, evalúe matemáticas y equidad, uso del RNG, reglas y arte, estado del juego, presentación al jugador, canal, integración de plataforma, seguridad, diseño responsable, localización y referencias a informes anteriores. Registre quién aceptó la clasificación y qué regresión corresponde.
Resuelva consultas del laboratorio sin desviar versiones
Las preguntas del laboratorio deben actualizar un registro controlado de consultas antes de actualizar cualquier archivo enviado. Un adjunto reemplazado con rapidez puede crear en silencio un paquete con dos versiones distintas de la misma evidencia.
Registre la pregunta, fecha, elemento afectado, responsable, interpretación, respuesta, versión revisada, nuevo resumen e impacto en el alcance o pruebas anteriores. Si la respuesta cambia el comportamiento, deje de tratarla como aclaración documental. Cree un nuevo candidato o límite de modificación aprobado y permita que el laboratorio decida qué pruebas deben repetirse.
Separe las consultas en evidencia ausente, evidencia ambigua, defecto de producto, problema de entorno y decisión de alcance. Esa clasificación permite corregir la causa sin presentar cada consulta como una certificación fallida ni tratar un cambio real como limpieza administrativa.
Convierta el resultado del laboratorio en aceptación del release
El informe final debe reconciliarse con el candidato exacto, el alcance y las condiciones sin resolver antes de que un operador acepte el juego. Un título de informe, carta de aprobación o resumen satisfactorio no bastan cuando su build o configuración difieren del paquete previsto para lanzamiento.
Compruebe las versiones probadas, resúmenes, normas, jurisdicción, autoridad del laboratorio, configuración, entorno, exclusiones, observaciones abiertas y referencias a informes anteriores contra el índice. Confirme que el candidato de release es el probado o que siguió la vía aprobada de cambio. Conserve el informe y el índice junto con la autorización de despliegue y sus evidencias.
El paquete no garantiza certificación, no sustituye a un regulador o laboratorio y no demuestra que el juego sea apto para todos los mercados. Proporciona al estudio y al comprador un registro inspeccionable de qué se envió, qué se probó, qué preguntas cambiaron el paquete y si el release previsto aún coincide con la evaluación.
Para equipos que encargan un nuevo juego de casino, el desarrollo de juegos de Wizards puede convertir requisitos del mercado objetivo, activos del juego y criterios de aceptación en una build controlada y un paquete preparado para el laboratorio.
Preguntas frecuentes
¿Qué incluye un envío para certificar un juego de casino?
Debe incluir el alcance acordado, código y binarios exactos, identidad de build, matemáticas, reglas, arte visible, configuración, entorno, utilidades de prueba, cambios, referencias a informes anteriores y excepciones requeridas por el mercado y laboratorio.
¿Quién decide el alcance de pruebas de un juego de casino?
La autoridad aplicable, el licenciatario responsable y el laboratorio autorizado determinan la vía y el alcance requeridos. Una lista del proveedor puede organizar las evidencias, pero no establecer requisitos universales.
¿Cómo demuestra un estudio qué build fue probada?
Debe vincular la revisión del repositorio, entorno de build, estado de dependencias, binarios, firmas o resúmenes y evidencias con un candidato inmutable, usando una compilación independiente o presenciada cuando el proceso acordado la exija.
¿Puede reutilizarse un informe anterior de pruebas?
Puede referenciarse cuando la autoridad y el laboratorio acepten su relevancia y el producto, las normas y la configuración afectados sigan siendo aplicables. Los cambios deben clasificarse para el mercado objetivo antes de reutilizar evidencias.
¿Qué ocurre si una consulta del laboratorio cambia el juego?
El equipo debe crear una nueva build controlada o un límite de modificación, actualizar el índice y permitir que el laboratorio determine el alcance de nuevas pruebas. No debe reemplazar un archivo en silencio dentro del paquete original.
¿Un informe de laboratorio garantiza aprobación en todos los mercados?
No. Cada jurisdicción define requisitos propios, puede autorizar laboratorios distintos y exigir presentaciones, pruebas o controles adicionales. El informe solo aplica a su alcance, normas, configuración e identidad de release declarados.
