Pruebas de Aceptacin del Usuario (UAT)

Autor: Norberto Figuerola

Despus de toda la planificacin, diseo, 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 solucin desarrollada. El equipo ha trabajado meses en tratar de perfeccionar su
labor, pero la verdadera prueba para decir que est listo, es cuando se efecta la prueba de
aceptacin 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 aceptacin 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
aceptacin formal. Como siempre se indica la verificacin del alcance difiere del control de
calidad en que mientras la primera corresponde principalmente a la aceptacin 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 verificacin del alcance.

Antes de dar algunos consejos en base a la experiencia de varios proyectos y conforme lo
ratifica mucha bibliografa, repasemos cuales son las malas estrategias en lo que se refiere a
las pruebas de aceptacin 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
vctima 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 da con un cronograma
retrasado." Aquellos de nosotros con aos 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 produccin.

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 artculo 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 produccin de un informe especfico o 10
lotes de 30 documentos cada uno en una base de datos o generar un archivo de exportacin
de 600.000 registros, y asumiendo que toma aproximadamente 3 horas la configuracin de
cada ciclo de prueba; el tiempo de instalacin, pruebas, recoger datos y analizarlos es de
aproximadamente 360 horas. Entonces, cmo lograr hacer esto dentro del cronograma?
Los que lo hacen se encontrarn con una gran cantidad de problemas del mundo real y
mucho re-trabajo incluso despus de la implementacin.
Los requisitos de prueba de cada proyecto son diferentes de cualquier otro, porque cada
producto y la situacin son nicos. El punto es que las pruebas de usuario para que sean
vlidas y tiles requieren de tiempo y planificacin. Por dicho motivo es comn a veces
inclur a los usuarios desde el principio en la planificacin de lo que los criterios de prueba
y aceptacin van a utilizar.

Consejos sobre las pruebas de aceptacin 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 tpicos 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 lnea con la solucin.
3. Seleccione los usuarios que efectuaran las pruebas, con un amplio rango de experiencia y
diversidad de orgenes, y que sigan los scripts predefinidos para obtener desde el principio
un buen feedback. No seleccionar a todos los novatos o slo 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 genricamente. 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 ms
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 slo la informacin 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. Ensearle 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 ms fcil la tarea, incluso una lista de SharePoint se
puede utilizar para rastrear los artculos que salen de la UAT.
5. Mantener informes detallados de las pruebas, incluidos los procedimientos y resultados.
Comunicar los resultados al equipo de gestin y los clientes. Dependiendo del momento de
la UAT, es posible que desee presentar informes sobre la situacin diaria o semanal.
Adems de un superficial paso/no paso, aadir un poco de informacin analtica 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 cules son las
necesidades y el porqu, y comience el proceso de negociacin y seguimiento del contrato.

Mejores prcticas y lecciones aprendidas
Con el tiempo uno va adquiriendo ms 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 includas en los requerimientos y alcance iniciales. Un par de lecciones
aprendidas que espero resulten tiles:
1. Conseguir que el cliente / los actores involucrados estn desde el comienzo para definir
en qu consistir el anlisis y la aceptacin.
2. Balancear la formalidad de la UAT con el alcance y la duracin del proyecto y la
solucin. He visto demasiada formalidad para el desarrollo de un pequeo sistema y no el
mismo rigor para una solucin 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 obtencin de los usuarios
para la definicin de las mismas, entonces este es un momento emocionante en el que
pueden probar el sistema recin terminado. Hacer que los usuarios sientan este tipo de
pruebas como conducir un coche nuevo recin adquirido para probarlo antes que los dems.















Est prohibida la difusin, transmisin, modificacin, copia, reproduccin y/o distribucin
total o parcial del presente Documento, en cualquier forma y por cualquier medio, sin la
previa autorizacin escrita del autor, encontrndose 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 violacin de los derechos antes sealados puede acarrear condenas civiles y/o penales
establecidas en las normas precedentemente citadas. Se exigirn responsabilidades a los
infractores por todas las vas disponibles en derecho. Fecha y lugar de publicacin:
Buenos Aires, Noviembre de 2011. Queda hecho el depsito que establece la Ley 11.723