Pruebas de Aceptación del Usuario (UAT) Autor: Norberto Figuerola
Después de toda la planificación, diseño, reuniones, revisiones de control y las pruebas internas, solo queda un acto final antes de que el comprador (o el cliente interno) acepte el software o solución desarrollada. El equipo ha trabajado meses en tratar de perfeccionar su labor, pero la verdadera prueba para decir que está listo, es cuando se efectúa la prueba de aceptación con los usuarios reales del sistema. Desde el punto de vista del PMBOK® las UAT equivalen al proceso de “Verificar el Alcance” dado que consisten en formalizar la aceptación de los entregables del proyecto que se han completado. Verificar el alcance incluye revisar los entregables con el cliente para asegurarse de que se han completado satisfactoriamente y para obtener de ellos su aceptación formal. Como siempre se indica la verificación del alcance difiere del control de calidad en que mientras la primera corresponde principalmente a la aceptación de los entregables, el segundo se refiere sobre todo a corroborar la exactitud de los entregables y su cumplimiento con los requisitos de calidad especificados para los entregables. Por lo general, el control de calidad se lleva a cabo antes de la verificación del alcance. Antes de dar algunos consejos en base a la experiencia de varios proyectos y conforme lo ratifica mucha bibliografía, repasemos cuales son las malas estrategias en lo que se refiere a las pruebas de aceptación del usuario
Esperar hasta el fin del desarrollo para ponerse a pensar sobre las pruebas de usuario El plan de pruebas del usuario debe comenzar temprano, esto es, desde el inicio del proyecto, por lo que deben ser correctamente planificadas en el cronograma. No sea víctima de la estrategia de "vamos a confiar en los resultados de las pruebas del sistema y pasar por alto las pruebas con usuarios, asi nos ponemos al día con un cronograma retrasado." Aquellos de nosotros con años de experiencia podemos decir que el aplicativo se construye con las pruebas y seguramente con los usuarios reales, si deseamos que el sistema funcione en el entorno de producción. No dejar que pase mucho tiempo para comenzar con las pruebas de usuario Uno puede darse cuenta tarde de la cantidad enorme de pruebas que deben pasar por el OK del usuario final. Adjuntamos a este artículo un informe de Sentry sobre lecciones
aprendidas de UAT. Dentro del white paper ponen como ejemplo que suponiendo que se tienen 120 elementos de prueba tales como la producción de un informe específico o 10 lotes de 30 documentos cada uno en una base de datos o generar un archivo de exportación de 600.000 registros, y asumiendo que toma aproximadamente 3 horas la configuración de cada ciclo de prueba; el tiempo de instalación, pruebas, recoger datos y analizarlos es de aproximadamente 360 horas. Entonces, ¿cómo lograr hacer esto dentro del cronograma? Los que lo hacen se encontrarán con una gran cantidad de problemas del mundo real y mucho re-trabajo incluso después de la implementación. Los requisitos de prueba de cada proyecto son diferentes de cualquier otro, porque cada producto y la situación son únicos. El punto es que las pruebas de usuario para que sean válidas y útiles requieren de tiempo y planificación. Por dicho motivo es común a veces incluír a los usuarios desde el principio en la planificación de lo que los criterios de prueba y aceptación van a utilizar.
Consejos sobre las pruebas de aceptación de los usuarios 1. Incluya las pruebas de usuario en los requisitos de la propuesta original, el plan, el costo y el cronograma. Utilice todo el input de sus analistas de negocios o equipo del proyecto (que incluya a representantes de los clientes), para generar escenarios típicos y los guiones para las pruebas de usuario. 2. Crear un plan detallado de lo que la UAT está poniendo a prueba. Las pruebas de usuario se deben hacer sobre la base de los requisitos acordados, y no todo lo que un usuario desee que el sistema haga. En otras palabras, limitar el alcance de las pruebas para estar en línea con la solución. 3. Seleccione los usuarios que efectuaran las pruebas, con un amplio rango de experiencia y diversidad de orígenes, y que sigan los scripts predefinidos para obtener desde el principio un buen feedback. No seleccionar a todos los novatos o sólo a los usuarios con experiencia, sino que una buena mezcla es lo mejor. 4. Entrene a los usuarios sobre como informar los problemas. Explique a los usuarios que es frecuente que digan simplemente "no funciona", y que eso hace que los desarrolladores no sean capaces de arreglar un problema descrito así tan genéricamente. Si trabaja con muchos usuarios sin experiencia probablemente sea importante filtrar los errores reportados antes de asignarlos a los desarrolladores. Comprobar que pueden recrearse los errores y eliminar errores duplicados antes de asignarlos a los desarrolladores. Si no se puede recrear un fallo basado en las instrucciones, reasignarlo al usuario que lo reportó y pedir más detalles. Otra forma eficiente de trabajo es solicitar a los usuarios que hagan las siguientes actividades antes de escribir el informe de fallas:
1. Registrar el error tan claramente como sea posible y asignarlo a otro usuario o a sí mismo. 2. Esperar 5 horas. 3. Tratar de recrear el error con sólo la información que escribió. 4. Si el mismo usuario u otro es capaz de recrear el error, pasar el informe, de lo contrario, volver al paso 1. Sugerirle a los probadores que anoten los pasos que siguieron y que llevaron al fracaso. Luego, esperar un par de horas y tratar de seguir los pasos como los escribieron para ver si el error vuelve a aparecer. Enseñarle a los probadores a encontrar errores y reportarlos con el suficiente detalle como para que los desarrolladores puedan repararlos. Utilizar alguna herramienta si es posible que haga más fácil la tarea, incluso una lista de SharePoint se puede utilizar para rastrear los artículos que salen de la UAT. 5. Mantener informes detallados de las pruebas, incluidos los procedimientos y resultados. Comunicar los resultados al equipo de gestión y los clientes. Dependiendo del momento de la UAT, es posible que desee presentar informes sobre la situación diaria o semanal. Además de un superficial paso/no paso, añadir un poco de información analítica sobre las causas o elementos comunes. Recuerde que las pruebas de usuario tratan de demostrar que el sistema hace lo que el cliente afirmó que necesitaba para hacer su trabajo. Si con las especificaciones y los planes anteriores todas las partes involucradas estuvieron de acuerdo, y a pesar de eso el producto resultante no es compatible con las necesidades del usuario, documente cuáles son las necesidades y el porqué, y comience el proceso de negociación y seguimiento del contrato.
Mejores prácticas y lecciones aprendidas Con el tiempo uno va adquiriendo más experiencia, pero mientras tanto cometemos toda clase de errores, desde recortar o limitar las UAT, hasta permitir a los usuarios testear cosas que no estaban incluídas en los requerimientos y alcance iniciales. Un par de lecciones aprendidas que espero resulten útiles: 1. Conseguir que el cliente / los actores involucrados estén desde el comienzo para definir en qué consistirá el análisis y la aceptación.
2. Balancear la formalidad de la UAT con el alcance y la duración del proyecto y la solución. He visto demasiada formalidad para el desarrollo de un pequeño sistema y no el mismo rigor para una solución de gran escala para cientos de usuarios. 3. Motivar y dar empuje emocional a las pruebas de usuario o UAT y no comenzarlas con negatividad. Si se ha hecho lo mejor que se pudo incluyendo la obtención de los usuarios para la definición de las mismas, entonces este es un momento emocionante en el que pueden probar el sistema recién terminado. Hacer que los usuarios sientan este tipo de pruebas como conducir un coche nuevo recién adquirido para probarlo antes que los demás.
Está prohibida la difusión, transmisión, modificación, copia, reproducción y/o distribución total o parcial del presente Documento, en cualquier forma y por cualquier medio, sin la previa autorización escrita del autor, encontrándose protegidos por las Leyes de Derecho de Autor, Marcas, Lealtad Comercial, Bases de Datos y otras normas Asimismo, queda prohibido cualquier uso de los Documentos o parte de los mismos con fines comerciales. La violación de los derechos antes señalados puede acarrear condenas civiles y/o penales establecidas en las normas precedentemente citadas. Se exigirán responsabilidades a los infractores por todas las vías disponibles en derecho. Fecha y lugar de publicación: Buenos Aires, Noviembre de 2011. Queda hecho el depósito que establece la Ley 11.723