Pruebas de aceptación de usuario (UAT): ejemplos y plantilla

Las pruebas de aceptación de usuario (UAT, del inglés user acceptance testing) son la última ronda de pruebas, en la que el cliente o usuarios reales comprueban que una web o aplicación hace lo que necesitan antes de publicarla. En un proyecto de agencia es también el momento en que el cliente dice formalmente «sí, esto es lo que encargamos». Cuando el cliente prueba con escenarios escritos y los criterios de aprobación se pactan antes de empezar, terminan con un sí claro en lugar de un goteo de peticiones nuevas. El plan de pruebas y el formulario de aprobación gratis de más abajo están pensados para eso.

¿Qué son las pruebas de aceptación de usuario (UAT)?

Las pruebas de aceptación de usuario son pruebas que hacen las personas que van a gestionar o usar un producto, con sus tareas reales, para decidir si lo aceptan. Quien desarrolla se pregunta «¿funciona?»; la UAT pregunta «¿nos sirve a nosotros?». El glosario del ISTQB, el vocabulario de referencia en pruebas de software, las define igual: decidir si un sistema satisface las necesidades de sus usuarios.

En una web, eso es la responsable de marketing del cliente publicando una noticia desde el gestor de contenidos, el equipo comercial recibiendo los contactos del formulario o un comprador pagando con un código de descuento. En una aplicación web, son los usuarios haciendo su trabajo diario en el nuevo sistema.

Las pruebas terminan con una aprobación por escrito: la web puede salir y esa fase del proyecto está cerrada. A la agencia también le interesa, porque marca dónde acaba el alcance pactado y dónde empiezan las peticiones nuevas.

¿Quién hace las pruebas de aceptación en un proyecto web?

Las hacen el cliente, su equipo o un grupo pequeño de usuarios finales; la agencia las prepara y corrige lo que salga. El cliente o responsable del proyecto ejecuta los escenarios, decide qué bloquea el lanzamiento y aprueba; el project manager redacta los escenarios con el cliente y clasifica las incidencias; desarrollo y diseño corrigen, pero aquí no prueban su propio trabajo.

La regla básica: quien ha montado la web no hace las pruebas de aceptación. Ya sabe cómo debería funcionar y no ve los problemas con los que tropieza alguien que la usa por primera vez.

¿En qué se diferencian las pruebas de aceptación y el QA?

El QA comprueba si la web está bien construida, y lo hace el equipo que la construye frente a la especificación, durante y después del desarrollo. Las pruebas de aceptación comprueban si es lo que el cliente necesita, y las hacen el cliente o usuarios reales frente a sus tareas, justo antes del lanzamiento. El QA termina con las incidencias corregidas; la UAT, con una aprobación formal.

Haz primero el QA. Si el cliente empieza las pruebas con formularios rotos y la maquetación descuadrada, se pasará el tiempo reportando cosas que deberías haber visto tú y perderá confianza en el proceso. Para ese paso tienes nuestra checklist web.

¿Cómo se hace un plan de pruebas de aceptación?

En seis pasos: pactar qué entra en el alcance, redactar entre diez y veinte escenarios con el cliente, preparar un entorno de pruebas con contenido definitivo y envío real de correos, decidir quién prueba qué y hasta cuándo, explicar cómo reportar y pactar los criterios de aprobación antes de empezar. Saltarse el último paso es lo que convierte las pruebas en una lista infinita.

1. Pacta el alcance: lista lo que se va a probar, como plantillas, formularios, proceso de compra, tareas en el gestor de contenidos e integraciones. Lo que no esté en la lista no forma parte de la aceptación.
2. Redacta los escenarios con el cliente: cada uno es una tarea real, con sus pasos y el resultado esperado (mira los ejemplos de abajo). Entre diez y veinte cubren la mayoría de webs corporativas y tiendas pequeñas.
3. Prepara el entorno: una web de pruebas con el contenido definitivo, envío real de correos y pagos en modo prueba, con accesos para quien los necesite.
4. Fija fechas y responsables: quién prueba qué y hasta cuándo. «Cuando tengas un rato» significa que las pruebas no terminan nunca.
5. Explica cómo reportar: una incidencia por aviso, con captura y lo que esperaba ver.
6. Pacta antes los criterios de aprobación: antes de empezar, no después.

¿Cómo es un escenario de prueba de aceptación? (ejemplos)

Es una tarea real escrita como una secuencia corta de pasos con un resultado esperado, para que quien prueba la marque como correcta o fallida. Se redacta con las palabras del cliente y en torno a un objetivo de negocio, como «un cliente compra con un código de descuento», no en torno a un componente técnico.

Si el cliente no sabe decir cuál es el resultado esperado de un escenario, es un requisito que nunca se pactó, y mejor descubrirlo ahora que después del lanzamiento.

Checklist de pruebas de aceptación para webs

Antes de que el cliente empiece, repasa esta lista para que la ronda pruebe la web y no la preparación. Complementa los escenarios: los escenarios comprueban tareas; la checklist, que está todo lo necesario para probarlas.

