Las pruebas UAT aparecen al final de muchos planes de trabajo, pero no deberían tratarse como una última revisión superficial. Su objetivo es confirmar, con personas que conocen el negocio, que el producto permite completar los procesos reales para los que fue construido.
En mi experiencia en calidad de software, una UAT útil no consiste en repetir todos los casos que ya ejecutó QA. Se concentra en las decisiones, reglas y recorridos que determinan si el producto puede usarse de forma segura y satisfactoria. En esta guía explico cómo prepararla, quién debe participar y qué evidencia conviene conservar antes de aprobar una salida a producción.
¿Qué son las pruebas UAT?
UAT significa User Acceptance Testing o pruebas de aceptación del usuario. Es la validación en la que representantes del negocio o usuarios autorizados comprueban que el sistema satisface las necesidades acordadas y permite completar los procesos principales.
La pregunta central de UAT no es solamente «¿la aplicación funciona?», sino «¿podemos utilizarla para cumplir el objetivo del negocio?». Un flujo puede responder correctamente desde el punto de vista técnico y, aun así, ser inaceptable si calcula mal una condición comercial, solicita información innecesaria o impide completar una tarea importante.
UAT, pruebas funcionales y pruebas de integración: diferencias
| Tipo de prueba | Pregunta principal | Participantes habituales |
|---|---|---|
| Prueba funcional | ¿La funcionalidad cumple el comportamiento especificado? | QA y equipo de desarrollo |
| Prueba de integración | ¿Los componentes y servicios intercambian información correctamente? | QA, desarrollo y equipos técnicos |
| UAT | ¿El producto permite ejecutar el proceso real y satisface la necesidad del negocio? | Usuarios autorizados, negocio, Product Owner y apoyo de QA |
Estas pruebas se complementan. La UAT no reemplaza las pruebas funcionales, de APIs, integración, seguridad o rendimiento. Debería comenzar cuando esas validaciones ya ofrecen un nivel razonable de confianza. Para profundizar en las capas técnicas, puedes revisar qué validar en una API REST además del código 200.
¿Quién debe participar?
- Representantes del negocio o usuarios clave: ejecutan los escenarios y confirman si el resultado es aceptable.
- Product Owner o responsable funcional: aclara reglas, prioridades y criterios de aceptación.
- QA: ayuda a definir escenarios, preparar datos, recopilar evidencias y gestionar los hallazgos sin sustituir la decisión del negocio.
- Desarrollo y soporte técnico: analizan defectos, atienden bloqueos y verifican correcciones.
- Responsable de la liberación: consolida riesgos y coordina la decisión final de salida.
Conviene definir estos roles antes de empezar. Cuando nadie sabe quién aprueba, quién registra los resultados o quién decide frente a un riesgo pendiente, la UAT puede terminar sin una conclusión verificable.
Qué debe estar listo antes de iniciar
- Alcance y funcionalidades que serán validadas.
- Criterios de aceptación claros y relacionados con necesidades del negocio.
- Entorno estable y suficientemente parecido al uso real.
- Versión identificada y sin cambios no controlados durante la ejecución.
- Datos de prueba representativos, anonimizados y sin información sensible real.
- Usuarios, permisos y accesos preparados.
- Escenarios priorizados según impacto y riesgo.
- Canal para registrar defectos, dudas y decisiones.
- Responsables y horario disponible para atender bloqueos.
- Criterios de entrada, salida y suspensión acordados.
Si faltan accesos, datos o estabilidad, es mejor corregirlo antes de convocar a los usuarios. Una sesión perdida por problemas de preparación reduce la confianza y puede dejar los flujos críticos sin validar.
Cómo ejecutar una UAT paso a paso
1. Definir el objetivo y el alcance
Empiezo por describir qué decisión debe permitir la UAT. Por ejemplo: confirmar que un usuario puede registrarse, completar una compra, recibir la confirmación y consultar el resultado. También dejo explícito qué no se probará para evitar expectativas diferentes entre los participantes.
2. Priorizar escenarios de negocio
No todos los casos tienen el mismo valor. Primero cubro los recorridos que afectan dinero, cumplimiento, información sensible, continuidad del servicio o una gran cantidad de usuarios. Después agrego alternativas relevantes y excepciones que el negocio necesita controlar.
3. Diseñar casos comprensibles
Un caso UAT debe hablar el lenguaje del usuario. Puede incluir objetivo, precondiciones, datos, pasos principales, resultado esperado y evidencia. Evito instrucciones excesivamente técnicas que conviertan al participante en un ejecutor mecánico y le impidan observar el proceso como lo haría en su trabajo.
4. Ejecutar y recopilar evidencia
Durante la ejecución registro el resultado, la fecha, la versión evaluada y la evidencia necesaria. Si aparece un problema, documento las condiciones para reproducirlo y su impacto. También separo los defectos de las solicitudes de cambio: ambos pueden ser importantes, pero requieren decisiones distintas.
5. Revisar hallazgos y decidir
Al finalizar reviso los resultados con negocio, producto y el equipo técnico. Un caso fallido no debería aprobarse solo porque existe una solución manual. Si se acepta un riesgo, conviene registrar quién lo acepta, por qué, durante cuánto tiempo y cuál será el seguimiento. Para organizar esta parte recomiendo complementar la UAT con una gestión de defectos clara y sin buscar culpables.
Ejemplo práctico de un caso UAT
Supongamos una aplicación que permite realizar una transferencia entre dos cuentas propias. El caso podría documentarse así:
| Objetivo | Confirmar que el usuario puede transferir un valor permitido y consultar la confirmación. |
|---|---|
| Precondiciones | Usuario activo, dos cuentas habilitadas y saldo suficiente. |
| Datos | Cuentas y valores ficticios preparados para el entorno de UAT. |
| Flujo principal | Seleccionar cuenta de origen y destino, ingresar el valor, revisar el resumen y confirmar. |
| Resultado esperado | La operación se procesa una sola vez, los saldos se actualizan y el comprobante muestra información coherente. |
| Evidencia | Identificador de la operación, capturas necesarias y resultado registrado en la herramienta acordada. |
Además del flujo exitoso, evaluaría valor superior al saldo, límites permitidos, cancelación antes de confirmar, reintento y prevención de una operación duplicada. El objetivo no es agotar todas las combinaciones técnicas, sino confirmar que los escenarios relevantes para el negocio son utilizables y confiables.
Criterios de salida y aprobación
- Todos los escenarios críticos fueron ejecutados.
- No existen defectos bloqueantes o críticos pendientes.
- Los defectos menores tienen responsable, fecha y riesgo aceptado.
- Los resultados y evidencias están disponibles para consulta.
- Los usuarios responsables confirmaron la aceptación.
- Existe una decisión documentada: aprobado, aprobado con condiciones o no aprobado.
La aprobación debe relacionarse con una versión concreta. Si después se incorpora un cambio importante, corresponde evaluar su impacto y decidir qué escenarios necesitan repetirse. Esta disciplina también forma parte de una estrategia de QA conectada con el riesgo.
Errores comunes que reducen el valor de la UAT
- Convocar usuarios sin explicar el objetivo ni el alcance.
- Usar producción o datos personales reales para facilitar la prueba.
- Repetir únicamente los casos funcionales preparados por QA.
- Probar solo el flujo exitoso y omitir condiciones de negocio importantes.
- Cambiar la versión del entorno durante la ejecución sin informar.
- Registrar resultados sin evidencia o sin identificar la versión.
- Confundir una solicitud nueva con un defecto del alcance aprobado.
- Dar por aprobada la salida sin una decisión explícita del responsable.
Checklist rápido para una UAT
- ☐ El alcance está definido.
- ☐ Los criterios de aceptación son verificables.
- ☐ Los participantes y responsables están confirmados.
- ☐ El entorno, versión, accesos y datos están listos.
- ☐ Los escenarios críticos están priorizados.
- ☐ Existe una herramienta para resultados y defectos.
- ☐ Los criterios de salida y suspensión están acordados.
- ☐ Los riesgos pendientes tienen responsable y decisión.
- ☐ La aprobación final queda documentada.
Preguntas frecuentes sobre UAT
¿QA debe ejecutar las pruebas UAT?
QA puede preparar escenarios, datos y evidencias, además de acompañar la ejecución. Sin embargo, la aceptación debería provenir de representantes autorizados del negocio o de los usuarios, porque son quienes pueden confirmar que el producto satisface la necesidad.
¿UAT reemplaza las pruebas funcionales?
No. UAT valida la aceptación del proceso de negocio; las pruebas funcionales e integración comprueban el comportamiento técnico y detallado. Omitirlas traslada problemas evitables a los usuarios de UAT.
¿Se puede automatizar una UAT?
Algunos recorridos repetitivos pueden automatizarse como apoyo a la regresión, pero la decisión de aceptación incluye contexto, reglas y criterio humano. Automatizar un flujo no sustituye la validación del negocio.
¿Cuánto debería durar?
Depende del alcance, el riesgo y la disponibilidad de los participantes. Prefiero estimarla por escenarios críticos, datos y ciclos de corrección, no por un número fijo de días. Una UAT pequeña y bien preparada puede aportar más confianza que una larga sin prioridades claras.
Conclusión
Una buena UAT conecta la calidad técnica con la realidad del negocio. Cuando el alcance, los datos, los responsables y los criterios de salida están claros, la aprobación deja de ser una formalidad y se convierte en una decisión basada en evidencia.
Si estás definiendo este proceso para un proyecto, puedes revisar también mis contenidos sobre QA en DevOps y CI/CD o contactarme desde el blog.