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». En esta guía verás quién las hace, en qué se diferencian del QA, cómo planificarlas con una plantilla de escenarios, cómo recoger las incidencias y cuándo darlas por cerradas.

Qué son las pruebas de aceptación UAT

Las pruebas de aceptación son pruebas que hacen las personas que van a gestionar o usar el producto, con sus tareas reales, para decidir si lo aceptan. El desarrollador se pregunta «¿funciona?»; la UAT pregunta «¿nos sirve a nosotros?».

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.

La UAT termina 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 la UAT

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.

Diferencias entre UAT y QA

Se confunden porque las dos consisten en «probar la web», pero responden a preguntas distintas:

Haz primero el QA. Si el cliente empieza la UAT 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 QA web.

Cómo planificar la UAT en 6 pasos

1. Pacta el alcance. Lista lo que se va a probar: plantillas, formularios, proceso de compra, tareas en el gestor de contenidos, integraciones. Lo que no esté en la lista no forma parte de la aceptación.
2. Redacta los escenarios con el cliente. Cada escenario es una tarea real, con sus pasos y el resultado esperado (mira la plantilla de abajo). Entre 10 y 20 escenarios 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. Da accesos a quien los necesite.
4. Fija fechas y responsables. Quién prueba qué y hasta cuándo. «Cuando tengas un rato» significa que la UAT no termina nunca.
5. Explica cómo reportar. Una incidencia por aviso, con captura y lo que esperaba ver. Lo vemos más abajo.
6. Pacta los criterios de aprobación antes de empezar, no después.

Plantilla de escenarios de prueba (con ejemplos)

Un escenario describe una tarea, los pasos para hacerla y el resultado esperado. Quien prueba rellena las dos últimas columnas.

Escribe los escenarios con las palabras del cliente y en torno a sus objetivos («un cliente compra…»), no en torno a componentes técnicos («checkout de WooCommerce»). Si el cliente no sabe decir cuál es el resultado esperado, es un requisito que nunca se pactó, y mejor descubrirlo ahora.

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

Aquí es donde se atascan casi todas las rondas de UAT. 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. Cada aviso así te cuesta otra ronda de preguntas.

Dale un formato sencillo. Un buen aviso de UAT incluye:

• ID del escenario (por ejemplo, UAT-02), para saber qué estaba haciendo
• Qué ha pasado y qué esperaba
• URL de la página
• Dispositivo, sistema operativo y navegador
• Una captura de pantalla con el problema marcado
• Gravedad: bloqueante (no se puede lanzar), importante (hay que arreglarlo antes) o menor (puede esperar)

Ejemplo:

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.

Puedes pedirlo por correo, pero el cliente se olvidará de la mitad de los datos. Una herramienta de feedback visual los rellena 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 a Asana o Notion como tarea. No graba vídeo ni recoge los logs de consola, y el botón del widget está en inglés, así que en una aplicación compleja puede que el desarrollador tenga que reproducir el fallo; para la UAT de la mayoría de webs, una captura marcada con los datos del navegador basta.

Criterios de aprobación: cuándo se da por terminada la UAT

Pacta los criterios antes de empezar y déjalos por escrito en el documento del proyecto. Criterios habituales en una web:

• Se han ejecutado todos los escenarios al menos una vez
• No queda ninguna incidencia bloqueante ni importante abierta
• Las incidencias menores están listadas con fecha de corrección (no bloquean el lanzamiento)
• Las peticiones de cambio están apuntadas aparte y presupuestadas
• El cliente lo confirma por escrito (correo o documento firmado)

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.

Sin criterios escritos, la UAT se convierte en una lista infinita de «una cosita más». Con ellos tienes una línea clara: la web hace lo pactado, se publica, y lo nuevo va a la siguiente fase. Si quieres profundizar en ese último paso, lee nuestra guía sobre la aprobación del cliente en un proyecto web.

Errores habituales en la UAT

• 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 de la UAT en la planificación y en el contrato.

Esta semana, redacta con el cliente entre 10 y 20 escenarios, pacta con él qué significa «terminado» y elige un único sitio para las incidencias. Solo con eso, la UAT pasa de ser la parte más tensa del proyecto a una lista corta y predecible.