Free Press

En las pruebas de aceptación del usuario (UAT), el software es probado por los usuarios reales en sus instalaciones. También se denomina con otros nombres como prueba beta y prueba de usuario final. Básicamente se realiza para confirmar que el sistema desarrollado está de acuerdo con los requisitos de los usuarios que fueron compartidos con los desarrolladores antes del inicio del desarrollo del sistema.

¿Qué es la prueba de aceptación del usuario?

Es un tipo de prueba que realizan los usuarios reales en la última etapa de las pruebas, antes de que el producto o la aplicación se lance al entorno de producción o al mercado.

El entorno utilizado para realizar las Pruebas de Aceptación del Usuario (UAT) es similar al entorno de producción y no es el entorno de desarrollo.

Lista de comprobación de las Pruebas de Aceptación del Usuario (UAT)

Es importante asegurarse de que las siguientes etapas y sus actividades de prueba se cubren como parte de las Pruebas de Aceptación del Usuario para garantizar resultados óptimos de las UAT.

1. Inicio del proyecto de Pruebas de Aceptación del Usuario
2. Planificación de las Pruebas de Aceptación del Usuario
3. Diseño de las Pruebas de Aceptación del Usuario
4. Ejecución de las Pruebas de Aceptación del Usuario
5. Decisiones de lanzamiento
6. Acciones posteriores a las Pruebas de Aceptación del Usuario

A continuación se indican las actividades que forman parte de cada una de las etapas anteriores.

Inicio del proyecto de Pruebas de Aceptación del Usuario

Las siguientes actividades deberían llevarse a cabo idealmente como parte del inicio del proyecto UAT.

1. Identificar las partes interesadas clave
2. Seleccionar un líder de equipo
3. Comunicar la intención del negocio, objetivos y criterios de aceptación del sistema
4. Acordar los recursos del equipo de Pruebas de Aceptación del Usuario
5. Acordar la documentación para apoyar las Pruebas de Aceptación del Usuario
6. Acordar las estructuras de toma de decisiones
7. Acordar sobre el equipo de Pruebas de Aceptación de Usuario
8. Iniciar la formación de las Pruebas de Aceptación de Usuario
9. Formar un plan de proyecto inicial para las Pruebas de Aceptación de Usuario

Planificar las Pruebas de Aceptación de Usuario

Mientras se planifica la UAT, se deben realizar las siguientes tareas.

1. Identificar el método de adquisición del sistema para determinar el mejor enfoque para las Pruebas de Aceptación del Usuario.
2. Determinar si la intención del negocio y las expectativas del usuario han sido capturadas y son medibles.
3. Verificar que los requisitos del negocio han sido capturados.
4. Verificar que se han incluido todos los tipos de requisitos.
5. Escribir los criterios de aceptación y comprobar que son adecuados.
6. Asegurar que el alcance es claro y relevante.
7. Capturar y verificar los procesos de negocio.
8. Evaluar la documentación actual y su sostenibilidad para servir como base de la prueba.

Diseño de la prueba de aceptación del usuario

Es importante asegurarse de que el diseño de la prueba para la UAT sigue los siguientes pasos con el fin de garantizar que la UAT proporciona el resultado deseado.

1. Establecer los criterios de entrada para las Pruebas de Aceptación del Usuario.
2. Revisar los guiones de prueba donde estén disponibles.
3. Definir la estrategia de las Pruebas de Aceptación del Usuario.
4. Revisar las condiciones de prueba existentes donde estén disponibles y escribir otras nuevas.
5. Revisar los casos de prueba existentes donde estén disponibles y escribir otros nuevos basados en las condiciones de prueba.
6. Escribir guiones de prueba basados en los casos de prueba.
7. Asegurarse de que las pruebas cubren todos los requisitos.

Ejecución de pruebas de aceptación del usuario

Las siguientes tareas deben ejecutarse como parte de la ejecución de la prueba UAT.

