¿Qué es la prueba de aceptación de usuario? La última comprobación antes de que alguien dependa de ello

La prueba de aceptación de usuario es el momento en que las personas que van a usar el software de verdad deciden si hace su trabajo. No si funciona - eso ya se ha probado - sino si hace lo que pidieron, de una forma con la que puedan vivir.

Es la única fase de pruebas cuyo propósito es una decisión y no una lista de defectos. La UAT termina con alguien diciendo sí o no a una entrega.

Qué la diferencia de cualquier otra prueba

Cada fase anterior pregunta si el software se ajusta a su especificación. La UAT pregunta si la especificación era correcta.

Esa distinción suena académica hasta que la ves ocurrir. Una función puede pasar todas las pruebas funcionales, cumplir cada criterio de aceptación tal como está escrito, y aun así ser rechazada en UAT porque la persona que hace ese trabajo trescientas veces por semana ve que le va a costar cuatro clics donde antes bastaba uno. Nada está roto. El requisito estaba mal, y este es el último momento barato para descubrirlo.

Pruebas de QA

¿Hace el software lo que dijimos que haría? Las ejecutan testers, contra la especificación

Prueba de aceptación de usuario

¿Hace lo que el negocio necesita? La ejecutan las personas cuyo trabajo es, contra la realidad

Quién la hace, y quién no debería

Las personas que van a usarlo. Ni el equipo de desarrollo, ni QA, ni un responsable que haga de sustituto.

Eso es más difícil de lo que parece. Las personas que quieres están ocupadas haciendo el trabajo para el que existe el software, y su tiempo es la parte más cara de todo el ejercicio. Por eso una UAT que se planifica a última hora acaba delegada en quien esté libre, y una entrega termina firmada por alguien que nunca ha hecho el trabajo que ese software sostiene.

Dos roles que merece la pena nombrar: alguien que sea dueño de la decisión y pueda decir que no, y alguien que recoja lo que encuentran los testers y lo convierta en algo sobre lo que un desarrollador pueda actuar. Sin el primero, la UAT produce opiniones y ningún resultado. Sin el segundo, produce una hoja de cálculo con la que nadie puede trabajar.

Qué hay que darles a los testers

No una lista de funciones. Una lista de las cosas que hacen normalmente.

1. Llevar a un cliente nuevo desde la consulta hasta la primera factura
2. Tramitar una devolución de un pedido pagado con tarjeta
3. Cerrar el mes con dos sucursales que reportan por separado
4. Corregir una dirección en un pedido que ya se ha enviado

Eso son procesos de negocio, y cada uno atraviesa varias funciones. A un tester al que le dices “revisa la pantalla de facturas” revisará la pantalla de facturas; a un tester al que le dices “lleva a un cliente nuevo hasta su primera factura” encontrará los dos sitios donde el proceso se rompe entre pantallas, que es donde viven los problemas de verdad.

Dales datos reales, o la copia segura más parecida. Una UAT sobre una base de datos con Cliente de Prueba 1 al 20 no encuentra ninguno de los problemas que un cliente llamado “O’Brien & Sons (antes Smith)” encuentra de inmediato.

Cuándo ha terminado

Antes de empezar, acordad qué significa “sí”. Por escrito, y en términos que alguien pueda comprobar.

• Qué procesos tienen que funcionar, y cuáles pueden resultar incómodos
• Qué cuenta como bloqueante frente a lo que se arregla en la siguiente entrega
• Quién firma, y qué está firmando
• Cuánto dura. Una UAT sin fecha de fin no termina; se desvanece

El fallo más común no es una mala prueba, es un final poco claro. Una fase que dura hasta que la gente deja de reportar cosas termina cuando se aburren, y una entrega que sale por aburrimiento es una entrega que nadie acordó.

Los reportes que produce la UAT

Esta es la parte para la que los equipos de desarrollo se preparan, y la razón es estructural más que culpa de nadie.

Tus testers no son testers. Son contables, coordinadores, enfermeras, comerciales - y describen lo que ha pasado en el lenguaje de su trabajo y no en el del software. “La factura fue a la sucursal equivocada” es una frase perfectamente clara y no es reproducible. Le faltan qué factura, qué sucursal, qué había en pantalla y qué esperaban en su lugar.

Dos cosas ayudan más que cualquier otra:

Pide el proceso, no el diagnóstico. “¿Qué estabas haciendo y qué esperabas que pasara?” te lleva más lejos que cualquier formulario, porque la suposición de un usuario de negocio sobre la causa suele estar equivocada y suele sustituir a los hechos.

Quítales de las manos la parte técnica. A nadie en una UAT se le debería pedir una versión de navegador, un log de consola ni pasos escritos para un desarrollador. Hacer eso bien es para lo que están las herramientas, y cuanto menos le pidas a un tester, más reportará.

Quien recoge los reportes todavía tiene que convertir cada uno en algo sobre lo que un desarrollador pueda actuar, y la guía de reportes de errores es la forma que eso toma. Si un hallazgo de UAT no se puede reproducir, se cerrará sin resolver por muy real que fuera.

La versión corta

La UAT pregunta si el software hace el trabajo, y lo deciden las personas cuyo trabajo es. Dales procesos en lugar de pantallas, datos reales en lugar de filas de prueba, una definición acordada de sí, y los menos deberes técnicos que puedas. Lo que vuelva estará expresado en su lenguaje, y convertir eso en algo reproducible es el trabajo, no una señal de que probaron mal.