El blog de QA en español de Redsauce

UAT y testing ágil. ¿Qué son y cómo hacerlas?

Artículo de Pablo Gómez

UAT y testing ágil. ¿Qué son y cómo hacerlas?

¿Cuál es el significado de UAT?

UAT, significa por sus siglas en inglés: prueba de aceptación del usuario (User Acceptance Testing) y es crucial en la validación del software. Es una de las últimas etapas donde el cliente verifica que el producto cumple con sus expectativas. En este contexto, la UAT se realiza en un entorno similar al real para asegurar que el software satisface las necesidades y requisitos del usuario final. Es esencial para identificar problemas desde la perspectiva del usuario antes del despliegue final.


Cuando hablamos de qa testing una de las últimas fases de validación de nuestro producto es la prueba de aceptación del usuario (UAT, por sus siglas en inglés). Se trata, por tanto, de una de las últimas oportunidades para el cliente de asegurarse de que el producto se ajusta a lo esperado.


Este tipo de test puede confundirse con otros como functional testing, end-user testing, alpha-testing, beta-testing, black-box testing, operational acceptance testing, contract acceptance testing o regulation acceptance testing. Pero entonces…

¿Qué es la UAT?

Afortunadamente en este caso el significado del acrónimo es bastante autoexplicativo: las pruebas que se realizan al producto en un entorno idéntico al real y por su público objetivo. Se realiza para comprobar si un producto o sistema de software cumple con los requisitos y expectativas del usuario final. Es decir, se trata de una prueba que se realiza para asegurarse de que el producto es aceptable y útil para las personas que lo utilizarán en su día a día.

¿Por qué hacemos la UAT? ¿No es lo mismo que un test funcional?

La UAT se realiza después de las pruebas unitarias, las pruebas de integración y las pruebas de sistema, lo que significa que el producto ya ha sido probado exhaustivamente por los desarrolladores. Esto también incluye a las pruebas funcionales, que validan los requisitos y especificaciones del software sin tener en cuenta al usuario. Sin embargo, la UAT se centra precisamente en la experiencia del usuario final y puede descubrir problemas que no se detectaron en pruebas anteriores. Estos usuarios finales pueden ser clientes, empleados, socios o cualquier persona que vaya a interactuar con el producto o sistema en cuestión.

Tipos de UAT

Hay varios tipos de test que podrían “encajar” en la definición de UAT. Entre ellos podríamos citar:

Alfa y beta testing

En estos casos la UAT la realizan grupos de usuarios finales que en estos casos, harán de testers. En el caso del Alfa testing, generalmente los usuarios finales son empleados internos de la compañía empleando un entorno de pruebas específico y dedicado. Esta fase Alfa, que se lleva a cabo antes que la Beta, ayuda a detectar errores y problemas de usabilidad. Este es el tipo de UAT más común, donde habitualmente es una figura del equipo de Producto quien realiza la prueba.


Por otro lado, el Beta testing (también llamado test de campo) es llevado a cabo por un grupo de usuarios finales “controlados” que usan la aplicación también en un determinado entorno diferente al definitivo pero más cercano que en el caso del Alfa testing. También han de poder ofrecer feedback al equipo de desarrollo, que se traduce en más mejoras del producto.

Pruebas de aceptación operacional (Operational Acceptance Testing)

Estas pruebas se llevan a cabo para validar que hay procesos que ayuden a que el software sea compatible con otras versiones, que sea estable bajo determinadas circunstancias, que haya planes de backup, de seguridad, formación para los usuarios, etc.

Pruebas de aceptación de regulación (Regulation Acceptance Testing o Compliance Acceptance Testing)

Validan que el software desarrollado cumpla con las leyes y regulaciones aplicables, que pueden ser locales, nacionales, gubernamentales, etc.

Pruebas de aceptación de contrato (Contract Acceptance Testing)

En este caso se prueba que el software cumpla los criterios y especificaciones que el equipo de proyecto ha definido en el contrato.

Cómo llevar a cabo una UAT

Diría que a lo largo de mi vida laboral, hemos conocido tantas formas de llevar a cabo una UAT como empresas hemos visitado. Más técnicas, menos técnicas, con diferentes actores implicados, en un momento del ciclo de desarrollo o en otro, en diferentes entornos… (sólo el jardín de la gestión de entornos daría para otra entrada del blog). Sin embargo, de manera habitual, todas las UAT comparten (o deberían compartir) estos pasos:

  1. Calendarizar el día de la prueba

Generalmente el propio ciclo de desarrollo ágil tiene definido un día para realizar esa UAT pero en cualquier caso, recomiendo tenerlo calendarizado.

  1. Identificar las funcionalidades implicadas

El objetivo es que las pruebas cubran en la medida de lo posible todos los casos de uso que el usuario final pueda llegar a hacer. Tener claras qué funcionalidades se han incluido o se han visto afectadas en la release ayuda a saber qué tipos de pruebas hacer y también a no dejarnos nada en el tintero.

  1. Seleccionar el equipo que llevará a cabo la prueba

Generalmente es una o varias personas del equipo de producto quienes llevan a cabo esta UAT. Es la figura que sabe qué hacía falta, quien acordó los criterios de aceptación y en última instancia, el “representante” de nuestro usuario final. En algunas ocasiones esta UAT puede llevarse a cabo por otro equipo de la empresa o incluso un conjunto seleccionado de usuarios finales que harán de beta-testers.

  1. Relacionar los fallos en un gestor de defectos

Es muy conveniente poder tener relacionados todos los fallos que se han encontrado en la UAT con el fin de realizar una clasificación, tener el detalle del defecto, saber en qué release ha aparecido, cómo reproducirlo, etc.

  1. Valorar las incidencias y hacer un triaje

Una vez dispongamos de los fallos encontrados, es necesario clasificarlos para decidir si la versión puede desplegarse en producción con esos errores y corregirlos más adelantes o si por el contrario, es necesario corregirlos.

  1. Decisión final

Por último, en base a los puntos anteriores, se ha de decidir si el software está listo para su despliegue en producción y escoger una fecha para hacerlo o esperar al siguiente sprint para disfrutar de la nueva funcionalidad.


Y tú, ¿cómo gestionas las UAT en tu equipo?


Si buscas una empresa de software que te ayude con la calidad o tus pruebas, recuerda que puedes encontrarnos en Google Maps o contactar con nosotros. Estaremos encantados de ayudarte.


Muchas gracias, salud y felices UAT :)


Este y otros muchos consejos los encontrarás en nuestro Ebook gratuito, 30 consejos de QA para transformar tu desarrollo. Descárgarlo gratis ahora:


QA Free ebook

Sobre nosotros

Has llegado al blog de Redsauce, un equipo de expertos en QA y desarrollo de software. Aquí hablaremos sobre, testing ágil, automatización, ciberseguridad… ¡Bienvenido!