Checklist UAT y aceptación de puesta en producción de lotería
UAT de una plataforma de lotería debe demostrar que la versión acordada gestiona recorridos de negocio y sus fallos, no simplemente que carga pantallas. Utiliza una matriz que relacione cada requisito con datos ficticios, resultado esperado, evidencias y aprobador responsable. La puesta en producción requiere una decisión operativa separada basada en esos resultados y las […]
UAT de una plataforma de lotería debe demostrar que la versión acordada gestiona recorridos de negocio y sus fallos, no simplemente que carga pantallas. Utiliza una matriz que relacione cada requisito con datos ficticios, resultado esperado, evidencias y aprobador responsable. La puesta en producción requiere una decisión operativa separada basada en esos resultados y las dependencias restantes.
Este checklist cubre aceptación técnica. La guía general de preparación del lanzamiento aborda personal, contrapartes, alcance y traspaso operativo. Ninguno autoriza pagos reales, cambios de datos de producción ni eludir controles obligatorios.
Fija la base de aceptación
Registra versión, configuración, productos, canales, idiomas y contratos de interfaces probados. Distingue funciones disponibles de desarrollos previstos. Cada prueba necesita requisitos previos, estado inicial, datos ficticios permitidos, pasos, resultado de negocio esperado y referencias de evidencia.
Redacta criterios medibles, no «funciona como se espera». Por ejemplo: repetir una compra aceptada no crea otro boleto ni apunte; una cuenta de otra marca no accede al registro; corregir un resultado deja un ajuste auditable. Define el comportamiento según el contrato real, no un endpoint supuesto de WhiteLotto.
Prueba recorridos completos y fallos controlados
| Recorrido | Casos a cubrir | Evidencia |
|---|---|---|
| Cuenta y verificación | Aprobación, rechazo, nueva presentación, revisión manual y cambio de decisión. | Resultado del proveedor, permisos e historial. |
| Ingresos y retiradas | Éxito, rechazo, pendiente, webhook retrasado, reembolso y respuesta incierta. | Referencia del proveedor, efecto contable único y conciliación. |
| Compra del boleto | Pedido válido, selección inválida, cierre, solicitud duplicada y confirmación perdida. | Identidad del boleto, sorteo y estado financiero final. |
| Resultados y liquidación | Resultados ausentes, preliminares, definitivos y corregidos. | Resultado versionado, trazabilidad y excepciones con responsable. |
| Canal físico | Pérdida de red, fallo de impresora, reinicio y reimpresión. | Registros POS y centrales sin emisión duplicada. |
| Acceso y controles | Rol no autorizado, recurso de otra marca, cliente/dispositivo revocado y restricciones configuradas. | Acciones denegadas y errores seguros. |
| Operación | Interrupción del proveedor, recuperación, investigación y exportación financiera. | Alerta operativa, responsable y evidencias utilizables. |
Utiliza las guías de pagos, KYC e interfaces de sorteos y resultados para especificar casos. La guía OWASP de pruebas de lógica de negocio ayuda a plantear abusos y temporización; un checklist no demuestra que una versión los haya superado.
Comprueba los registros finales, no solo la pantalla
El mensaje del navegador puede parecer correcto mientras existe un apunte duplicado en el monedero. Registra referencias relevantes de boleto, proveedor y contabilidad con datos de prueba permitidos. Comprueba comunicación al cliente, acceso del personal e informes financieros dentro del mismo recorrido.
Prueba cada idioma soportado y las combinaciones significativas de dispositivo y canal. Un menú traducido no demuestra que errores KYC, recibos, horas de sorteos o mensajes de soporte sean comprensibles. Documenta la cobertura e identifica expresamente las variaciones no probadas.
Distingue bloqueos y tareas posteriores aceptadas
Acuerda severidad y autoridad de decisión antes de ejecutar. Los defectos que afectan fondos, boletos válidos, aislamiento de acceso, controles requeridos o recuperación fiable no deben llamarse cosméticos porque se acerque una campaña. Tras corregir, vuelve a probar el recorrido afectado; no repitas automáticamente comprobaciones ajenas sin motivo.
Para un elemento no bloqueante registra impacto, medida compensatoria, responsable, aceptación autorizada y fecha límite. Un PASS sin resultado no es aprobación. Superar un caso de laboratorio no garantiza disponibilidad futura ni rendimiento comercial.
Define por separado pausa, rollback y recuperación de datos
Puede ser seguro restaurar software anterior, pero compras, apuntes y migraciones de base de datos no se revierten automáticamente. Especifica condiciones de pausa, autoridad, versión recuperable y conservación y conciliación de operaciones pendientes.
La guía NIST de contingencia es una referencia para planificar y validar recuperación. Utilízala como contexto, no como certificación de la plataforma ni prueba de que se haya ensayado una restauración concreta.
Completa el paquete de decisión y traspaso
- Versión y configuración exactas probadas y alcance aceptado.
- Matriz completada, evidencias y registro de defectos pendientes.
- Dependencias externas, condiciones obligatorias y riesgos residuales autorizados.
- Responsables de monitorización, contactos de guardia y mensajes al cliente.
- Autoridad de pausa, rollback seguro y responsabilidades sobre datos.
- Acceso de soporte y finanzas, procedimientos y revisión posterior.
Incluye la matriz en la evaluación de proveedores antes de firmar el alcance. Acordar aceptación tarde puede generar trabajo de integración no presupuestado.
Preguntas frecuentes sobre UAT de lotería
¿Una demo del proveedor es UAT?
No. La demo muestra funciones seleccionadas; la aceptación prueba configuración acordada, resultados y fallos con evidencia registrada.
¿Un rollback correcto elimina transacciones?
No. Recuperar código y recuperar transacciones o datos son procedimientos diferentes. Conserva y concilia los registros reales mediante un plan autorizado.
Comparte prioridades de aceptación y dependencias de entrega con WhiteLotto. CONTACTO.