Aceptar un software no significa declarar que nunca tendrá defectos. Significa decidir, sobre una versión identificada y con evidencia, si cumple los criterios acordados para el uso previsto o qué impide todavía su aceptación.
La decisión de aceptación corresponde al cliente, usuario, owner de negocio u otra persona que el acuerdo haya autorizado. QA y el equipo técnico aportan pruebas y correcciones; solo deciden la aceptación si esa autoridad se les ha asignado expresamente.
Fija la versión y la referencia que se van a probar
Antes de ejecutar casos, registra:
- versión o build;
- entorno y configuración;
- alcance y criterios vigentes;
- datos de prueba;
- integraciones o terceros disponibles;
- fecha y participantes;
- exclusiones y pendientes ya aceptados.
Si no existen criterios observables, vuelve a la guía para definir el alcance de un software. Probar contra impresiones distintas no produce una decisión reproducible.
NASA define la aceptación como comprobar criterios documentados y conservar evidencia vinculada a requisitos y objetivos (NASA SWE-034, observada el 29/08/2026). Su contexto incluye sistemas de alta exigencia; una pyme puede usar un formato más ligero sin trasladar toda su formalidad.
Separa QA, demostración y aceptación
| Actividad | Pregunta principal |
|---|---|
| Prueba técnica/QA | ¿La implementación se comporta como especifica el equipo? |
| Demostración | ¿Se puede mostrar el flujo y explicar su estado? |
| Aceptación de usuario | ¿El resultado acordado permite completar el trabajo previsto? |
| Puesta en producción | ¿La organización está preparada para operar la versión? |
Una demo no sustituye la ejecución por usuarios. La aceptación tampoco reemplaza pruebas de seguridad, rendimiento, accesibilidad o integración cuando forman parte de los criterios.
Elige usuarios con conocimiento del proceso
Participan, de forma proporcional:
- owner del resultado o persona autorizada para aceptar;
- usuarios que realizan los flujos críticos;
- responsable de datos o proceso cuando deba validar reglas;
- equipo técnico para reproducir y registrar hallazgos;
- proveedor externo cuando una dependencia lo requiera.
AGESIC diferencia las pruebas de desarrollo de las UAT: estas validan desde el punto de vista del organismo y deben basarse en requisitos y criterios acordados, no en cualquier deseo surgido durante la sesión (AGESIC, observada el 29/08/2026). El modelo pertenece al gobierno digital uruguayo; los roles y formalidad deben adaptarse al proyecto.
Diseña escenarios completos
Un caso de aceptación necesita:
| Campo | Contenido |
|---|---|
| ID | referencia estable |
| Objetivo | trabajo que valida |
| Precondición | estado, permiso y dato inicial |
| Pasos | acciones relevantes, no cada clic decorativo |
| Resultado esperado | condición observable |
| Evidencia | captura, registro, salida o comparación |
| Resultado real | qué ocurrió |
| Estado | pasa, falla, bloqueado o pendiente |
Cubre como mínimo:
- recorrido principal;
- permisos o perfiles diferentes;
- datos válidos e inválidos;
- duplicado, ausencia o error esperado;
- integración disponible y no disponible;
- recuperación o siguiente acción cuando algo falla.
No todos los proyectos necesitan la misma cobertura. Prioriza los flujos cuyo fallo impide operar, altera datos o deja una decisión sin salida.
Prepara datos y entorno de prueba
Los datos deben representar el proceso sin exponer información innecesaria. Define quién los prepara, qué variantes cubren y cómo se restablece el estado entre ejecuciones.
Comprueba también:
- permisos equivalentes a los perfiles reales;
- configuración y versión de terceros;
- notificaciones o integraciones aisladas cuando sea necesario;
- registros que permitan explicar el resultado;
- diferencias conocidas frente a producción.
Una prueba que pasa con una cuenta administradora y datos ideales puede no representar el uso diario.
Registra evidencia y discrepancias
Para cada ejecución conserva resultado esperado, resultado real, evidencia y versión. NASA recomienda evaluar los resultados frente a lo esperado, documentar discrepancias y mantener pruebas repetibles (NASA SWE-068, observada el 29/08/2026). Es una referencia de aseguramiento de software de alta exigencia, no una obligación documental universal.
La evidencia debe ser suficiente para reproducir o decidir. Acumular capturas sin referencia, entorno o caso no mejora la trazabilidad.
Clasifica el hallazgo antes de decidir
- Defecto: la versión incumple un criterio vigente.
- Cambio de alcance: aparece una necesidad no incluida o cambia el resultado esperado.
- Problema de datos o entorno: la prueba no puede concluir por una preparación incorrecta o una dependencia.
- Aclaración: hace falta precisar la referencia sin alterar el resultado.
- Mejora futura: aporta valor, pero no es necesaria para aceptar la versión actual.
No conviertas cada comentario de una sesión en defecto. Tampoco reclasifiques como cambio aquello que ya estaba acordado. La guía para gestionar cambios de alcance ayuda a registrar y decidir los casos que modifican la referencia.
Repite después de corregir
Cuando se corrige un defecto:
- reproduce el fallo original;
- ejecuta de nuevo el caso;
- revisa los flujos relacionados que puedan haberse afectado;
- registra nueva evidencia y versión;
- actualiza el estado sin borrar el historial.
Una corrección visible no demuestra por sí sola que el recorrido completo siga funcionando.
Decide aceptación, aceptación condicionada o bloqueo
La persona autorizada puede concluir:
accepted: los criterios acordados para esta entrega pasan;accepted-with-pending: existen pendientes explícitos que no impiden el uso acordado y tienen owner;blocked: falla un criterio que impide aceptar o la evidencia no permite decidir;not-evaluated: una dependencia dejó la prueba sin ejecutar.
Estas etiquetas son un mecanismo editorial, no términos contractuales obligatorios. El documento aplicable debe definir quién acepta y qué efectos tiene la decisión.
Aceptar una versión tampoco autoriza automáticamente su puesta en producción. Accesos, migración, observabilidad, soporte, comunicación y rollback pertenecen al siguiente trabajo operativo.
Checklist de cierre de aceptación
- Versión, entorno y referencia identificados.
- Owner y usuarios responsables presentes.
- Escenarios críticos y excepciones ejecutados.
- Datos, permisos e integraciones representativos.
- Evidencia vinculada a cada caso.
- Hallazgos clasificados como defecto, cambio, entorno o mejora.
- Correcciones relevantes repetidas y comprobadas.
- Pendientes con owner y decisión explícita.
- Resultado final registrado sin prometer ausencia de defectos.