1. Comprobar la disponibilidad del entorno de prueba.
2. Definir el cronograma de pruebas de alto nivel contra la estrategia de pruebas de aceptación del usuario para lograr las prioridades.
3. Definir el cronograma de pruebas detallado para lograr el mejor uso de los recursos.
4. Asegurar que el registro de pruebas se mantenga actualizado.
5. Asegurar que los incidentes se reporten con precisión y a tiempo.
6. Comprobar regularmente la resolución de defectos con el equipo de desarrollo y asegurarse de que no hay cuellos de botella.
7. Generar informes regulares de resumen de las pruebas.

Decisiones sobre la liberación de las pruebas de aceptación del usuario

Los siguientes puntos ayudarán al equipo a decidir si seguir adelante con la liberación o no, después de la UAT.

1. Identificar el estado frente a los criterios de aceptación.
2. Identificar el esfuerzo y el tiempo necesario para cumplir con los criterios de aceptación en detalle.
3. Examinar las alternativas basadas en los riesgos pendientes.
4. Criterios de liberación de emergencia para permitir la liberación controlada.
5. Informar del estado a las partes interesadas clave con propuestas alternativas para la liberación.
6. Preparar el informe de finalización de las Pruebas de Aceptación del Usuario con recomendaciones.

Acciones posteriores a las Pruebas de Aceptación del Usuario

Las siguientes actividades deben llevarse a cabo tras la finalización de las UAT.

1. Diseño y plan de formación del usuario.
2. Soporte posterior a la liberación.
3. Pruebas continuas
4. Informe posterior a las pruebas de aceptación del usuario con las preguntas más frecuentes, etc.

Mejores prácticas de las pruebas de aceptación del usuario

Conocer a los usuarios que finalmente utilizarán el software

Conocer a su público objetivo. ¿Cuáles son sus problemas/necesidades? ¿Cuál es su motivación? ¿Cómo puede llegar a ellos? Cuando se tiene toda esta información antes de iniciar las Pruebas de Aceptación de Usuario, se ahorra el esfuerzo perdido y ayuda a obtener resultados dirigidos.

Preparar el plan de Pruebas de Aceptación de Usuario con mucha antelación

Por lo general, las Pruebas de Aceptación de Usuario se llevan a cabo antes del lanzamiento del software en el mercado y en esta etapa ya está bajo la presión de cumplir con los plazos y están entusiasmados con la respuesta del usuario final con respecto a su software, por lo tanto, la planificación de las Pruebas de Aceptación de Usuario en esta etapa podría resultar en perder algunos casos de uso de la vida real que son frecuentes. La disponibilidad de recursos también podría ser una limitación en esta etapa.

Sistema de gestión de Pruebas de Aceptación de Usuario bien estructurado

Un sistema de gestión de Pruebas de Aceptación de Usuario bien estructurado es aquel que contiene opciones de filtrado fáciles, informes eficientes, matriz de trazabilidad, características de seguimiento de errores y seguridad.

Crear Escenarios basados en los requisitos del negocio

Siempre es una buena práctica preparar escenarios de prueba basados en los requisitos del negocio con el fin de dirigirse al usuario final.

Defina claramente los criterios de aceptación

Si el producto se aprueba o fracasa después del desarrollo se decide por los criterios de aceptación por lo que es mejor definir los criterios de aceptación claramente.

Etapa en la que se realizan las pruebas de aceptación del usuario

Hay muchas formas de desarrollar un sistema pero a grandes rasgos se clasifican en 2 categorías:

1. Desarrollo secuencial
2. Desarrollo iterativo

Desarrollo secuencial

El desarrollo secuencial utiliza una secuencia de etapas de desarrollo que suelen seguir una forma de V. La UAT es el nivel de prueba final que comprueba el sistema completado con respecto a los requisitos del negocio.

Desarrollo iterativo

En un enfoque iterativo (como el desarrollo ágil), el diseño y las pruebas tienen lugar durante sprints cortos, por lo que la funcionalidad del sistema está disponible de forma incremental al final de cada sprint. La UAT será necesaria antes de desplegar cada sprint.

Enfoque de las pruebas de aceptación del usuario

El enfoque de la UAT se basa en 3 elementos:

1. Requisitos del negocio
2. Procesos del negocio
3. Expectativas del usuario

Debe haber un enfoque que siga estos 3 elementos.

