Pruebas de Aceptación de Usuario (UAT)
Marco de trabajo integral de UAT que cubre: generación de planes, ejecución, aprobación de interesados y puertas de lanzamiento go/no-go. UAT es la última puerta de calidad antes de producción: trátala como tal. Ninguna función se envía sin la aprobación explícita de los interesados contra los criterios de aceptación.
Preprocesamiento (Contexto Automático)
Antes de comenzar, recopila el contexto del proyecto en silencio:
- Lee
PORTFOLIO.mdsi existe en la raíz del proyecto o en directorios padre para contexto de producto/equipo - Ejecuta:
cat package.json 2>/dev/null || cat build.gradle.kts 2>/dev/null || cat Podfile 2>/dev/nullpara detectar la pila tecnológica - Ejecuta:
git log --oneline -5 2>/dev/nullpara cambios recientes - Ejecuta:
ls src/ app/ lib/ functions/ 2>/dev/nullpara entender la estructura del proyecto - Usa este contexto para adaptar toda la salida al proyecto real
Paso 1: Clasificar la Necesidad de UAT
Determina el tipo de UAT antes de construir el plan. El tipo dicta el alcance, la profundidad, la participación de los interesados y el cronograma.
| Tipo de UAT | Desencadenante | Alcance | Duración Típica |
|---|---|---|---|
| UAT de Nueva Función | Desarrollo de función completado, fusionado a staging | Todos los criterios de aceptación de PRD/historias, ruta feliz completa + casos extremos | 2-5 días hábiles |
| UAT de Regresión | Refactorización mayor, actualización de dependencia o migración de plataforma | Viajes de usuario críticos reverificados, sin regresiones de comportamiento | 1-3 días hábiles |
| UAT de Candidato a Lanzamiento | Rama de lanzamiento cortada, todas las funciones integradas | Alcance completo del lanzamiento: cada función, punto de integración y comportamiento multiplataforma | 3-5 días hábiles |
| Validación de Hotfix | Error de producción corregido, parche desplegado a staging | Alcance estrecho: verificar la corrección, confirmar que no hay efectos secundarios en flujos adyacentes | 2-4 horas |
Si el tipo de UAT no está claro, pregunta antes de continuar. Una validación de hotfix y una UAT de candidato a lanzamiento requieren planes fundamentalmente diferentes.
Recopilación Automatizada de Contexto
Antes de crear el plan de UAT:
- Busca especificaciones de prueba existentes, archivos PRD, documentos de criterios de aceptación
- Lee cualquier especificación encontrada para extraer requisitos comprobables
- Busca marcas de funciones (feature flags) que controlen las funciones bajo prueba
Generación de Artefactos (Requerido)
Genera usando Write:
- Plan de UAT:
docs/uat/uat-plan.md— usando el estilo de salida de plan de prueba - Casos de prueba:
docs/uat/test-cases.md— casos de prueba detallados con pasos y resultados esperados - Formulario de aprobación:
docs/uat/sign-off.md— plantilla de aprobación de interesados - Plantilla de triaje de errores:
docs/uat/bug-triage.md— guía de clasificación de gravedad
Paso 2: Recopilar Contexto
Recopila todas las entradas antes de escribir el plan de UAT. La falta de contexto produce planes incompletos.
| Entrada | Requerida | Fuente | Notas |
|---|---|---|---|
| Nombre de función/versión de lanzamiento | Sí | PM/Líder Técnico | Identificador corto para seguimiento |
| Criterios de aceptación | Sí | PRD, historias de usuario, tickets Jira/Linear | Usa la salida de la habilidad /sdlc si está disponible |
| Lista de interesados | Sí | PM/Product Owner | Quién prueba, quién aprueba, quién tiene poder de veto |
| Entorno objetivo | Sí | Ingeniería | URL de staging, número de compilación, marcas de funciones |
| Plataforma(s) | Sí | Ingeniería | Android, iOS, Web o combinación |
| Requisitos de cumplimiento | Opcional | Legal/Seguridad | Restricciones de HIPAA, SOC 2, PCI-DSS, GDPR sobre datos de prueba |
| Riesgos o limitaciones conocidos | Opcional | Ingeniería | Deuda técnica, problemas conocidos, integraciones incompletas |
| Resultados de UAT anteriores | Opcional | QA/PM | Línea base para comparación de regresión |
| Fecha límite de lanzamiento | Sí | PM | Fecha fija vs. flexible: impulsa la presión go/no-go |
Si no existen criterios de aceptación, detente y créalos primero usando la habilidad /sdlc. UAT sin criterios de aceptación son pruebas basadas en opiniones: no prueban nada.
Paso 3: Generación del Plan de UAT
3.1 Extracción de Criterios de Aceptación
Extrae los criterios de aceptación de cada fuente y normalízalos en declaraciones comprobables.
Formato: Dado [precondición], Cuando [acción], Entonces [resultado esperado]
Prioridad de fuente:
1. Criterios de aceptación de PRD (autoritativos)
2. Criterios de aceptación de historias de usuario (detallados)
3. Especificaciones de diseño / prototipos (comportamiento visual y de interacción)
4. Contratos de API (formas de respuesta, códigos de error)
5. Casos extremos identificados durante la revisión de código o /feature-audit
Cada criterio de aceptación se convierte en uno o más escenarios de prueba. Si un criterio no se puede probar manualmente, márcalo y especifica el método de verificación automatizada.
3.2 Matriz de Escenarios de Prueba
Construye la matriz completa de escenarios. Cada escenario tiene exactamente un resultado esperado.
| ID | Categoría | Escenario | Precondición | Pasos | Resultado Esperado | Plataforma | Prioridad |
|---|---|---|---|---|---|---|---|
| UAT-001 | Ruta Feliz | [Flujo de éxito primario] | [Estado de configuración] | [1. 2. 3.] | [Resultado esperado] | Todas | P0 |
| UAT-002 | Ruta Feliz | [Flujo de éxito secundario] | [Estado de configuración] | [1. 2. 3.] | [Resultado esperado] | Todas | P0 |
| UAT-003 | Caso Extremo | [Condición límite] | [Estado de configuración] | [1. 2. 3.] | [Resultado esperado] | Todas | P1 |
| UAT-004 | Estado de Error | [Entrada inválida / fallo] | [Estado de configuración] | [1. 2. 3.] | [Manejo de errores] | Todas | P1 |
| UAT-005 | Multiplataforma | [Comportamiento específico de plataforma] | [Estado de configuración] | [1. 2. 3.] | [Expectativa de plataforma] | Específica | P1 |
| UAT-006 | Accesibilidad | [Lector de pantalla / navegación por teclado] | [AT habilitado] | [1. 2. 3.] | [Resultado accesible] | Todas | P1 |
| UAT-007 | Rendimiento | [Tiempo de carga / capacidad de respuesta] | [Condiciones estándar] | [1. 2. 3.] | [Dentro del presupuesto] | Todas | P2 |
| UAT-008 | Sin conexión/Degradado | [Sin conectividad / señal débil] | [Modo avión / limitado] | [1. 2. 3.] | [Manejo elegante] | Móvil | P1 |
Definiciones de prioridad:
- P0 — Funcionalidad central. Si falla, la función no funciona. Bloquea el lanzamiento.
- P1 — Comportamiento importante. Si falla, la función funciona pero con brechas significativas. Debe corregirse antes del lanzamiento.
- P2 — Verificación agradable de tener. Si falla, se puede enviar con el problema conocido documentado.
3.3 Lista de Verificación del Entorno
Verifica el entorno de prueba antes de que comience la UAT. Un entorno roto pierde el tiempo de los interesados y erosiona la confianza.
LISTA DE VERIFICACIÓN PRE-UAT
[ ] Entorno de staging desplegado con la compilación/versión correcta
[ ] Versión de compilación documentada: _______________
[ ] Marcas de funciones habilitadas para el alcance de UAT:
[ ] Marca: _____________ = ACTIVADO/DESACTIVADO
[ ] Marca: _____________ = ACTIVADO/DESACTIVADO
[ ] Datos de prueba sembrados (cuentas, contenido, transacciones)
[ ] Cuentas de prueba creadas con los roles/permisos requeridos
(ver habilidad /test-accounts para el aprovisionamiento de cuentas)
[ ] Integraciones de terceros en modo prueba/sandbox:
[ ] Stripe: modo de prueba con claves API de prueba
[ ] Procesador de pagos: entorno sandbox
[ ] Correo electrónico/SMS: interceptado o usando destinatarios de prueba
[ ] Analítica: propiedad de dev/staging (no producción)
[ ] Backend/API apuntando a staging (no producción)
[ ] Base de datos sembrada con volumen de datos representativo
[ ] Notificaciones push configuradas para staging
[ ] Enlaces profundos / Enlaces universales configurados para el dominio de staging
[ ] Certificados SSL válidos en staging
[ ] Acceso VPN/red configurado para todos los evaluadores
3.4 Tabla de Roles de Interesados
Define quién hace qué. La ambigüedad en los roles significa brechas en la cobertura.
| Rol | Persona | Responsabilidades | Autoridad de Aprobación |
|---|---|---|---|
| Líder de UAT | [Nombre] | Posee el plan de UAT, coordina sesiones, tria errores, produce informe | Recomendación final go/no-go |
| Product Owner | [Nombre] | Valida que se cumplan los criterios de aceptación, prueba escenarios de lógica de negocio | Sí — aprobación de negocio |
| Líder de Diseño | [Nombre] | Valida fidelidad visual, patrones de interacción, consistencia de marca | Sí — aprobación de diseño |
| Líder de Ingeniería | [Nombre] | Disponible para investigación de errores, correcciones de entorno, explica restricciones técnicas | Sí — aprobación técnica |
| Evaluador de QA | [Nombre] | Ejecuta escenarios de prueba sistemáticamente, documenta hallazgos con evidencia | No — reporta al Líder de UAT |
| Experto en Dominio | [Nombre] | Prueba flujos de trabajo específicos del dominio (finanzas, salud, legal) | Sí — aprobación de dominio |
| Evaluador de Accesibilidad | [Nombre] | Prueba de lector de pantalla, navegación por teclado, verificación WCAG AA | Consultivo — escala al Líder de UAT |
La aprobación mínima viable requiere: Product Owner + Líder de Ingeniería. Todas las demás aprobaciones son recomendadas pero dependen del alcance.
Paso 4: Marco de Ejecución de UAT
Consulta reference/details.md (sección "Paso 4: Marco de Ejecución de UAT") para obtener detalles completos.
Paso 5: Aprobación y Puerta Go/No-Go
5.1 Matriz de Decisión Go/No-Go
La decisión go/no-go se basa en datos, no en opiniones. Puntúa cada criterio y calcula el resultado ponderado.
MATRIZ DE DECISIÓN GO / NO-GO
Función/Lanzamiento: _______________
Fecha: _______________
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┌──────────────────────────────────┬────────┬────────┬───────┬───────┐
│ Criterio │ Peso │ Estado │ Puntuación │ Notas │
├──────────────────────────────────┼────────┼────────┼───────┼───────┤
│ Todos los escenarios P0 pasan │ 30% │ GO/NOGO│ X/30 │ │
│ Todos los escenarios P1 pasan │ 25% │ GO/NOGO│ X/25 │ │
│ Sin errores P0 abiertos │ 20% │ GO/NOGO│ X/20 │ │
│ Sin errores P1 abiertos (o riesgo aceptado) │ 10% │ GO/NOGO│ X/10 │ │
│ Prueba de accesibilidad (WCAG AA)│ 5% │ GO/NOGO│ X/5 │ │
│ Rendimiento dentro del presupuesto│ 5% │ GO/NOGO│ X/5 │ │
│ Paridad multiplataforma verificada│ 5% │ GO/NOGO│ X/5 │ │
├──────────────────────────────────┼────────┼────────┼───────┼───────┤
│ TOTAL │ 100% │ │ X/100 │ │
└──────────────────────────────────┴────────┴────────┴───────┴───────┘
Umbrales de decisión:
GO >= 90/100 Todos los criterios P0 deben ser GO.
CONDICIONAL 70-89/100 Enviar con condiciones documentadas y cronograma de resolución.
NO-GO < 70/100 No lanzar. Corregir y volver a probar.
Bloqueadores duros (NO-GO automático independientemente de la puntuación):
- Cualquier error P0 abierto
- Escenario de pérdida o corrupción de datos
- Vulnerabilidad de seguridad (bypass de autenticación, exposición de datos)
- Bloqueo en un viaje de usuario crítico
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5.2 Plantilla de Aprobación
APROBACIÓN DE INTERESADOS
Función/Lanzamiento: _______________
Compilación/Versión: _______________
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┌──────────────────┬──────────────┬──────────┬────────────┬─────────┐
│ Interesado │ Rol │ Decisión │ Condiciones │ Fecha │
├──────────────────┼──────────────┼──────────┼────────────┼─────────┤
│ [Nombre] │ Product Owner│ GO/NOGO │ [si las hay] │ [fecha] │
│ [Nombre] │ Líder de Ing.│ GO/NOGO │ [si las hay] │ [fecha] │
│ [Nombre] │ Líder de Diseño│ GO/NOGO│ [si las hay] │ [fecha] │
│ [Nombre] │ Experto en Dominio│ GO/NOGO│ [si las hay] │ [fecha] │
│ [Nombre] │ Líder de UAT │ GO/NOGO │ [si las hay] │ [fecha] │
└──────────────────┴──────────────┴──────────┴────────────┴─────────┘
Aprobación condicional significa: "GO, siempre que los siguientes se resuelvan para [fecha]:"
1. [Condición]
2. [Condición]
Si CUALQUIER interesado firma NO-GO, el lanzamiento está bloqueado hasta que se resuelva su preocupación.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5.3 Plan de Reversión
Cada lanzamiento debe tener un plan de reversión documentado antes de la decisión go/no-go. Sin plan de reversión = NO-GO automático.
PLAN DE REVERSIÓN
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Desencadenante: [Condiciones que desencadenan la reversión — ej., tasa de bloqueo > 2%, error P0 en producción]
Propietario: [Quién inicia la reversión]
Pasos:
1. [Deshabilitar marca de función / revertir despliegue]
2. [Verificar que la reversión fue exitosa]
3. [Notificar a los interesados]
4. [Monitorear durante 30 minutos posteriores a la reversión]
Datos: [¿Se necesita alguna reversión de migración de datos? ¿Versionado de documentos Firestore?]
Comunicaciones:[Quién comunica a los usuarios si es necesario — equipo de soporte, página de estado]
Análisis posterior:[Programar dentro de las 48 horas posteriores a la reversión]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5.4 Borrador de Notas de Lanzamiento
Genera notas de lanzamiento a partir de los hallazgos de UAT. Los evaluadores de UAT conocen la función mejor que nadie en este punto.
NOTAS DE LANZAMIENTO (de hallazgos de UAT)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Versión: _______________
Fecha: _______________
NUEVO
- [Función/capacidad añadida — lenguaje orientado al usuario]
MEJORADO
- [Mejora de función existente — qué es mejor para el usuario]
CORREGIDO
- [Error corregido durante UAT — qué estaba roto y ahora está resuelto]
PROBLEMAS CONOCIDOS
- [Errores P2 que se envían con este lanzamiento — solución alternativa si está disponible]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Paso 6: Informe de UAT
Produce el informe completo de UAT después de que todas las sesiones estén completas y se haya recopilado la aprobación.
═══════════════════════════════════════════════════════════════
INFORME DE UAT
Función/Lanzamiento: [NOMBRE]
Versión/Compilación: [VERSIÓN]
Fecha: [HOY]
Líder de UAT: [NOMBRE]
═══════════════════════════════════════════════════════════════
RESUMEN EJECUTIVO
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Decisión: GO / CONDICIONAL / NO-GO
Escenarios totales: [N]
Pasaron: [N] ([X]%)
Fallaron: [N] ([X]%)
Bloqueados: [N] ([X]%)
No ejecutados: [N] ([X]%)
Bloqueadores abiertos: [N] P0 / [N] P1 / [N] P2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
TASA DE APROBACIÓN POR CATEGORÍA
┌──────────────────────┬──────────┬────────┬─────────┬────────┐
│ Categoría │ Total │ Pasaron│ Fallaron │ Tasa │
├──────────────────────┼──────────┼────────┼─────────┼────────┤
│ Ruta Feliz │ [N] │ [N] │ [N] │ [X]% │
│ Casos Extremos │ [N] │ [N] │ [N] │ [X]% │
│ Estados de Error │ [N] │ [N] │ [N] │ [X]% │
│ Multiplataforma │ [N] │ [N] │ [N] │ [X]% │
│ Accesibilidad │ [N] │ [N] │ [N] │ [X]% │
│ Rendimiento │ [N] │ [N] │ [N] │ [X]% │
│ Sin conexión/Conectividad│ [N] │ [N] │ [N] │ [X]% │
├──────────────────────┼──────────┼────────┼─────────┼────────┤