Qué es la prueba de aceptación del usuario (UAT): una guía completa

Aprenda qué es la prueba de aceptación del usuario (UAT) , Junto con su definición, tipos, pasos y ejemplos:

Mi regla número uno cuando trato de entender un nuevo concepto es que: el nombre siempre será relevante y principalmente un significado literal (en el contexto técnico).

Averiguar qué es eso me dará una comprensión inicial y me ayudará a comenzar.

= > Haga clic aquí para ver la serie completa de tutoriales del plan de prueba

Pongamos este concepto a prueba.

= > Lea todos los tutoriales de nuestra serie de pruebas de aceptación.

¿Qué son las pruebas de aceptación del usuario?

Sabemos qué es la prueba, aceptación significa aprobación o acuerdo. El usuario en el contexto de un producto de software es el consumidor del software o la persona que solicitó que se construyera para él (cliente).

Entonces, siguiendo mi regla, la definición será :

Prueba de aceptación del usuario (UAT), también conocida como prueba beta o de usuario final, se define como probar el software por parte del usuario o cliente para determinar si puede ser aceptado o no. Esta es la prueba final que se realiza una vez que se completan las pruebas funcionales, de sistema y de regresión.

El objetivo principal de esta prueba es validar el software frente a los requisitos comerciales. Esta validación la llevan a cabo los usuarios finales que están familiarizados con los requisitos comerciales.

Las pruebas UAT, alfa y beta son diferentes tipos de pruebas de aceptación.

Dado que la prueba de aceptación del usuario es la última prueba que se realiza antes de que el software entre en funcionamiento, obviamente esta es la última oportunidad para que el cliente pruebe el software y mida si es adecuado para el propósito.

¿Cuándo se realiza?

Este suele ser el último paso antes de que el producto entre en funcionamiento o antes de que se acepte la entrega del producto. Esto se realiza después de que el producto en sí se haya probado a fondo (es decir, después de la prueba del sistema).

¿Quién realiza UAT?

Usuarios o cliente: puede ser alguien que está comprando un producto ( en el caso de software comercial) o alguien que haya tenido un software personalizado a través de un proveedor de servicios de software o el usuario final si el software está disponible para ellos antes de tiempo y cuando se busca su retroalimentación.

El equipo puede estar compuesto por probadores beta o el cliente debe seleccionar a los miembros de UAT internamente de cada grupo de la organización para que todos y cada uno de los roles de usuario se puedan probar en consecuencia.

Necesidad de pruebas de aceptación del usuario

Los desarrolladores y probadores funcionales son personas técnicas que validan el software contra las especificaciones funcionales. Interpretan los requisitos de acuerdo con sus conocimientos y desarrollan / prueban el software (aquí está la importancia del conocimiento del dominio).

Este software está completo de acuerdo con las especificaciones funcionales, pero hay algunos requisitos y procesos comerciales que son conocidos solo por los usuarios finales, se pasan por alto para comunicarse o se malinterpretan.

Esta prueba juega un papel importante en la validación de si se cumplen o no todos los requisitos comerciales antes de lanzar el software para uso en el mercado. El uso de datos en vivo y casos de uso reales hacen de esta prueba una parte importante del ciclo de lanzamiento.

Muchas empresas que sufrieron grandes pérdidas debido a problemas posteriores al lanzamiento conocen la importancia de una prueba de aceptación del usuario exitosa. El costo de arreglar los defectos después del lanzamiento es muchas veces mayor que arreglarlo antes.

¿Es UAT realmente necesario?

Después de realizar muchas pruebas de sistema, integración y regresión, uno se preguntaría acerca de la necesidad de esta prueba. En realidad, esta es la fase más importante del proyecto, ya que es el momento en el que los usuarios que realmente van a utilizar el sistema validarán el sistema para que se ajuste a su propósito.

UAT es una prueba fase que depende en gran medida de la perspectiva de los usuarios finales y del conocimiento del dominio de un departamento que representa a los usuarios finales.

De hecho, sería realmente útil para los equipos comerciales, si participaron en el proyecto desde el principio, por lo que pueden proporcionar sus puntos de vista y contribuciones que ayudarían al uso eficaz del sistema en el mundo real.

Proceso de prueba de aceptación del usuario

El La forma más fácil de entender este proceso es pensar en esto como un proyecto de prueba autónomo, lo que significa que tendrá las fases de planificación, diseño y ejecución.

Los siguientes son los requisitos previos antes de la fase de planificación comienza:

# 1) Reúna los criterios de aceptación clave

