prueba de aceptacion

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 queestá 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 completadosatisfactoriamente 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 logeneral, 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 usuarioEl 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 experienciapodemos 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 esteartí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 ciclode 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 cadaproducto 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 losrequisitos 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...