Que Es el Testing de Aceptacion de Usuario?
El Testing de Aceptacion de Usuario (UAT) es el ultimo nivel de testing antes de que el software se libere a produccion. Responde una pregunta fundamentalmente diferente a todos los demas niveles. Mientras que unit, integracion, sistema y E2E preguntan “El software funciona correctamente?”, el UAT pregunta “El software hace lo que el negocio realmente necesita?”
Esta distincion es critica. Un sistema puede pasar cada test tecnico y aun asi fallar en UAT porque no resuelve el problema que el negocio pretendia resolver.
Considera una empresa que solicita un generador de reportes. El equipo de desarrollo lo construye perfectamente segun la especificacion: extrae datos, aplica filtros y genera PDFs. Todos los tests pasan. Pero durante UAT, la gerente de finanzas dice: “Necesito exportar a Excel, no PDF. Y necesito los datos agrupados por trimestre, no por mes.” El sistema funciona correctamente pero no cumple la necesidad real del negocio.
El UAT detecta estos desalineamientos entre lo construido y lo necesitado.
Quien Realiza el UAT?
El UAT lo realizan usuarios de negocio — las personas que realmente usaran el software:
- Product owners que definieron los requisitos
- Analistas de negocio que tradujeron necesidades en especificaciones
- Usuarios finales o representantes que trabajaran con el sistema diariamente
- Expertos de dominio que entienden las reglas de negocio
- Oficiales de cumplimiento en industrias reguladas
Los ingenieros QA no realizan UAT. QA valida que el sistema funciona correctamente (verificacion). Los usuarios de negocio validan que el sistema hace lo correcto (validacion).
Tipos de Testing de Aceptacion
Testing Alfa
Realizado internamente por personas de la organizacion, pero no el equipo de desarrollo.
Quien: Empleados internos, stakeholders, analistas de negocio Donde: Ambiente de prueba interno (no produccion) Cuando: Antes del testing beta, despues del testing de sistema Objetivo: Detectar problemas mayores antes de exponer el software a usuarios externos
Testing Beta
Realizado externamente por usuarios reales en condiciones reales. El software se libera a una audiencia limitada para recopilar feedback.
Quien: Usuarios externos, early adopters, clientes seleccionados Donde: Ambientes reales (dispositivos y redes propias de los usuarios) Cuando: Despues del testing alfa, antes de la disponibilidad general Objetivo: Descubrir problemas que solo aparecen en condiciones reales diversas
Testing de Aceptacion Contractual
Verifica que el software cumple las obligaciones contractuales definidas en un acuerdo formal entre el cliente y el proveedor.
Quien: Representantes del cliente y proveedor Que: Testing contra criterios contractuales especificos Cuando: Antes del pago/firma de aceptacion Objetivo: Verificacion legal de que todos los requisitos contratados se cumplieron
Testing de Aceptacion Regulatorio
Verifica que el software cumple con regulaciones de la industria, requisitos legales y estandares.
Quien: Oficiales de cumplimiento, auditores, entes reguladores Que: Testing contra regulaciones especificas (HIPAA, GDPR, SOX, PCI-DSS) Cuando: Antes del despliegue en ambientes regulados Objetivo: Asegurar cumplimiento legal y regulatorio
Planificacion del UAT
1. Definir Alcance
Que se probara? Que features, flujos y procesos de negocio?
2. Escribir Criterios de Aceptacion
Cada requisito debe tener criterios claros y medibles:
- Especifico: “El usuario puede generar un reporte de ingresos trimestral”
- Medible: “El reporte se genera en menos de 10 segundos”
- Testeable: Condiciones claras de aprobacion/fallo
3. Preparar Escenarios de Prueba
Los usuarios de negocio prueban con escenarios realistas:
- “Procesar una orden estandar desde cotizacion hasta factura”
- “Aplicar 15% de descuento a una orden mayorista sobre $10,000”
- “Generar reporte de conciliacion financiera de fin de mes”
4. Preparar el Ambiente
- Datos similares a produccion (anonimizados si es necesario)
- Todas las integraciones conectadas
- Cuentas de usuario con roles y permisos apropiados
5. Capacitar Participantes del UAT
Los usuarios de negocio no son testers profesionales. Necesitan:
- Instrucciones de como reportar problemas
- Entendimiento del alcance
- Acceso a soporte del equipo QA/dev
6. Definir Criterios de Aprobacion
Cuando se completa el UAT? Criterios comunes:
- Todos los escenarios criticos pasan
- No quedan defectos bloqueantes
- Stakeholders aprueban formalmente
- Evidencia documentada del testing
El Proceso de Aprobacion (Sign-Off)
Rol de QA en el UAT
QA no realiza UAT pero juega un rol de soporte crucial:
Antes del UAT: Asegurar que el sistema paso testing de sistema, ayudar a escribir escenarios UAT, configurar ambiente, crear datos de prueba.
Durante el UAT: Soporte tecnico a usuarios, ayudar a reproducir y documentar problemas, clasificar defectos reportados, rastrear progreso.
Despues del UAT: Coordinar correcciones, re-probar issues, compilar reporte de resultados, facilitar el proceso de aprobacion.
Ejercicio: Crea un Plan UAT con Criterios de Aceptacion
Eres QA Lead para un nuevo portal de autoservicio de RRHH. El portal permite:
- Ver y actualizar informacion personal
- Enviar solicitudes de tiempo libre (vacaciones, licencia medica, dias personales)
- Ver recibos de pago y documentos fiscales
- Inscribirse o cambiar beneficios
Crea un plan UAT que incluya:
- 3 escenarios para solicitudes de tiempo libre
- Criterios de aceptacion para cada escenario
- Quien debe ejecutar cada escenario
- Criterios de aprobacion del UAT completo
Pista
Piensa en el flujo de trabajo desde la perspectiva del empleado. Cuales son los happy paths? Que reglas deben aplicarse (saldo disponible, aprobacion del gerente, fechas bloqueadas)?Solucion
Escenario 1: Solicitud Estandar de Vacaciones
- Actor: Empleada regular (Sara, departamento de Marketing)
- Pasos: Login → Seccion “Tiempo Libre” → Nueva Solicitud → Seleccionar “Vacaciones” → Elegir fechas (5 dias) → Verificar saldo → Enviar
- Criterios de Aceptacion:
- Calculo de saldo preciso
- Notificacion al gerente dentro de 5 minutos
- Solicitud aparece como “Pendiente de Aprobacion”
- Vista de calendario muestra fechas como “Pendiente”
Escenario 2: Licencia Medica con Saldo Insuficiente
- Actor: Empleado con 2 dias de licencia restantes (Alex, Ingenieria)
- Pasos: Solicitar 3 dias de licencia medica
- Criterios de Aceptacion:
- Advertencia: “Solicitado: 3 dias, Disponible: 2 dias”
- Sistema permite envio pero marca “Excede Saldo”
- Notificacion al gerente incluye advertencia
- RRHH notificado automaticamente
Escenario 3: Flujo de Aprobacion del Gerente
- Actor: Gerente (Juan, Director de Marketing)
- Precondicion: Solicitud de Sara enviada
- Pasos: Login como gerente → Ver notificacion → Revisar solicitud → Ver calendario del equipo → Aprobar
- Criterios de Aceptacion:
- Gerente ve detalles completos (fechas, tipo, saldo)
- Calendario muestra conflictos si hay
- Aprobacion/Rechazo requiere seleccionar razon
- Empleada notificada dentro de 5 minutos
- Sistema de RRHH actualizado inmediatamente
Participantes UAT: 5-10 empleados, 3-5 gerentes, 1 admin RRHH, 1 especialista de nomina
Criterios de Aprobacion:
- Los 3 escenarios criticos pasan para todos los grupos
- Sin defectos bloqueantes
- Issues menores documentados con timeline de correccion
- Aprobacion formal del Director de RRHH
- Precision de nomina verificada en 10+ casos
Errores Comunes del UAT
Error 1: Usar UAT para encontrar bugs. Si los usuarios pasan el tiempo reportando crashes, el sistema no estaba listo para UAT.
Error 2: Sin criterios de aceptacion claros. Sin criterios medibles, el UAT se vuelve subjetivo.
Error 3: Participantes incorrectos. Que desarrolladores o QA realicen UAT anula su proposito.
Error 4: Ciclos UAT indefinidos. El UAT debe tener duracion definida y criterios de salida claros.
Tips Profesionales
Tip 1: Programa el UAT temprano. El UAT frecuentemente descubre malentendidos de requisitos que requieren retrabajo significativo. Presupuesta tiempo para al menos dos ciclos.
Tip 2: Proporciona datos realistas. Los usuarios no pueden validar logica de negocio con datos falsos. Usa datos de produccion anonimizados.
Tip 3: Documenta todo. La aprobacion del UAT es un evento formal de negocio. Mantiene registros de quien probo que, que paso, que fallo y quien aprobo.
Conclusiones Clave
- El UAT valida que el sistema cumple necesidades de negocio, no solo requisitos tecnicos
- Usuarios de negocio realizan UAT — no ingenieros QA ni desarrolladores
- Cuatro tipos: alfa (interno), beta (externo), contractual (legal), regulatorio (cumplimiento)
- Criterios de aceptacion claros con condiciones medibles son esenciales
- QA apoya UAT a traves de planificacion, configuracion de ambiente y coordinacion de defectos
- El proceso de aprobacion formaliza la autorizacion de negocio para liberar a produccion