En términos simples, los criterios de aceptación son una lista de estos ngs que serán evaluados antes de aceptar el producto.

Estos podrían ser de 2 tipos:

(i) Funcionalidad de la aplicación o relacionada con el negocio

Idealmente, todas las funciones clave del negocio deberían validarse, pero debido a Varias razones, incluido el tiempo, no es práctico hacerlo todo. Por lo tanto, una reunión o dos con el cliente o los usuarios que van a participar en esta prueba pueden darnos una idea de cuántas pruebas se van a involucrar y qué aspectos se van a probar.

(ii) Contractual – No vamos a entrar en esto y la participación del equipo de GC en todo esto es casi nada. El contrato inicial que se redacta incluso antes de que comience el SDLC se revisa y se llega a un acuerdo sobre si todos los aspectos del contrato se han entregado o no.

Nos centraremos solo en la funcionalidad de la aplicación .

# 2) Definir el alcance de la participación de QA.

La función del equipo de control de calidad es una de las siguientes:

(i) Sin participación: esto es muy raro.

(ii) Ayudar en esta prueba: la mayoría común. En este caso, nuestra participación podría ser capacitar a los usuarios de UAT sobre cómo usar la aplicación y estar en espera durante esta prueba para asegurarnos de que podemos ayudar a los usuarios en caso de cualquier dificultad. O en algunos casos, además de estar en espera y ayudar, podríamos compartir sus respuestas y registrar los resultados o registrar errores, etc., mientras los usuarios realizan las pruebas reales.

(iii) Realizar UAT y Presentar Resultados – Si este es el caso, los usuarios señalarán las áreas del AUT que desean evaluar y la evaluación en sí la realiza el equipo de GC. Una vez hecho esto, los resultados se presentan a los clientes / usuarios y estos tomarán una decisión sobre si los resultados que tienen en la mano son suficientes o no y de acuerdo con sus expectativas para aceptar la AUT. La decisión nunca es del equipo de control de calidad.

Dependiendo del caso en cuestión, decidimos qué enfoque es el mejor.

Los objetivos y expectativas principales:

Por lo general, la UAT es realizada por un experto en la materia (SME) y / o un usuario comercial, que puede ser el propietario o el cliente de un sistema bajo prueba. Similar a la fase de prueba del sistema, la fase UAT también abarca fases religiosas antes de que se cierre.

Las actividades clave de cada fase UAT se definen a continuación:

Gobernanza UAT

De manera similar a las pruebas del sistema, se aplica una gobernanza efectiva para UAT para garantizar que haya puertas de calidad sólidas junto con los criterios de entrada y salida definidos (que se proporcionan a continuación **).

** Tenga en cuenta que es solo una guía. Esto podría modificarse en función de las necesidades y requisitos del proyecto.

Planificación de pruebas de UAT

El proceso es casi el mismo que con el plan de pruebas regular en la fase del sistema.

El enfoque más común seguido en la mayoría de los proyectos es planificar las fases de prueba del sistema y UAT juntas. Para obtener más información sobre el plan de prueba de UAT junto con una muestra, consulte las secciones de UAT del documento del plan de prueba adjunto.

Plan de prueba de aceptación del usuario

(Este es el mismo que también puede encontrar en nuestro sitio la serie de capacitación de control de calidad).

Haga clic en la imagen de abajo y desplácese hacia abajo para encontrar la muestra del documento del plan de prueba en varios formatos. En esa plantilla, consulte la sección UAT.

Las fechas, el entorno, los actores (quiénes), los protocolos de comunicación, los roles y responsabilidades, las plantillas, los resultados y su proceso de análisis, los criterios de entrada y salida, todo esto y cualquier otra cosa que sea relevante se encontrará en el plan de prueba de UAT.

Ya sea que el equipo de control de calidad esté participando, participando parcialmente o no participando en absoluto en esta prueba, es nuestro trabajo planificar esta fase y asegúrese de que todo se tenga en cuenta.

= > Aquí hay un documento de muestra del plan de prueba de aceptación del usuario

Diseño de prueba de aceptación del usuario

En este paso se utilizan los criterios de aceptación recopilados por los usuarios. Las muestras podrían verse como se muestra a continuación.

(Estos son extractos de CSTE CBOK. Esta es una de las mejores referencias disponibles acerca de esta prueba).

Plantilla de prueba de aceptación del usuario:

Basándonos en los criterios, nosotros (el equipo de control de calidad) les damos a los usuarios una lista de casos de prueba de UAT. Estos casos de prueba no son diferentes de los casos de prueba de nuestro sistema habitual. Son solo un subconjunto, ya que probamos todas las aplicaciones en lugar de las áreas funcionales clave.

