No importa cómo lo llames. Aquí está el resultado final: necesita probar el software con sus futuros usuarios.
Uno de los temas que genera mucha confusión en el mundo del software es la diferencia entre las pruebas de usabilidad (UT) y las pruebas de aceptación del usuario (UAT). Los profesionales de la experiencia del usuario (UX) solo se preocupan por las pruebas de usabilidad, mientras que los desarrolladores y el personal de preguntas y respuestas se centran en las pruebas de aceptación del usuario. Otras partes interesadas usan ambos términos indistintamente creyendo en el sentimiento de: «No importa cómo lo llames, siempre que probemos nuestro software con los usuarios».
De hecho, ambas pruebas involucran a usuarios finales que utilizan software con el objetivo de encontrar deficiencias. Sin embargo, las fallas que se identifican difieren y, por lo tanto, el propósito de por qué desea ejecutar cada prueba. Además, el momento en el que se realizan las pruebas también puede diferir según el proceso de desarrollo que se utilice. Así que tratemos de desenredar todo esto.
¿Qué hacen las pruebas?
Tanto en las pruebas de usabilidad como en las pruebas de aceptación del usuario, los usuarios finales interactúan con un producto y pasan por ciertos escenarios de prueba. Observar a los usuarios de prueba que tienen éxito o fallar en las tareas de prueba y escuchar sus comentarios sobre el producto en sí proporciona información sobre la calidad del producto.
UT se preocupa por comprender la experiencia del usuario que se manifiesta cuando un usuario interactúa con un producto o concepto. UX es un concepto integral que describe y mide la efectividad y la eficiencia objetivas y subjetivas de la interacción; es decir, hasta qué punto los usuarios pueden lograr los objetivos y cuánto esfuerzo deben realizar.
UX también incluye el impacto psicológico de la interacción usuario-producto. ¿Se percibe como cómodo, alegre, estresante, confuso o sencillo? Durante las pruebas de usabilidad se evalúan aspectos cualitativos y cuantitativos. Los aspectos cualitativos abarcan el sentimiento de los usuarios de prueba; sus comentarios y reacciones sobre el producto. Un ejemplo es un hallazgo «El usuario de prueba se sorprende cuando el botón ‘Cerrar’ guarda su configuración en la ventana modal». Los aspectos cuantitativos son hallazgos medibles, como tasas de éxito de tareas, tiempos de finalización de tareas, cantidad de errores de usuario cometidos durante la ejecución de tareas, etc. Por ejemplo, un hallazgo puede ser: “85% de los usuarios de prueba completaron la tarea de prueba n.º 1 en menos de 1 minuto. ”
UAT se preocupa por comprender si el producto hace lo que se supone que debe hacer y si su público objetivo de hecho puede lograr sus objetivos. En otras palabras: UAT verifica si el producto cumple con los requisitos comerciales definidos. Esto significa que las funciones correctas están integradas y que el código es impecable.
Por ejemplo, podemos probar si un sitio web de comercio electrónico permite a los usuarios agregar un artículo desde una página de detalles del producto al carrito de compras. El producto pasa la prueba si se cumplen los criterios de aceptación predeterminados. Por ejemplo: El usuario selecciona la cantidad deseada del producto; el usuario hace clic en el botón «agregar al carrito»; La página muestra un mensaje emergente «agregado al carrito». UAT considera los problemas de usabilidad que comentan los usuarios de prueba, pero la usabilidad en sí no se mide.
Pruebas de usabilidad |
¿Produce el producto una buena experiencia de usuario?
|
Pruebas de aceptación del usuario |
¿El producto es adecuado para el propósito?
|
Artículo relacionado: UX es una inversión continua para empresas rentables. Este es el por qué
¿Qué valor proporcionan las pruebas?
Como se mencionó anteriormente, ver cómo los usuarios reales de la demografía objetivo interactúan con el producto proporciona una comprensión imparcial y auténtica de la calidad del producto.
En la mayoría de los casos, las pruebas de usabilidad se utilizan de forma formativa: implican una revisión del producto para mitigar las deficiencias identificadas. La prueba es parte del proceso iterativo de diseño y desarrollo y garantiza que los defectos de usabilidad se descubran lo antes posible y se corrijan antes de que el producto se lance al mercado.
La función de las pruebas de aceptación del usuario, por otro lado, es verificar que el producto que se va a lanzar cumpla con el propósito establecido y que el código no tenga fallas, lo que permite a los usuarios objetivo trabajar con éxito con él. Brinda a la empresa que crea el producto un nivel de seguridad de que lo que está a punto de lanzar ofrece las capacidades para las que fue creado. Tradicionalmente, esta verificación ha ocurrido solo una vez y al final del proceso de desarrollo, un enfoque de prueba sumativa a menudo llamado «prueba beta». Como explicaré a continuación, esto ha cambiado en la era de los procesos de desarrollo ágil.
¿Cuándo realizar las pruebas?
El tipo de proceso de desarrollo que se utiliza para crear el producto tiene un impacto en el momento de las pruebas. Consideremos los procesos en cascada y ágiles.
Proceso de cascada
Para ayudar a dar forma a futuras iteraciones de diseño/desarrollo, la UT en un proceso en cascada, donde cada una de las fases de desarrollo (análisis, diseño, implementación y prueba) se realiza una tras otra, NO ocurre durante la fase de prueba regular. Sucede, en cambio, ya durante las fases de diseño y desarrollo. Debido a que el costo del cambio crece exponencialmente durante el proceso de desarrollo del producto, cuanto antes se pueda llevar a cabo la UT, mejor. Todo lo que se necesita es algo que pueda experimentar un usuario de prueba (más sobre eso más adelante).
UAT en cascada se lleva a cabo al final del proceso de desarrollo. No se hace para mejorar aún más el producto, sino para verificar que se han cumplido los requisitos comerciales y que el código es completamente funcional para permitir que los usuarios logren sus objetivos. Si la prueba revela que este no es el caso, entonces esto representa un desafío, porque el desarrollador debe retroceder en el proceso (para permanecer en la metáfora de la cascada: nadar contra la corriente) para mitigar los problemas en las etapas anteriores del proceso, lo cual es costoso. en términos de tiempo y recursos.
Proceso ágil
En ágil, donde un proyecto de desarrollo se divide en microproyectos llamados sprints, para cada fase de desarrollo del producto (análisis, diseño, implementación y prueba), tanto UT como UAT son principalmente parte de los sprints individuales. En la práctica, dado que los sprints suelen durar solo 2 semanas, puede ser un desafío ajustar las pruebas con los usuarios finales en el apretado cronograma. Es una opción realizarlos en una determinada cadencia como sprints propios, separados.
Curiosamente, cuando UAT se realiza dentro de Agile, es formativo en lugar de sumativo: ya no ocurre solo una vez al final, sino a lo largo del desarrollo del producto. Dado que ambas pruebas son formativas y brindan información que se utiliza para avanzar y optimizar el producto, se podría argumentar que son esencialmente lo mismo. Sin embargo, la diferencia en el alcance permanece: UT se enfoca únicamente en la experiencia del usuario, mientras que UAT se enfoca en el cumplimiento de los requisitos comerciales y el código impecable.
Artículo relacionado: La agilidad ya no es opcional en los negocios
¿Qué fidelidad de producto necesita para ejecutar cada prueba?
La fidelidad se refiere a qué tan real es el producto que se va a probar, desde un prototipo en papel hasta un producto completamente funcional con todas las características, funciones, apariencia y apariencia.
Una prueba de usabilidad requiere menos fidelidad que una prueba de aceptación del usuario. Las pruebas de prototipos en papel o simples maquetas de clics se realizan regularmente en UT. La fidelidad requerida depende de lo que desee probar la usabilidad: ¿es el diseño y la arquitectura de la información? Entonces, un prototipo en papel o un conjunto de imágenes estáticas está bien. ¿Son las micro-interacciones y animaciones? Entonces, probar algo estático no arrojaría buenos conocimientos.
Para realizar una prueba de aceptación del usuario, hay menos margen de maniobra: necesita ejecutar un software con código ejecutable, lo que permite que las personas de la demografía objetivo lleven a cabo los escenarios de prueba. En un proceso en cascada, esa falta de flexibilidad no significa que las etapas anteriores del proyecto de código no puedan y no puedan probarse.
Pero estas son pruebas diferentes; por ejemplo, pruebas unitarias (probar las partes más pequeñas de un producto individualmente) y pruebas de integración (probar las partes juntas como un sistema combinado). En Agile, a medida que realiza pruebas formativas, no todas las características y funciones que ofrecerá el producto final deben implementarse en el momento en que el usuario acepta las pruebas. Los únicos requeridos son aquellos en el alcance de los escenarios de prueba y criterios de aceptación.
¿Quién está orquestando las pruebas?
Tanto durante la UA como la UAT, el software bajo revisión está expuesto a los usuarios finales. Después de todo, son los clientes quienes determinan el éxito o el fracaso del producto. Una aplicación defectuosa o difícil de usar no ganaría terreno en el mercado, lo que dificultaría alcanzar los ingresos deseados. Las funciones corporativas que son responsables de planificar, ejecutar, analizar y reportar los resultados de las pruebas son diferentes para cada prueba.
Los UT son realizados por miembros del equipo de UX. Dependiendo de cómo se construya ese equipo, un investigador de usuarios o un probador de usabilidad es el responsable. Para evitar el sesgo de confirmación, la prueba no debe ser realizada por los propios diseñadores de UX.
Los UAT son ejecutados por el equipo de preguntas y respuestas o de prueba, que normalmente es un equipo separado tanto de UX como de desarrollo.
Artículo relacionado: Comprender el impacto que tiene el tratamiento del texto en la usabilidad y la experiencia del usuario
¿Se pueden combinar ambas pruebas?
¿No tendría sentido fusionar ambas pruebas en una sola? Esto puede ahorrar tiempo y dinero.
En el mundo de las cascadas esto no es posible, porque como se indicó anteriormente, ambas pruebas se llevan a cabo en diferentes puntos en el tiempo: UT como prueba formativa se ejecuta repetidamente y tan pronto como sea posible en el proceso de desarrollo, mientras que UAT es sumativa y siendo hecho una vez al final del proceso.
En Agile, donde ambas pruebas se usan formativamente, podrían combinarse en una, si ambas se basan en los mismos escenarios de prueba. Los usuarios de prueba llevarían a cabo estos escenarios de prueba y compartirían sus reacciones y sentimientos con el investigador de UX y la persona de preguntas y respuestas, quienes aún serían necesarios.
Espero que este artículo haya ayudado a explicar los puntos en común y las diferencias entre las pruebas de usabilidad y las pruebas de aceptación del usuario. Ambos tienen su lugar y relevancia, y no son lo mismo. Para responder a la pregunta en el título del artículo, no es un «o», sino un «y».