El plan de pruebas de software se elabora para atender los objetivos de calidad en un desarrollo de sistemas, encargándose de definir aspectos como por ejemplo los módulos o funcionalidades sujeto de verificación, tipos de pruebas, entornos, recursos asignados, entre otros aspectos.
Aquí te compartimos un método para documentar las diferentes secciones del plan de pruebas de software, incluyendo el alcance, estrategia de pruebas, tipos de pruebas de software a incluir, criterios de aceptación, requisitos de infraestructura, requisitos de personal y la planificación.
Analizar los requerimientos de desarrollo de software
Para elaborar un plan de pruebas de software lo primero que debes hacer es entender los requerimientos de usuario que componen la iteración o proyecto, que son el sujeto de la verificación de calidad que se va a realizar.
Deberás analizar toda la información de la ingeniería de requisitos, incluyendo la matriz de trazabilidad, especificaciones y diseño funcional, requisitos no funcionales, casos de uso, historias de usuario (si estás trabajando con metodologías ágiles), entre otra documentación.
También es muy importante realizar entrevistas con el equipo encargado de la ingeniería de requisitos para aclarar dudas y ampliar la información que sea necesaria.
Identificar las funcionalidades nuevas a probar
A partir de la documentación del análisis de requisitos y de las entrevistas con el equipo de ingeniería de requisito y desarrollo, debes identificar e incluir en el plan de pruebas de software en la lista de las funcionalidades.
Si estás trabajando con un sistema informático nuevo, no tendrás problemas en discernir, pues todas serán nuevas.
En el caso de desarrollos de software integrados a un sistema existente es necesario revisar con los analistas de negocio y también con los arquitectos de software las funcionalidades que forman parte del desarrollo de software, en todas las capas de la arquitectura.
Identificar las funcionalidades de sistemas existentes que deben probarse
Se debe identificar las funcionalidades existentes que estén siendo impactadas por el desarrollo de alguna forma, considerando todos los componentes afectados en todas las capas de la arquitectura de software.
Existen dos situaciones que se puede encontrar al identificar estas funcionalidades:
Funcionalidades modificadas de cara al usuario: Por ejemplo, si una funcionalidad está siendo modificada agregando más pantallas o cambios a su flujo de proceso, debe ser incluida en el plan de pruebas de software.
Funcionalidades modificadas en sus componentes internos: Son funcionalidades no modificadas de cara al usuario, manteniendo la misma interfaz gráfica y flujo de procesos, sin embargo, si se modifican componentes internos que comparten con otras funcionalidades del sistema, en las capas de lógica de negocio o acceso a datos. Estas deben incluirse en el plan de pruebas de software para determinar a partir de ellas pruebas de regresión a realizar.
Quienes pueden suministrar la información serán los Analistas de negocio o Arquitectos de software, familiarizados con el sistema informático implementado en entorno de producción.
Definir la estrategia de pruebas
Consiste básicamente en seleccionar cuáles son los tipos de pruebas de software que se deben realizar.
Es recomendable seguir un marco de referencia para determinar los tipos de prueba, como por ejemplo los tipos de pruebas de software definidos por el ISTQB.
Definir os criterios de inicio, aceptación y suspensión de pruebas
Criterios de aceptación o rechazo:
Para definir los criterios de aceptación o rechazo, es necesario definir el nivel de tolerancia a fallos de calidad. Si la tolerancia a fallos es muy baja puede definirse como criterio de aceptación que el 100% de los casos de prueba estén sin incidencias. Lograr este margen en todos los casos de prueba principales y casos bordes será muy difícil, y podría comprometer los plazos del proyecto (incrementa los riesgos), pero asegura la calidad del producto.
Por otra parte, puede ser que la intención sea realizar un Soft Launch, o un mínimo producto viable, en ese caso se podría definir como criterio de aceptación el 100% de los casos de prueba principales (considerados clave) y 20% de casos de prueba no principales (casos borde).
Una vez logradas las condiciones, se darán por aceptadas las pruebas y el desarrollo de software.
Criterios de inicio o reanudación:
Definen las condiciones que deben cumplirse para dar inicio o reanudar las pruebas. Por ejemplo, en el caso de inicio la condición podría ser la instalación de los componentes de software en el ambiente y que los casos de pruebas de verificación de ambiente sean exitosos.
Para el caso de la reanudación las condiciones están relacionadas, se determina a partir de cuales criterios de suspensión se presentaron para detener las pruebas. Una vez que estás condiciones ya no existan (sean solventadas) se procede con la reanudación.
Criterios de suspensión:
Las condiciones van a depender de los acuerdos de nivel de servicio (SLAs) internos de la organización y también de los acuerdos establecidos en cada proyecto individual.
Por ejemplo, si se tiene un equipo de pruebas que comparte su esfuerzo entre varios proyectos, se puede definir un criterio de suspensión exigente, un determinado porcentaje de casos fallidos que resulten en incidencias. Si la condición se cumple, se detienen las pruebas y se dedica el personal a otras actividades,
Por otra parte, si se tiene un equipo de pruebas con personal dedicado, el criterio de suspensión puede ser poco exigente, por ejemplo solo ocurriendo si se bloquean por incidencia todos los casos de prueba.