Además de estos, los datos, las plantillas para registrar los resultados de las pruebas, los procedimientos administrativos, el mecanismo de registro de defectos, etc., tiene que estar en su lugar antes de pasar a la siguiente fase.

Ejecución de la prueba

Por lo general, cuando es posible, esta prueba ocurre en una conferencia o en una sala de guerra, una especie de configurar el lugar donde los usuarios, PM, representantes del equipo de control de calidad se sientan juntos durante uno o dos días y trabajan en todos los casos de prueba de aceptación.

O en el caso de que el equipo de control de calidad realice las pruebas, ejecutamos la prueba casos en la AUT.

Una vez que se ejecutan todas las pruebas y los resultados están a la mano, se toma la decisión de aceptación. A esto también se le llama la decisión de ir / no ir. Si los usuarios están satisfechos, es un Go, o bien es un No-go.

Llegar a la decisión de aceptación suele ser el final de esta fase.

Herramientas & Metodologías

Normalmente, el tipo de herramientas de software que se utilizan durante esta fase de prueba es similar a las herramientas que se utilizan durante la realización de pruebas funcionales.

Herramientas:

Dado que esta fase implica la validación de los flujos completos de un extremo a otro de la aplicación, puede resultar difícil tener una herramienta para automatizar esta validación por completo. Sin embargo, hasta cierto punto, podríamos aprovechar los scripts automatizados desarrollados durante las pruebas del sistema.

De manera similar a las pruebas del sistema, los usuarios también utilizarían herramientas de gestión de pruebas y gestión de defectos como QC, JIRA, etc. Las herramientas se pueden configurar para acumular datos para la fase de aceptación del usuario.

Metodologías:

Aunque las metodologías convencionales, como usuarios comerciales específicos que realizan UAT del producto, siguen siendo relevantes, en un contexto verdaderamente global En el mundo como hoy, las pruebas de aceptación del usuario a veces tienen que involucrar a diversos clientes en todos los países según el producto.

Por ejemplo, los clientes de todo el mundo utilizarían un sitio web de comercio electrónico. En escenarios como este, las pruebas colectivas serían la mejor opción viable.

Las pruebas colectivas son una metodología en la que personas de todo el mundo pueden participar y validar el uso del producto y dar sugerencias y recomendaciones.

Las plataformas de pruebas colectivas están construidas y ahora están siendo utilizadas por muchas organizaciones. Un sitio web o un producto que necesita ser probado en masa se aloja en la plataforma y los clientes pueden nominarse ellos mismos para hacer la validación. Los comentarios proporcionados se analizan y priorizan.

La metodología de Crowd Testing está demostrando ser más eficaz, ya que se puede entender fácilmente el pulso del cliente en todo el mundo.

UAT en un entorno ágil

El entorno ágil es de naturaleza más dinámica. En un mundo ágil, los usuarios comerciales estarán involucrados a lo largo de los sprints del proyecto y el proyecto se mejorará en función de los ciclos de retroalimentación de ellos.

Al comienzo del proyecto, los usuarios comerciales serían las partes interesadas clave para proporcionar requisitos actualizando así la cartera de pedidos del producto. Durante el final de cada sprint, los usuarios comerciales participarían en la demostración del sprint y estarían disponibles para proporcionar comentarios.

Además, se planificaría una fase UAT antes de la finalización del sprint en la que los usuarios comerciales harían su validaciones.

Los comentarios que se reciben durante la demostración del sprint y el UAT del sprint se recopilan y se agregan a la cartera de pedidos del producto, que se revisa y prioriza constantemente. Así, en un mundo ágil, los usuarios empresariales están más cerca del proyecto y evalúan el mismo para su uso con mayor frecuencia a diferencia de los proyectos tradicionales en cascada.

Equipo UAT – Roles & Responsabilidades

Una organización UAT típica tendría los siguientes roles y responsabilidades. El equipo de UAT estaría apoyado por el director del proyecto, los equipos de desarrollo y pruebas en función de sus necesidades.

7 desafíos de UAT Y plan de mitigación

No importa si forma parte de una versión de mil millones de dólares o de un equipo de inicio, debe superar todos estos desafíos para ofrecer un software exitoso para el usuario final.

# 1) Proceso de configuración e implementación del entorno:

La realización de esta prueba en el mismo entorno utilizado por el equipo de pruebas funcionales ciertamente terminará pasando por alto los casos de uso del mundo real. Además, las actividades de prueba cruciales, como las pruebas de rendimiento, no se pueden llevar a cabo en un entorno de prueba con datos de prueba incompletos.

