Pruebas de aceptación de software: cómo evitar el retrabajo que nadie presupuestó
Cómo usar criterios y pruebas de aceptación para validar flujos reales antes de entregar software y evitar retrabajo caro.
Cuando alguien dice “ya quedó”, la pregunta incómoda es: ¿quedó para quién? Una pantalla puede verse terminada, no tener errores obvios y aun así fallar en el momento exacto en que una persona intenta cobrar, agendar, aprobar o cerrar su día.
Las pruebas de aceptación de software existen para evitar ese teatro. No son otra ronda de clics porque “hay que probar”. Son el acuerdo concreto de que una funcionalidad resuelve el trabajo que prometía resolver antes de entregarla.
El bug más caro no siempre tira la app
Un error técnico que rompe una pantalla se detecta rápido. El más caro suele ser más silencioso: el flujo funciona, pero obliga al equipo a hacer una excepción manual, no contempla una regla de negocio o deja al cliente sin saber qué pasó después de presionar guardar.
Piensa en una app de pedidos. Decir “se puede crear un pedido” no alcanza. ¿Qué ocurre si no hay inventario? ¿Quién puede aplicar un descuento? ¿Se puede corregir una dirección? ¿Llega una confirmación? Cada respuesta cambia lo que significa que esa función esté lista.
Ahí entran las pruebas de aceptación de software, también llamadas UAT por sus siglas en inglés. La idea es sencilla: comprobar con escenarios reales que el producto cumple una necesidad del negocio, no solo que el código compila y la demo se ve bonita.
Los criterios de aceptación convierten opiniones en acuerdos
Antes de desarrollar una funcionalidad, vale la pena escribir las condiciones que deben cumplirse para darla por aceptada. No hace falta convertir cada requisito en un documento de cincuenta páginas. Hace falta quitarle espacio a los supuestos.
Para una función de recuperación de contraseña, un criterio útil no sería “que mande correo”. Sería algo como: una persona registrada puede solicitar un enlace, el enlace vence después de cierto tiempo, no revela si un correo no existe y, al cambiar la contraseña, puede iniciar sesión con la nueva.
Eso le da a producto, desarrollo y operación una misma definición de terminado. También hace las conversaciones mucho mejores. En vez de discutir si algo “se siente incompleto”, se revisa una condición específica y se decide qué hacer.
Los criterios de aceptación no sustituyen el diseño técnico ni las pruebas automáticas. Son otra capa. El equipo técnico valida que el sistema se comporte de forma segura y estable. Quien usa u opera el producto valida que ese comportamiento sirve para trabajar.
No esperes al final para descubrir el flujo real
El error clásico es dejar la aceptación para la última semana, cuando ya hay fechas prometidas, presupuesto gastado y cero ganas de abrir otra conversación. En ese punto, cualquier hallazgo parece un retraso aunque solo revele una decisión que nadie tomó antes.
Mejor revisa los criterios cuando se plantea la historia, confirma escenarios antes de construir y prueba cada bloque cuando está listo. Así una observación llega todavía a tiempo de ser una decisión, no una emergencia.
También conviene que pruebe la persona que conoce el trabajo cotidiano. Si el sistema lo usará un encargado de almacén, un vendedor o alguien de finanzas, su recorrido vale más que una revisión hecha solo por quien patrocinó el proyecto. Esa persona sabe dónde se rompe el día normal: pedidos duplicados, permisos raros, datos incompletos y clientes que no siguen el camino ideal.
Una prueba útil parece trabajo, no una demo
Una buena sesión de aceptación parte de tareas reales. “Registra una venta con descuento y devuélvela parcialmente.” “Cierra una orden que quedó pendiente.” “Invita a un usuario con permiso limitado.” El objetivo no es recorrer todas las pantallas, sino verificar que un resultado importante puede lograrse sin trucos.
Cada escenario debería tener un resultado esperado y una decisión registrada: aceptado, requiere ajuste o queda fuera de este alcance. Esa última opción es sana. No todo hallazgo debe convertirse en cambio inmediato; lo peligroso es fingir que no existe o mezclarlo con un defecto de lo ya acordado.
En DevAces solemos preferir esta claridad desde el arranque. Hace más honesta una cotización y protege a ambos lados: el cliente sabe qué va a poder hacer al recibir una entrega, y el equipo no adivina reglas críticas a mitad del camino.
La entrega empieza con una definición clara de “listo”
Si vas a contratar o construir software, pide criterios de aceptación para los flujos que mueven dinero, operación o confianza. No necesitas saber programar para hacer esa pregunta. Solo necesitas describir qué debe poder lograr una persona, bajo qué condiciones y cómo sabrán que salió bien.
Las pruebas de aceptación de software no eliminan los cambios. Eliminan la sorpresa de descubrir demasiado tarde que cada quien imaginaba un producto distinto.
Si tienes un flujo importante pero todavía no sabes cómo aterrizarlo en alcance, podemos revisarlo contigo antes de que se convierta en meses de retrabajo.