Lo que las Pruebas Unitarias no Detectan: Por Qué tu Release Necesita una Validación de Uso Real Antes del Go-Live
¿Cuántas veces tu equipo entregó algo «aprobado» y al día siguiente del go-live empezaron las quejas del usuario final?
¿Cuántas veces descubriste, demasiado tarde, que la persona que aprobó las pruebas no era la persona que iba a usar el sistema?
La validación de uso real es el último filtro antes del go-live: confirmar que el sistema no solo funciona, sino que funciona como el usuario final realmente trabaja. No es testing unitario, no es la aprobación del patrocinador — es la pregunta más incómoda y la única que cuenta: «¿quién es la dueña real de este proceso y ya lo usó como lo va a usar mañana?»
¿Por qué un sistema «aprobado» puede no estar listo?
Las pruebas unitarias confirman que el código funciona. La aprobación del patrocinador confirma que el sistema cumple lo contratado. Ninguna de las dos confirma que el usuario real pueda hacer su trabajo con el sistema cuando llegue el lunes.
Estos 5 puntos cambiarán cómo cierras un release:
- Las pruebas unitarias responden una pregunta técnica: ¿el código hace lo que dice que hace? Eso no es lo mismo que: ¿el sistema sirve para trabajar?
- El patrocinador aprueba el contrato, no el proceso: suele firmar lo que se prometió en la propuesta, no lo que ocurre en el día a día del usuario.
- El usuario real rara vez está en las pruebas formales: suele estar trabajando, no en reuniones de UAT.
- El flujo documentado y el flujo real casi nunca coinciden: la documentación captura el proceso ideal; el usuario real opera con excepciones, atajos y decisiones que nadie escribió.
- El go-live es donde aparece la dueña real del proceso: si no apareció antes, va a aparecer ahí — y va a tener razón.
Las 3 trampas que un equipo cae cuando aparece el problema tarde
Trampa 1 — Salir igual y esperar que no se note
La presión de la fecha empuja a deployar y «ya iremos ajustando en caliente». Funciona los primeros tres días. Después aparecen los tickets, el usuario pierde confianza, y reparar la reputación cuesta más que lo que costaba parar.
Trampa 2 — Posponer indefinidamente hasta que «esté perfecto»
La fecha del go-live se mueve sin nueva fecha. Eso no es prudencia — es parálisis. El usuario se queda con el sistema viejo, el equipo pierde momentum, y el aprendizaje no llega porque nada se prueba en producción.
Trampa 3 — Buscar culpables en el equipo técnico
«Los desarrolladores debieron prever esto.» No. El equipo técnico hizo lo que su Definition of Done le pedía. Si el DoD no incluía validar con el usuario real, el problema es el DoD, no las personas.
El protocolo de 4 pasos cuando la degradación aparece
1 Detén el go-live.
No la implementación entera. Solo la salida a producción. El equipo no para de trabajar — para de salir.
2 Identifica la causa raíz.
No es «el usuario no entiende» — eso es síntoma. La causa real es siempre una pregunta que no se hizo a tiempo: ¿quién es la dueña real?, ¿cómo trabaja realmente?, ¿qué excepciones maneja?
3 Arregla y replanifica.
No la implementación entera. Solo la salida a producción. El equipo no para de trabajar — para de salir.
4 Valida con el usuario real, no con el aprobador.
Antes de fijar la nueva fecha de go-live, la dueña del proceso tiene que ejecutar el flujo completo. No una demo. El flujo real.
El sistema que evita volver a este punto
Reaccionar bien una vez es un éxito. No volver a pasar por aquí es un sistema. Esto es lo que se construye después del primer susto:
Define el «usuario real» en el inicio del proyecto:
No es el cargo ni el departamento. Es la persona específica que va a abrir el sistema cada día. Si no la conoces al kickoff, ya tienes un riesgo identificado.
Añade «validación con usuario real» al Definition of Done:
«Done» no es «código aprobado» ni «patrocinador firmó». Es «la dueña del proceso ejecutó el flujo de punta a punta sin asistencia técnica y lo aceptó».
Programa la validación antes de la fecha de go-live, no después:
Reserva al menos dos semanas entre «sistema técnicamente listo» y «go-live». Esas dos semanas son la validación real. Si no caben en la planificación, la planificación está mal hecha — no se eliminan.
Ejemplo práctico: el SaaS que casi sale sin probarse con la dueña del proceso
Hace unos años trabajé en la implementación de un SaaS con un cliente. Los desarrolladores corrieron sus pruebas unitarias — todas verdes. El interlocutor del lado del cliente aprobó las pruebas funcionales — todo en orden. Avanzamos con confianza hacia las pruebas de usuario previas a la salida.
Y ahí apareció algo que no estaba en el plan: una persona que nadie había mencionado en seis meses de proyecto. Era la dueña real del proceso. La que iba a operar el sistema todos los días.
Ejecutó el flujo y la respuesta fue inmediata: «Esto no es como nosotros trabajamos.»
No era un bug. Era un gap entre el flujo documentado y el flujo que la dueña ejecutaba en la realidad: excepciones que ella manejaba a mano, un orden distinto en algunos pasos, validaciones que para ella eran obvias y que el sistema no contemplaba.
Lo que hicimos:
- Paramos el go-live. La fecha que teníamos no era viable y aceptarlo a tiempo era parte de la solución.
- Convocamos a la dueña real a sesiones de revisión detalladas. No «qué te parece» — sino «muéstrame cómo lo haces hoy».
- Documentamos las diferencias y priorizamos cuáles eran ajustes del sistema y cuáles eran procesos que sí podían cambiar.
- Trabajamos un mes con horas extra, sí — pero con foco. No reescribimos todo. Ajustamos lo necesario para que el flujo encajara.
- Replanificamos el go-live con una nueva fecha realista y volvimos a validar con ella antes de salir.
Salió. Funcionó. Y el cliente sigue siendo cliente.
Pero la lección no fue técnica. Fue: al inicio del próximo proyecto, la primera pregunta no es «quién aprueba», sino «quién va a usar esto cada día». Esa pregunta cambia todo el resto del proyecto.
Sin validación con usuario real: llegas al go-live confiado y descubres a la dueña del proceso en el peor momento posible — cuando ya no hay margen para ajustar sin dolor.
Con validación con usuario real: la dueña aparece en el kickoff, sus excepciones están documentadas, y el go-live es la consecuencia natural de un sistema que ya se probó con quien lo va a usar.
Errores típicos que debes evitar
- Confundir aprobación con validación: que alguien firme no significa que el sistema sirva. La validación es ejecución completa del flujo real.
- Validar con quien está disponible, no con quien usa: la persona que va a las reuniones rara vez es la que usa el sistema cada día.
- Saltarse la validación porque «ya hicimos pruebas»: las pruebas técnicas y la validación de uso son cosas distintas. Necesitas las dos.
- Mover el go-live sin nueva fecha clara: «lo movemos hasta que esté listo» es parálisis, no rigor. Cuantifica y comprométete.
Conclusión: las pruebas verdes no garantizan un go-live sin sorpresas
Un sistema técnicamente correcto puede ser operativamente inutilizable. Sin validación con el usuario real, el go-live es una apuesta. Con validación con el usuario real, el go-live es una consecuencia. La diferencia entre apostar y planificar es saber quién va a abrir el sistema el lunes — y haber visto cómo lo hace antes de que llegue ese lunes.