Se debe configurar un entorno de producción independiente para esta prueba.

Una vez que el entorno de UAT se separa del entorno de prueba, es necesario controlar el ciclo de lanzamiento de forma eficaz. El ciclo de lanzamiento incontrolado puede llevar a diferentes versiones de software en el entorno de prueba y UAT. Se pierde un valioso tiempo de prueba de aceptación cuando el software no se prueba con la última versión.

Mientras tanto, el tiempo requerido para el seguimiento de problemas en la versión de software incorrecta es alto.

# 2) Prueba Planificación:

Esta prueba debe planificarse con un plan de prueba de aceptación claro en la fase de diseño y análisis de requisitos.

En la planificación de la estrategia, se debe identificar el conjunto de casos de uso del mundo real para su ejecución. Es muy importante definir los objetivos de la prueba para esta prueba, ya que no es posible una ejecución completa de la prueba para aplicaciones grandes en esta fase de prueba. Las pruebas deben llevarse a cabo priorizando los objetivos comerciales críticos primero.

Estas pruebas se llevan a cabo al final del ciclo de pruebas. Obviamente, es el período más crítico para el lanzamiento del software. El retraso en cualquiera de las etapas anteriores de desarrollo y prueba consumirá el tiempo de UAT.

La planificación incorrecta de la prueba, en el peor de los casos, conduce a una superposición entre las pruebas del sistema y la UAT. Debido al menor tiempo y la presión para cumplir con los plazos, el software se implementa en este entorno incluso si no se completan las pruebas funcionales. Los objetivos principales de esta prueba no se pueden lograr en tales situaciones.

El plan de prueba UAT debe prepararse y comunicarse al equipo mucho antes de comenzar esta prueba. Esto les ayudará a planificar pruebas, escribir casos de prueba & scripts de prueba y crear un entorno UAT.

# 3) Manejo de nuevos requisitos comerciales como incidentes / defectos:

Las ambigüedades en los requisitos quedan atrapadas en la fase UAT. Los probadores de UAT encuentran problemas que surgen debido a requisitos ambiguos (al observar la IU completa que no estaba disponible durante la fase de recopilación de requisitos) y lo registran como un defecto.

El cliente espera que se corrijan en la versión actual sin considerar el tiempo para las solicitudes de cambio. Si la dirección del proyecto no toma una decisión oportuna sobre estos cambios de última hora, esto podría provocar la falla de la versión.

# 4) Probadores no calificados o probadores sin conocimientos comerciales:

Cuando no hay un equipo permanente, la empresa selecciona al personal de la UAT de varios departamentos internos.

Incluso si el personal está bien familiarizado con las necesidades del negocio, o si no está capacitado para los nuevos requisitos que en desarrollo, no pueden realizar UAT eficaz. Además, un equipo de negocios no técnico puede enfrentar muchas dificultades técnicas al ejecutar los casos de prueba.

Mientras tanto, la asignación de probadores al final del ciclo de UAT no agrega ningún valor al proyecto. Poco tiempo para capacitar al personal de UAT puede aumentar significativamente las posibilidades de éxito de UAT.

# 5) Canal de comunicación inadecuado:

La comunicación entre el desarrollo remoto, las pruebas y el equipo de UAT es más difícil . La comunicación por correo electrónico suele ser muy difícil cuando se cuenta con un equipo técnico en el extranjero. Una pequeña ambigüedad en los informes de incidentes puede retrasar su solución por un día.

La planificación adecuada y la comunicación eficaz son fundamentales para la colaboración eficaz del equipo. Los equipos de proyecto deben usar una herramienta basada en web para registrar defectos y preguntas. Esto ayudará a distribuir la carga de trabajo de manera uniforme y evitará informar problemas duplicados.

# 6) Solicitar al equipo de prueba funcional que realice esta prueba:

No hay peor situación que solicitar la prueba funcional equipo para realizar UAT.

Los clientes descargan su responsabilidad al equipo de prueba debido a la falta de recursos. Todo el propósito de esta prueba se ve comprometido en tales casos. Una vez que el software entre en funcionamiento, los usuarios finales detectarán rápidamente los problemas que los evaluadores funcionales no consideran escenarios del mundo real.

Una solución para esto es asignar estas pruebas a los expertos y dedicados probadores con conocimientos de negocios.

# 7) El juego de la culpa

