Pruebas de aceptación (UAT): cuando el que decide no es el tester

Un equipo entrega un módulo de facturación. Las pruebas unitarias pasan, la integración pasa, el end-to-end pasa. Verde en todas partes. Lo despliegan un viernes. El lunes la contadora lo abre, hace tres clics y dice: "esto no me sirve, así no facturamos". Nadie escribió una sola línea de código malo. Y aun así el software falló.

Ese hueco tiene nombre. Se llama aceptación. Y la prueba que lo cubre, la UAT (User Acceptance Testing, prueba de aceptación de usuario), es la que más se salta, más se improvisa y peor se entiende de toda la cadena de calidad. La respuesta corta: la UAT no verifica que el software esté bien construido, verifica que sea el software correcto para quien lo va a usar. Son dos preguntas distintas y casi nadie las separa.

01 · qué esLa aceptación responde otra pregunta

Hay una frase vieja en calidad de software que lo resume: la verificación pregunta "¿construimos el producto bien?" y la validación pregunta "¿construimos el producto correcto?". La UAT vive del lado de la validación. No le importa si el algoritmo es elegante ni si la cobertura llega al noventa por ciento. Le importa una sola cosa: si la persona que pidió esto puede hacer su trabajo con lo que le entregaste.

El estándar de testing ISTQB coloca la aceptación como el último de los cuatro niveles de prueba, tras las de componente, integración y sistema. Y marca una diferencia que en la práctica se ignora: los niveles anteriores los ejecuta el equipo técnico contra especificaciones técnicas. La aceptación la ejecuta, o la aprueba, quien va a vivir con el producto. El tester prepara el terreno. El que decide no es el tester.

Verde en toda la suite significa que el código hace lo que dijimos. No significa que dijimos lo correcto.

Esto no es un tecnicismo. Es la razón por la que un software impecable puede ser un fracaso. La contadora del ejemplo no encontró un bug. Encontró una funcionalidad que resuelve un problema que ella no tiene, y que no resuelve el que sí tiene. Ningún nivel técnico de prueba habría atrapado eso, porque todos ellos parten de la misma especificación equivocada.

02 · el error"A mí me gusta" no es un criterio

Aquí está el pecado original de casi toda UAT. Se convoca a un usuario, se le sienta frente al sistema y se le pide que "revise si está bien". El usuario navega un rato, hace lo que se le ocurre, y al final emite un veredicto: "me gusta" o "no me convence". Eso no es una prueba de aceptación. Es una encuesta de opinión disfrazada.

El problema de "a mí me gusta" es que no es repetible, no es discutible y no es responsabilidad de nadie. Si el usuario tiene un buen día, aprueba. Si tiene un mal día, rechaza. Y cuando en producción aparece un problema, nadie puede señalar qué se aceptó exactamente, porque nunca se escribió. La aceptación se volvió un estado de ánimo.

La alternativa tiene un nombre que suena burocrático pero salva proyectos: criterios de aceptación. Son condiciones concretas, verificables y acordadas antes de construir, que definen qué significa que algo esté terminado y sea aceptable. No "la factura se ve bien", sino "una factura con tres ítems, dos con IVA y uno exento, calcula el total correcto y lo muestra en pesos con dos decimales". Eso se puede probar. Eso pasa o no pasa. Eso no depende del humor.

Hay un formato que ayuda a no divagar, popularizado por el desarrollo guiado por comportamiento: dado un contexto, cuando ocurre una acción, entonces se espera un resultado. "Dado un cliente sin cupo de crédito, cuando intenta facturar a crédito, entonces el sistema lo bloquea y muestra el mensaje X." No hace falta la ceremonia completa. Hace falta la disciplina de escribir el resultado esperado antes, no de improvisarlo mirando la pantalla.

Criterio medible: pasa o no pasa. Gusto personal: depende de quién y de cuándo. Solo uno de los dos se puede firmar.

03 · cómo se haceAceptación que se puede firmar

Una UAT sana tiene tres momentos, y ninguno es "el usuario juega un rato". El primero ocurre antes de escribir código: se acuerdan los criterios de aceptación con quien va a decidir. Si el negocio no puede decir de antemano qué haría que acepte, el equipo está construyendo a ciegas y la UAT solo va a descubrir el desacuerdo tarde y caro.

El segundo momento es la ejecución. El usuario, o QA acompañando al usuario, recorre casos reales de negocio contra esos criterios ya escritos. No casos técnicos de borde: casos que la persona vive de verdad. La contadora factura el tipo de factura que factura cada día, con los datos raros que ella conoce y el equipo no. Ese conocimiento del dominio es justamente lo que la UAT aporta y ningún otro nivel de prueba tiene.

El tercer momento es el veredicto, y este es el que casi nadie formaliza. La aceptación termina con una decisión trazable: se acepta, se acepta con salvedades listadas, o se rechaza con motivos concretos ligados a criterios. Esa decisión tiene un dueño con nombre. En muchos marcos contractuales esto es literalmente una prueba de aceptación de contrato: lo que se firme define si el proveedor cumplió. No es un detalle de proceso. Es dónde cambia el riesgo de manos.

04 · dónde encajaLa UAT no reemplaza a QA, la cierra

Un malentendido frecuente: creer que si hay UAT, sobra el testing técnico, o al revés. Los dos prueban cosas distintas. Las pruebas unitarias, de integración y de sistema aseguran que el producto está bien construido. La aceptación asegura que es el producto correcto. Saltarse las primeras te lleva a un producto correcto lleno de defectos. Saltarse la segunda, a un producto impecable que nadie quería.

Por eso la UAT es la última puerta, no la única. Llega cuando lo técnico ya está verde, y aun así puede decir que no. Ese "no" al final es incómodo, pero es más barato que el del cliente en producción.

Una sola idea para llevarse: la aceptación no se mide en cobertura, se mide en decisiones que alguien puede firmar. El día que tu UAT produzca un documento donde un responsable dice "acepto estos criterios y rechazo estos otros, por estas razones", dejaste de hacer teatro y empezaste a hacer aceptación. Y el lunes por la mañana, cuando la contadora abra el módulo, ya sabrás la respuesta antes de que ella hable.