Los criterios de aceptación redactados una vez finalizado el desarrollo no son criterios de aceptación. Son una opinión formada al observar el resultado y no pueden resolver nada.
Redactar los criterios antes de empezar el desarrollo
Los criterios de aceptación describen cómo decidirás si una funcionalidad está terminada y deben existir antes de desarrollarla por dos motivos: el desarrollador necesita saber qué se espera que construya y el cliente necesita un estándar que no esté influido por el resultado.
Un criterio útil es específico y comprobable:
- Débil: "La búsqueda debería funcionar bien."
- Útil: "Al buscar por el nombre del cliente, se devuelven los registros coincidentes en menos de dos segundos, se aceptan coincidencias parciales del nombre y no se distingue entre mayúsculas y minúsculas."
Cualquiera puede comprobar el segundo. El primero no se puede comprobar en absoluto.
Cómo realizar una UAT que detecte problemas reales
Las pruebas de aceptación de usuario (UAT) realizadas con un «echa un vistazo y dinos qué te parece» detectan problemas estéticos y pasan por alto los importantes. Una estructura mejora enormemente el proceso.
- Prueba los flujos de trabajo, no las pantallas. Recorre de principio a fin las tareas completas que realiza un usuario real. Los errores aparecen en las transiciones entre pantallas, no en las pantallas en sí.
- Usa datos realistas. Nombres largos, caracteres con acentos, campos opcionales vacíos, cantidades grandes y fechas en los límites de meses y años. Los datos de prueba limpios ocultan la mayoría de los problemas de gestión de entradas.
- Prueba deliberadamente los casos de error. Envía el formulario dos veces. Introduce una contraseña incorrecta cinco veces. Pierde la conexión a mitad del proceso. Es en estos casos donde acaban los usuarios reales y donde rara vez llegan las pruebas.
- Haz que lo prueben los usuarios reales. La persona que utilizará el sistema a diario detectará problemas que el patrocinador nunca verá, porque sabe en qué consiste realmente el trabajo.
- Registra cada hallazgo en un solo lugar, con los pasos para reproducirlo y una captura de pantalla. Un hallazgo que no se puede reproducir no se puede corregir.
Defecto o cambio
Toda UAT genera hallazgos que no son defectos; clasificarlos de forma justa evita que el proceso se vuelva conflictivo.
Un defecto es una diferencia entre lo acordado y lo construido. Se corrige a cargo del desarrollador.
Un cambio es algo que funciona según lo acordado, pero que ya no es lo que quiere el cliente. Se presupuesta por separado.
A menudo, los clientes perciben lo segundo como un defecto, porque el software hace algo que no esperaban. La respuesta honesta no es discutir la etiqueta, sino señalar el criterio acordado y preguntar si vale la pena hacer el cambio. Muchos no lo valen.
Severidad: qué determina qué impide el lanzamiento
No todos los defectos deben corregirse antes de la puesta en producción, y tratarlos a todos como bloqueantes retrasa los lanzamientos sin beneficio alguno. Una clasificación sencilla de tres niveles, acordada de antemano:
- Bloqueante — no se puede completar un flujo de trabajo esencial, se pierden o corrompen datos, o existe un problema de seguridad. Debe corregirse antes del lanzamiento.
- Grave — una funcionalidad no funciona correctamente, pero existe una solución alternativa. Se corrige antes del lanzamiento si hay tiempo; de lo contrario, se programa para una fecha concreta.
- Leve — problemas estéticos, redacción e incoherencias menores. Se agrupan para una versión posterior al lanzamiento.
Acordar esta clasificación antes de empezar la UAT convierte una discusión sobre la urgencia en una evaluación compartida.
A qué compromete la aprobación a ambas partes
La aprobación debe tener un significado concreto: se cumplen los criterios acordados, se enumeran los elementos menores pendientes con sus fechas y se libera el pago correspondiente al hito. También inicia el periodo de garantía, durante el cual los defectos que se detecten más adelante se corrigen sin coste.
No significa que el cliente ya no pueda volver a informar de un problema, y un contrato que dé a entender eso no es razonable. El periodo de garantía cubre los defectos que no habría detectado una UAT razonable.
Tiempo que conviene reservar
La UAT suele planificarse con menos tiempo del necesario. Para un proyecto pequeño, reserva de una a dos semanas: tiempo suficiente para que los usuarios reales prueben el sistema mientras realizan su trabajo habitual, se corrijan los hallazgos y se repitan las pruebas.
Reducir este plazo a dos días produce una aprobación sin valor, y los problemas aparecen en la primera semana de uso real, cuando corregirlos cuesta más y son mucho más visibles.
Servicios de Manboo relacionados
- Desarrollo de aplicaciones Flutter para MVP de iOS y Android.
- Desarrollo de software empresarial para sistemas de CRM, reservas, inventario y flujos de trabajo.
- Desarrollo de paneles de administración para paneles de operaciones y gestión del backend.
- Integración de API de IA cuando tu producto esté listo para incorporar búsqueda inteligente, chat o automatización.
- Solicita una revisión del alcance y un presupuesto del proyecto cuando estés listo para planificar la primera versión.