A veces, los usuarios comerciales simplemente intentan encontrar razones para rechazar el software. Podría ser su propio dominio para mostrar cuán superiores son o culpar al equipo de desarrollo y pruebas para obtener respeto en el equipo de negocios. Esto es muy raro, pero ocurre en equipos con política interna.

Es muy difícil lidiar con este tipo de situaciones. Sin embargo, construir una relación positiva con el equipo empresarial definitivamente ayudaría a evitar el juego de la culpa.

Espero que estas pautas sin duda lo ayuden a ejecutar un plan de aceptación de usuarios exitoso al superar varios desafíos. La planificación adecuada, la comunicación, la ejecución y el equipo motivado son las claves para el éxito de las pruebas de aceptación del usuario.

Pruebas del sistema frente a las pruebas de aceptación del usuario

La participación del equipo de pruebas comienza bastante temprano en el proyecto desde la fase de análisis de requisitos.

Durante todo el ciclo de vida del proyecto, se realiza algún tipo de validación para el proyecto, es decir, pruebas estáticas, pruebas unitarias, pruebas del sistema, pruebas de integración, pruebas de un extremo a otro o pruebas de regresión. Esto nos permite comprender mejor las pruebas realizadas en la fase UAT y cuán diferente es de las otras pruebas realizadas anteriormente.

Aunque vemos las diferencias en SIT y UAT, es importante que aprovechemos las sinergias pero aún mantener la independencia entre ambas fases, lo que permitiría un tiempo de comercialización más rápido.

Conclusión

# 1) UAT no se trata de páginas, campos o botones. La suposición subyacente incluso antes de que comience esta prueba es que todas esas cosas básicas se prueban y funcionan bien. Dios no lo quiera, los usuarios encuentran un error tan básico como ese: es una muy mala noticia para el equipo de control de calidad. 🙁

# 2) Esta prueba es sobre la entidad que es el elemento principal en el negocio.

Permítame darle un ejemplo: si el AUT es un sistema de emisión de boletos, el UAT no se va a tratar, buscar el menú que abre una página, etc. Se trata de los tickets y su reserva, los estados que puede tomar, su recorrido por el sistema, etc.

Otro ejemplo, si el sitio es un sitio de concesionario de automóviles, entonces la atención se centra en el «automóvil y sus ventas» y no realmente en el sitio. Por lo tanto, el negocio principal es lo que se verifica y valida y quién es mejor para hacerlo que el propietarios de negocios. Es por eso que esta prueba tiene más sentido cuando el cliente está involucrado en gran medida.

# 3) UAT también es una forma de prueba en su esencia, lo que significa que hay una buena posibilidad de identificando algunos errores en esta fase también. A veces sucede. Aparte del hecho de que es una escalada importante en el equipo de QA, los errores de UAT generalmente significan una reunión para sentarse y discutir cómo manejarlos como sigue Al realizar esta prueba, generalmente no hay tiempo para corregir y volver a probar.

La decisión sería:

• Presionar la fecha de inicio, solucionar el problema primero y luego siga adelante.
• Deje el error como está.
• Considérelo como parte de la solicitud de cambio para versiones futuras.

# 4) UAT se clasifica como prueba Alfa y Beta, pero esa clasificación no es tan importante en el contexto de los proyectos típicos de desarrollo de software en una industria basada en servicios.

• Las pruebas alfa son cuando UAT se lleva a cabo en el entorno del constructor de software y es más importante en el contexto de comercial listo para usar. software.
• La prueba beta es cuando la UAT se lleva a cabo en el entorno de producción o en el entorno del cliente. Esto es más común para las aplicaciones orientadas al cliente. Los usuarios aquí son los clientes reales como usted y yo en este contexto.

# 5) La mayoría de las veces en un proyecto de desarrollo de software regular, UAT se lleva a cabo en el entorno de QA si hay no es un entorno de prueba o UAT.

En resumen, la mejor manera de averiguar si su producto es aceptable y adecuado para su propósito es ponerlo frente a los usuarios.

Las organizaciones están adoptando la forma ágil de entregar, los usuarios comerciales se están involucrando más y los proyectos se están mejorando y entregando a través de circuitos de retroalimentación. Una vez hecho todo, la fase de aceptación del usuario se considera la puerta para entrar en la implementación y la producción.

¿Cuál fue su experiencia con UAT? ¿Estabas en espera o realizaste una prueba para tus usuarios? ¿Los usuarios encontraron algún problema? En caso afirmativo, ¿cómo los trató?

= > Lea también TODOS los tutoriales de esta serie aquí

= > Visite aquí para ver la serie completa de tutoriales del plan de prueba