• QA terminado y sus incidencias corregidas o listadas
• La web de pruebas tiene el contenido definitivo, no textos de relleno
• Los correos de formularios y pedidos llegan a las direcciones reales del cliente
• Los pagos van en modo prueba y quien prueba tiene los datos de la tarjeta de prueba
• Cada persona que prueba tiene su acceso con el rol adecuado, si la web tiene cuentas
• Escenarios, fecha límite y criterios de aprobación enviados en un solo mensaje
• Un único canal para reportar (nada de correo, WhatsApp y llamadas a la vez)
• Una forma de separar errores de peticiones de cambio (una etiqueta o una lista aparte)
• La persona que clasifica las incidencias designada, con un momento al día para hacerlo
• Fecha reservada para volver a probar después de las correcciones

¿Cómo deben reportar las incidencias el cliente y los testers?

Cada incidencia debe ser un aviso con el ID del escenario, qué ha pasado y qué esperaba, la URL, el dispositivo, el sistema y el navegador, una captura con el problema marcado y una gravedad: bloqueante (no se puede lanzar), importante (hay que arreglarlo antes) o menor (puede esperar). Por correo el cliente olvida la mitad, así que el formato tiene que ser fácil o automático.

Aquí es donde se atascan casi todas las rondas. El cliente no es tester: manda correos tipo «el formulario no va en mi móvil», sin página, sin modelo de móvil y sin captura, y cada aviso así cuesta otra ronda de preguntas. Uno completo se parece a esto:

UAT-02: el código de descuento no se aplica en móvil

En iPhone (Safari), al meter OTONO10 en el carrito sale
«Código aplicado», pero el total no cambia.
Esperaba: un 10 % de descuento.
URL: pruebas.tudominio.es/carrito/
Gravedad: bloqueante

Nuestra plantilla de reporte de errores tiene todos los campos si quieres compartir un formato escrito. Una herramienta de feedback visual rellena la mayoría sola. Con GiveFeedback.io añades un script a la web de pruebas y aparece un botón de feedback. El cliente lo pulsa, marca el problema sobre una captura de la página, escribe un título y una descripción, y el aviso llega con la URL, la resolución de pantalla, el sistema operativo, el navegador y su versión. Quien prueba no necesita cuenta.

Puedes invitar al cliente al proyecto para que vea, en modo solo lectura, todo lo reportado y su estado (abierto, resuelto, archivado), y mandar cada aviso al gestor del equipo: una incidencia en Jira, una tarea en Asana, ClickUp o Wrike, una tarjeta en Trello o un mensaje en Slack o Discord. Para la mayoría de webs, una captura marcada con los datos del navegador es todo lo que necesita quien desarrolla para corregir el fallo.

¿Cuándo se dan por terminadas las pruebas de aceptación?

Las pruebas terminan cuando se cumplen los criterios pactados antes de empezar: todos los escenarios se han ejecutado al menos una vez, no queda ninguna incidencia bloqueante ni importante abierta, las menores están listadas con fecha de corrección, las peticiones de cambio están apuntadas y presupuestadas aparte, y el cliente lo confirma por escrito.

Criterios habituales en una web:

• Cobertura: se han ejecutado todos los escenarios al menos una vez.
• Gravedad: no queda ninguna incidencia bloqueante ni importante abierta.
• Incidencias menores: listadas con fecha de corrección; no bloquean el lanzamiento.
• Peticiones de cambio: apuntadas aparte y presupuestadas.
• Confirmación: el cliente aprueba por escrito, por correo o con el formulario de aprobación de arriba.

En la mayoría de proyectos basta con un correo así del cliente:

Hemos terminado las pruebas de aceptación de la nueva web en el
entorno de pruebas. Todos los escenarios, del UAT-01 al UAT-15,
funcionan correctamente. Las tres incidencias menores de la lista
se corregirán la primera semana tras el lanzamiento. Aprobamos la
publicación de la web el 14 de noviembre.

Con criterios así tienes una línea clara: la web hace lo pactado, se publica y lo nuevo va a la siguiente fase. Para ese último paso, lee nuestra guía sobre la aprobación del cliente en un proyecto web.

¿Cuáles son los errores más habituales en las pruebas de aceptación?

Cinco se repiten en casi todos los proyectos: empezar antes de terminar el QA, pedir al cliente que «le eche un ojo» en lugar de darle escenarios, recoger el feedback por cinco canales, mezclar errores con peticiones nuevas y no poner fecha límite. Cada uno alarga las pruebas y convierte una comprobación de tareas pactadas en un debate de gustos.

• Empezar antes de terminar el QA: el cliente se pasa el tiempo con fallos que deberías haber pillado tú.
• Sin escenarios, solo «échale un ojo»: recibes opiniones sobre colores en vez de comprobaciones de tareas.
• Feedback por cinco canales: correo, WhatsApp, llamadas y comentarios en un PDF. Elige uno y dilo claramente.
• Mezclar errores y peticiones nuevas: etiquétalos por separado desde el primer día.
• Sin fecha límite: pon las fechas en la planificación y en el contrato.

Esta semana, redacta con el cliente entre diez y veinte escenarios, pacta qué significa «terminado» y elige un único sitio para las incidencias. Solo con eso, las pruebas de aceptación pasan de ser la parte más tensa del proyecto a una lista corta y predecible.