La respuesta breve
«El juego se abre en el entorno de pruebas» demuestra que una ruta sin incidencias funcionó una vez en un entorno de prueba. Antes de producción, el equipo también debe demostrar que el candidato y el alcance están congelados, que se han probado las rutas funcionales y de excepción, que los registros financieros y operativos se concilian, que la configuración de producción y los límites de acceso están controlados, que la responsabilidad ante incidentes es ejecutable y que la reversión o interrupción puede realizarse con seguridad.
La aceptación debe producir evidencia y una decisión, no simplemente la frase «probado». Para cada elemento, registre el entorno, la versión candidata, el caso de prueba, el resultado real, la ubicación de la evidencia, el responsable y el nivel de bloqueo. Un elemento sin evidencia sigue estando sin verificar; una confirmación verbal en una reunión no lo convierte en aprobado.
Siete áreas de evidencia antes de producción
| Área | Evidencia mínima para aprobar | Qué debe bloquear producción |
|---|---|---|
| 1. Alcance y candidato | API acordadas, modelo de monedero, alcance de juegos, versión candidata, lista de configuración y exclusiones | El candidato aún cambia o el alcance probado difiere del alcance de lanzamiento |
| 2. Rutas funcionales | Resultados revisables para los casos acordados de inicio, retorno, monedero y consulta de registros | Falla una ruta comercial crítica o solo se verificó la visualización del front-end |
| 3. Rutas de excepción | Conclusiones para casos de tiempo de espera, duplicado, desconexión, fallo comercial, éxito parcial y estado desconocido | No puede establecerse el estado final y la recuperación depende de reintentos a ciegas |
| 4. Conciliación y consistencia | Identificadores estables relacionan solicitudes, transacciones, rondas, importes, monedas y movimientos de saldo | No se pueden vincular los registros o las discrepancias carecen de ruta de consulta, tratamiento y cierre |
| 5. Seguridad y aislamiento de entornos | Se verifican los límites de credenciales, acceso, datos, registros y configuración entre pruebas y producción | Se reutilizan credenciales de prueba, los secretos llegan al código o registros, o los permisos de producción no están claros |
| 6. Responsabilidad y preparación operativa | Se confirman el decisor de lanzamiento y los responsables de respuesta de ingeniería, conciliación, seguridad y escalado | Solo existe un contacto comercial o los incidentes y discrepancias financieras no tienen responsable |
| 7. Reversión, interrupción y recuperación | Se confirman los desencadenantes, ejecutor, tratamiento de datos, validación de recuperación y rutas de comunicación | No puede detenerse la integración con seguridad o nadie concilia el estado después de la reversión |
Paso 0: congelar el alcance y el formato de evidencia
Antes de las pruebas, establezca esta base:
- candidato de lanzamiento, versión de la documentación de API y versión de configuración;
- proveedores, juegos, modelo de monedero, monedas, idiomas y mercados previstos para el lanzamiento;
- exclusiones explícitas de este lanzamiento;
- diferencias entre el entorno de pruebas y producción;
- precondiciones, entradas, resultados comerciales esperados, resultados reales y ubicación de evidencia de cada caso;
- gravedad del defecto, aprobador de excepciones y responsable de la decisión final de avanzar o no avanzar.
Si el candidato de lanzamiento no es la versión que se probó, reevalúe las áreas de aceptación afectadas. No traslade conclusiones sin una revisión de impacto.
1. Aceptación funcional
Cubra la cadena comercial completa acordada, no una sola pantalla de juego:
- el catálogo o juego objetivo se identifica mediante el ID estable acordado;
- la creación de sesión, entrada, retorno y caducidad se comportan según lo acordado;
- el modelo de monedero seleccionado completa la ruta sin incidencias esperada;
- los resultados comerciales se evalúan según el protocolo de interfaz, no se infieren solo del estado HTTP;
- se pueden consultar los registros de transacción, ronda y relacionados, y vincularlos a las acciones de prueba;
- permisos, monedas, idiomas y dispositivos se prueban únicamente para las combinaciones de la base congelada.
Escriba las condiciones de aprobación como resultados observables; por ejemplo: «la transacción de prueba se devuelve mediante el ID comercial especificado y coincide con el movimiento del libro mayor», en vez de «el monedero funciona».
2. Aceptación de excepciones
Elija los casos de excepción según el riesgo del proyecto y el protocolo real. Habitualmente incluyen:
- tiempo de espera de solicitud, respuesta perdida o conexión interrumpida;
- envío duplicado o devolución de llamada duplicada;
- fallo de parámetro, permiso, firma o validación comercial;
- éxito parcial posterior cuando el llamante no dispone de un estado completo;
- consulta, compensación, conciliación de registros o escalado manual tras la recuperación del servicio;
- detener la acción automatizada después del límite de reintentos acordado, conservando la evidencia.
Esta lista de comprobación exige un resultado probado para las rutas de excepción. No inventa una clave de idempotencia, un número de reintentos ni un valor de espera progresiva para un proyecto. Consulte idempotencia, reintentos y conciliación de una API de Slots para el marco de diseño y use el protocolo formal de las partes para los detalles de implementación.
3. Aceptación de registros y conciliación
Utilice al menos una transacción normal y un escenario de excepción o estado desconocido. Compruebe si:
- se pueden correlacionar los identificadores de solicitud, transacción comercial, ronda y apuesta;
- el importe, moneda, dirección, estado final e interpretación de hora coinciden;
- el saldo del monedero o el movimiento del libro mayor coincide con el registro de transacción;
- los eventos duplicados se reconocen en lugar de crear dos resultados indistinguibles;
- toda discrepancia tiene un responsable, registro de tratamiento, condición de cierre y evidencia de auditoría;
- el alcance de consulta o exportación admite la revisión operativa y financiera acordada.
Una muestra aprobada demuestra únicamente los casos y el alcance cubiertos. No significa que las discrepancias futuras sean imposibles.
4. Seguridad, configuración y aislamiento de entornos
Producción no es la configuración del entorno de pruebas copiada a otro host. Antes del lanzamiento, verifique como mínimo que:
- prueba y producción usan credenciales, permisos y configuración independientes y controlados;
- los secretos no llegan al código fuente, capturas de pantalla, cuerpos de tickets ni registros ordinarios de la aplicación;
- el acceso a producción sigue el principio de mínimo privilegio y tiene registros de aprobación, cambio y revocación;
- los registros conservan contexto suficiente para el rastreo sin registrar secretos de firma, credenciales completas ni datos sensibles innecesarios;
- los datos de prueba no pueden confundirse con transacciones de producción y los datos de producción no entran en pruebas sin aprobación;
- se han revisado las diferencias de configuración, y los dominios de producción, reglas de red y objetivos de monitorización han superado comprobaciones reales del proyecto;
- las dependencias, relojes, certificados y ajustes relacionados con la firma tienen responsables designados.
Las normas técnicas de la Comisión de Juego del Reino Unido incluyen la separación de sistemas de desarrollo, prueba y producción dentro de su alcance de seguridad aplicable. Es una referencia útil de aislamiento de entornos, pero cada mercado y proyecto sigue requiriendo su propia revisión. No establece cumplimiento normativo o de seguridad completo.
5. Responsabilidad y preparación operativa
Convierta una lista de contactos en una matriz de responsabilidades ejecutable:
| Escenario | Responsabilidad que debe establecerse antes del lanzamiento |
|---|---|
| Incidente de API o sesión | Primer respondedor, requisito de evidencia, escalado de ingeniería y comunicación externa |
| Discrepancia financiera o de registros | Condición de pausa, responsable de conciliación, decisor comercial y estándar de cierre |
| Cambio de catálogo o versión | Iniciador del cambio, evaluación de impacto, notificación y pruebas de regresión |
| Incidente de credenciales o seguridad | Aislamiento, rotación, investigación, notificación y aprobación de recuperación |
| Lanzamiento y reversión | Decisión de avanzar o no avanzar, ejecución, validación y titularidad del registro final |
Si los objetivos de respuesta, disponibilidad del servicio o remedios son condiciones de lanzamiento, inclúyalos en el contrato u otro documento operativo formalmente acordado.
6. Reversión, interrupción y recuperación
No toda integración de API puede revertirse con una reversión de código. Cuando intervienen monederos y transacciones, el plan también debe cubrir los eventos comerciales creados durante la ventana de lanzamiento o reversión. Confirme:
- las condiciones explícitas que desencadenan la interrupción o reversión;
- qué puntos de entrada pueden cerrarse y qué eventos en curso todavía deben tratarse;
- quién ejecuta, aprueba y verifica la reversión;
- cómo se comprueban el servicio, los registros y el estado financiero después de recuperar configuración o versión;
- si los datos de producción deben conservarse, compensarse o conciliarse manualmente;
- una ruta controlada de degradación, pausa y comunicación cuando no es posible una reversión rápida.
Ejercite el plan en un entorno seguro o realice una simulación de mesa y conserve el resultado. Este artículo no presupone que AG proporcione una herramienta de reversión concreta.
El registro final de avanzar o no avanzar
Antes de producción, capture un registro de decisión conciso:
- versión candidata y configuración;
- estado de las siete áreas de evidencia: verificado, aceptado condicionalmente o bloqueado;
- defectos y excepciones sin resolver, incluidos riesgo, responsable y aprobador;
- responsabilidades de monitorización, escalado, interrupción y recuperación;
- aprobación independiente para acceso a producción y alcance comercial;
- decisión: avanzar, avanzar con alcance limitado o no avanzar;
- fecha de decisión y roles firmantes, sin presuponer una fecha fija de lanzamiento.
Qué puede evaluarse actualmente en este sitio
- El proceso de integración separa descubrimiento, alcance técnico, aceptación del entorno de pruebas a producción y coordinación previa a producción.
- La referencia pública de API muestra códigos de resultado comercial, identificadores de solicitud o transacción, dos direcciones de monedero y consultas de registros que pueden orientar el diseño de pruebas.
- Que un juego se abra cubre solo una ruta visible; no demuestra que el monedero, las excepciones, los registros o los permisos hayan superado la aceptación de extremo a extremo.
- El comportamiento real en ejecución y la admisión en producción deben basarse en evidencia de pruebas del entorno acordado y una decisión firmada por ambas partes.
Límites que deben tenerse presentes
- Esta página no afirma que AG haya proporcionado credenciales de entorno de pruebas o producción a un proyecto concreto.
- No fija un periodo de pruebas, fecha de lanzamiento, configuración de reintentos, nivel de rendimiento, capacidad ni SLA.
- Superar el entorno de pruebas no garantiza un comportamiento idéntico en producción.
- No establece que un juego, una versión o un modelo de monedero sea adecuado para todas las plataformas o mercados.
- No declara seguridad absoluta ni sustituye contrato, cumplimiento, seguridad y aprobación de cambios de producción.
Preguntas frecuentes
Si el entorno de pruebas aprueba, ¿el equipo puede lanzar de inmediato?
No automáticamente. Aún se deben revisar la identidad del candidato, las diferencias de entorno, el acceso a producción, la responsabilidad, la monitorización, el alcance comercial y las condiciones de reversión, y después tomar la decisión acordada de avanzar o no avanzar.
¿Bastan las pruebas de la ruta sin incidencias?
No. Los tiempos de espera, duplicados, desconexiones, fallos comerciales y estados desconocidos son fuentes comunes de procesamiento repetido y discrepancias financieras. Los casos de excepción deben entrar en aceptación de acuerdo con el protocolo y el riesgo.
¿Quién firma la decisión de producción?
La matriz de responsabilidades del proyecto lo determina. Ingeniería, QA, operaciones o finanzas, seguridad y el rol con autoridad para decidir producción firman normalmente sus propias áreas. La confirmación comercial no sustituye la aprobación técnica ni de producción.
¿Debe cada proyecto usar exactamente los mismos casos de prueba?
Las siete áreas de evidencia son un esqueleto común. Los casos concretos deben adaptarse al modelo de monedero, alcance, mercado objetivo, plataforma actual y riesgo de cambio. La decisión de adaptación debe documentarse y aprobarse.
Lecturas relacionadas y próximos pasos
- Páginas principales: proceso de integración, API de Slots y referencia pública de API
- Guías existentes: lista de comprobación de integración de API de Slots y monedero único frente a monedero de transferencia
- Continúe con cómo evaluar un proveedor de API de Slots e idempotencia, reintentos y conciliación
Para definir un alcance de aceptación de proyecto, utilice la sección «Contáctenos» para proporcionar el modelo de monedero, los juegos objetivo, el límite actual de plataforma y los entornos previstos. AG podrá entonces colaborar en casos y evidencia frente al protocolo confirmado, sin prometer por adelantado una fecha de lanzamiento ni admisión en producción.
Fuentes y alcance
Para el alcance de producto, consulte el proceso de integración, la visión general de la API de Slots y la referencia pública de API.
Los métodos generales de lanzamiento se fundamentan en ingeniería de lanzamientos y prácticas de evolución de la participación de SRE del SRE de Google. El ejemplo específico de mercado sobre aislamiento de entornos procede de los requisitos de seguridad de las Normas Técnicas de Juego Remoto y Software de la Comisión de Juego del Reino Unido.
Estas fuentes explican prácticas generales de aceptación. No establecen que AG implemente cada proceso citado ni que un proyecto cumpla con un mercado determinado. Las condiciones de producción deben acordarse entre los roles responsables de ingeniería, QA, operaciones o finanzas, seguridad, comercial y cumplimiento.
¿Quiere convertir esta guía en un plan de proyecto?
Esta guía apoya la evaluación y no sustituye la validación técnica, contractual, de certificación ni de requisitos locales.