El go-live no es la meta; es la puerta a la vida real. La fase de User Acceptance Testing nos ayuda a ver si lo que construimos sirve para operar de verdad: aparecen fallos que el tester no detectó y deseos que nunca se pidieron.
UAT es cliente al volante: escenarios reales y criterio propio, no el checklist de nuestros test cases re ejecutados. Si repiten nuestros pasos, verifican; si usan su contexto, validan.
Verificar no es lo mismo que validar
Cuando nosotros, como equipo, hacemos pruebas internas, lo que buscamos es verificar que la solución cumple el documento funcional.
Eso está bien, pero es solo la mitad del camino.
La validación (UAT) debería ser otra cosa: el cliente comprobando que lo entregado tiene sentido en su día a día.
Y ahí es donde aparecen esos defectos detectados por negocio: cosas que obviamos en nuestros test executions y que se detectan gracias a esa perspectiva de usuario final.
El atajo peligroso: darles nuestros test cases
Aquí es donde solemos caer en la trampa. Bajo presión de plazos o facturación, en vez de ayudar al cliente a validar, le pasamos nuestro export de pruebas internas.
El cliente las ejecuta, marca “ok” y firmamos el UAT. Todos contentos… hasta que llega producción.
El problema es que así lo único que se ha hecho es duplicar la verificación. El cliente no validó su negocio, solo repitió lo que ya habíamos probado nosotros. Y cuando descubra que no le encaja en su realidad, será demasiado tarde.
Cuando UAT se convierte en un arma de doble filo
El valor real de un UAT
Un UAT bien planteado no es repetir lo que ya probamos nosotros, sino poner al cliente en el asiento del conductor.
Ahí emergen dos tipos de hallazgos y conviene no mezclarlos:
- Defectos detectados desde el punto de vista de negocio: fallos que no hemos detectado, porque no hemos diseñado los test cases pensando como una persona que tiene que ir a la oficina el lunes.
- Gaps o nuevas necesidades: necesidades que no estaban en el alcance y afloran al utilizarlo "como un lunes cualquiera". No son incumplimientos, son cambios.
Práctica en proyectos reales
El UAT casi nunca es 100% validación.
Siempre hay una segunda capa de verificación, porque al usar el sistema en escenarios reales salen pequeños defectos que nadie vio antes (traducciones, permisos, configuraciones, datos).
Esto no invalida el UAT, pero sí genera esa “zona gris” en la que el usuario mezcla feedback del cliente con defectos descubiertos desde su perspectiva de negocio.
La clave es gestionar esa frontera con un semáforo claro:
-
Lo que es defecto → lo arreglamos, da igual dónde aparezca.
-
Lo que es gap de negocio → se gestiona como cambio (no es incumplimiento) y una nueva oportunidad de facturación.
-
Lo que es validación real → se documenta como aceptación.
Moraleja
👉 Verificar es confirmar que construimos el sistema correctamente.
👉 Validar es confirmar que construimos el sistema correcto.
Si confundimos ambas cosas, perdemos la esencia del UAT. Hoy cerramos un hito, pero mañana generaremos un incendio.
Un proyecto sostenible no se firma con un Excel lleno de checks en verde, sino con un cliente que, tras probar de verdad, puede decir: “esto funciona para mi negocio”.