En este último nivel, las pruebas de aceptación, nos volvemos a enfocar en el comportamiento de todo el sistema de información. Deseamos validar el producto desde el punto de vista del cliente, para avanzar con el lanzamiento a producción, o sencillamente verificar que el producto recibido es correcto.
A continuación detallo una serie de elementos: los objetivos, las formas de pruebas, la base, los objetos, los defectos y fallos típicos, y por último el enfoque y las responsabilidades específicas. Estos datos definen este último nivel.
Índice de contenidos
Objetivos de las pruebas de aceptación
Queremos crear confianza en la calidad de todo el sistema, validando que el sistema está completo y que funcionará como se ha definido. Por ello, hay que verificar que los comportamientos tanto funcionales, como no funcionales son los especificados en su definición y que por tanto está preparado para su utilización por el usuario final.
Es común detectar algunos defectos durante estas pruebas, pero nada significativo. Si el número de fallas es considerable, podría considerarse un riesgo para el proyecto.
Las formas más comunes de las pruebas
Existen cuatro tipos o formas de pruebas de aceptación.
PAU: Pruebas de aceptación del usuario
Este tipo de pruebas son realizadas por el usuario en un entorno real o simulado. Nos centraremos en la validación del sistema para su uso. Nuestro producto debe cumplir las necesidades del usuario de forma fácil e intuitiva y suponiendo un coste y riesgo mínimos.
PAO: Pruebas de aceptación operativa
Este tipo de pruebas son llevadas a cabo en un entorno simulado de producción, por el personal de administración de sistemas u operaciones.
Se van a probar el conjunto de acciones, que se llevarán a cabo de forma diaria o puntual, como con: pruebas de copias de seguridad y restauración, y recuperación de desastres. Probaremos la instalación, desinstalación y actualizaciones, realizaremos tareas de mantenimiento o pruebas de rendimiento. Además testearemos la gestión de los usuarios, la carga de datos y tareas de migración, y comprobaciones de vulnerabilidades de seguridad.
Pruebas de aceptación contractuales y regulatorias
Tanto las pruebas regulatorias, como las contractuales suelen realizarse por usuarios o probadores independientes. En las primeras, se prueba el cumplimiento de reglamentaciones gubernamentales, legales o de seguridad. Las agencias reguladoras presenciarán o auditarán estos resultados de forma frecuente.
En las segundas, aseguramos el cumplimiento de los criterios de aceptación definidos previamente en el contrato de software desarrollado a medida.
Pruebas alfa y beta
Este conjunto de pruebas son realizadas por clientes, usuarios y operadores potenciales para obtener comentarios del producto, y generar confianza en el sistema. También posibilita la detección de defectos debido a su utilización en otros entornos.
Las pruebas alfa, son realizadas en la propia organización, mientras que las pruebas beta se realizan en las instalaciones de los clientes u operadores.
Base de las pruebas, nuestras herramientas para trabajar
Para el desarrollo del plan de pruebas en este nivel, podemos utilizar los productos de trabajo: requisitos, casos de uso, procesos de negocio, regulaciones, contratos legales y normas. Es frecuente usar además, la documentación tanto del sistema, como del usuario, procedimientos de instalación, informes de análisis de riesgos.
Como base para derivar casos de prueba de aceptación operacional, se puede utilizar los productos de trabajo siguientes: procedimientos de copias de seguridad y restauración, o de recuperación de desastres. Se utilizan los requisitos no funcionales, documentación de operaciones, objetivos de rendimientos y normas o reglamentos de seguridad. También es frecuente la utilización de instrucciones de despliegue e instalación y paquetes de base de datos.
Objeto a asegurar su calidad
En este nivel, nos centramos en testear el sistema en sí, centrándonos en la configuración y los datos de configuración del mismo. Verificamos que los procesos de negocio sean correcto para un sistema completamente integrado. Es necesario asegurar la calidad de los procesos operacionales y de mantenimiento, formularios, informes y datos de producción existentes y controvertidos.
Es importante destacar la validación del sistema de recuperación y sitios activos (Plan de pruebas de continuidad y recuperación de desastres).
Defectos y fallas frecuentes en el último nivel
En este nivel se suelen detectar incidencias en flujos de trabajo que no cumplen con los requerimientos del proyecto o reglas comerciales que no están implementadas de forma correcta. Los testes suelen detectar que no se cumple requisitos reglamentarios o contractuales del sistema de información ó fallos funcionales no especificados literalmente. Algunos ejemplos son: rendimiento inadecuado, vulnerabilidades de seguridad u operación incorrecta con plataforma compatible.
Enfoques y responsabilidades específicas de las pruebas de aceptación
Los clientes o propietarios del producto, son los encargados de llevar este conjunto de pruebas. Aunque también las suelen realizan usuarios comerciales, operadores de sistemas u otras partes interesadas.
Estas pruebas son consideradas las pruebas del final del ciclo de vida del desarrollo de software, pero en otras ocasiones se realizan de forma previa a las pruebas de sistemas. Además en los desarrollos iterativos, este conjunto de pruebas puede darse al final de cada iteración, después de finalizar cada una de las iteraciones o después de un conjunto de iteraciones.
Conclusión
Para la aceptación de un sistema de información se debe revisar exhaustivamente cada uno de los elementos, flujos, funciones, normas, etc que se han definido. Además es muy recomendable que sea revisado por distintos usuarios, con enfoques diferentes para cubrir un mayor número de opciones.
Con la verificación en este nivel se cierra el ciclo de desarrollo del software. Si nuestro producto pasa las pruebas de forma satisfactoria, podemos estar seguros de que su calidad es muy alta. Pero recuerda, que ningún plan de pruebas es perfecto, y siempre hay algún detalle que puede escapar a los planes más detallados.
Si te gustó este post, suscríbete a las novedades, o déjame un comentario.