Casos de prueba basados en los requisitos

Los casos de prueba deben cubrir los requisitos del negocio, cada caso de prueba debe estar vinculado a un requisito específico basado en un número de identificación. Los casos de prueba pueden escribirse poco después de que se defina la especificación de los requisitos y se denominan casos de prueba basados en los requisitos. La desventaja de este enfoque es que si los requisitos contienen errores entonces los casos de prueba también se equivocarían.

Casos de prueba basados en el proceso de negocio

Los casos de prueba basados en el proceso de negocio se escriben para asegurarse de que el sistema que se entrega funcionará específicamente en el apoyo a los procesos de negocio. Los casos de prueba deben ser capaces de mostrar que los requisitos se han cumplido de una manera que refleja cómo la organización va a utilizar el sistema.

Casos de prueba basados en la interfaz de usuario

Los casos de prueba basados en la interfaz de usuario se estructuran en torno a formularios o pantallas que deben ser completados. Los casos de prueba se basan en la entrada de datos, las interacciones a través de la pantalla y los informes. Los casos de prueba impulsados por la interfaz de usuario pueden ser incrustados dentro de los casos de prueba basados en el proceso de negocio donde el proceso de negocio implica la entrada de datos, la interacción o la presentación de informes.

Establecer prioridades a través de las Pruebas Basadas en Riesgos

Las pruebas de usuario se realizan generalmente con presión porque se hacen justo antes de que el sistema se libere a los usuarios finales para que lo utilicen, por lo que hay una necesidad de encontrar una manera de hacer lo mejor dentro del tiempo limitado disponible. Para ello, se utiliza la técnica de priorización para ejecutar primero las pruebas más importantes, de modo que cualquier prueba que quede incompleta sea menos importante que la que se complete. Esto se denomina prueba basada en el riesgo.

Se identifica el nivel de riesgo de cada requisito y los requisitos se clasifican por prioridad.La prueba basada en el riesgo puede utilizarse junto con otros enfoques.

Por ejemplo

La prueba basada en el riesgo podría incluirse dentro de la prueba basada en el requisito para garantizar que las áreas más importantes se prueben primero.

Si el sistema hace lo que se requiere aunque falte alguna parte detallada de la especificación técnica, entonces ese resultado debe informarse pero no es un ‘show-stopper’.

Por otro lado, si el sistema cumple con todos y cada uno de los elementos de la especificación técnica, pero es engorroso de usar, entonces es una causa de preocupación.

Ejemplos de Pruebas de Aceptación del Usuario

Cualquier software de cualquier dominio como el de la automoción, viajes/turismo, etc. debe pasar por las pruebas de aceptación del usuario adecuadas antes de la entrega a la producción.

Supongamos que hay un software de seguimiento móvil en el que un administrador administra los recursos móviles y es una aplicación basada en la web. Ha pasado por muchas formas diferentes de pruebas, como las pruebas funcionales, las pruebas de integración, las pruebas del sistema, las pruebas de rendimiento, etc. y ahora llega el turno del nivel más importante de las pruebas y es la prueba de aceptación del usuario. Idealmente, se debe realizar en dos niveles:

Pruebas Alfa

Este tipo de pruebas de aceptación del usuario se realiza por los probadores en el sitio de los desarrolladores para comprobar cualquier último problema antes de la entrega del software a los usuarios finales para las pruebas beta.

Pruebas beta

Las realizan los usuarios finales en sus instalaciones y comprueban cualquier problema antes de que el software se lance a la producción.

Conclusión

La ventaja de las pruebas de aceptación del usuario es que no habrá sorpresas cuando el producto se lance a la producción/mercado para su uso real.

Otros artículos populares:

• ¿Qué son las pruebas de aceptación o User Acceptance Testing (UAT)?
• ¿Qué es el Acceptance Test-Driven Development en la metodología ágil?
• ¿Qué son la Pirámide de Pruebas y los Cuadrantes de Pruebas en la Metodología Ágil de Pruebas?
• ¿Qué son los Productos de Trabajo del Proyecto en las Pruebas Ágiles?
• ¿Qué son las Pruebas de Casos de Uso en las Pruebas de Software?