Pruebas de Aceptación del Usuario (UAT)

Pruebas de Aceptación del Usuario (UAT)

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