¿Qué contenido se debe incluir en una estrategia de pruebas? (I)

Todos los indicadores e informes señalan el crecimiento del sector de la calidad del software año tras año y la importancia que las compañías se toman en que sus aplicaciones tengan un proceso de pruebas.

Desde que inicié mi experiencia profesional en este sector, hace ya más de 10 años, observo que una parte muy importante del proceso no ha evolucionado de la misma manera ni se le presta la debida atención que merece. Estoy hablando de la estrategia de pruebas.

La estrategia de pruebas presenta, principalmente, los siguientes objetivos:

• Indicar los niveles y tipos de pruebas que se van a realizar en la aplicación.
• Detallar los módulos/componentes/funcionalidades, así como la cobertura de pruebas a aplicar en cada uno de ellos.
• Señalar las partes de la aplicación que no entran en la ejecución del proyecto.
• Indicar los posibles riesgos del proyecto y las acciones para mitigarlos.
• Planificación, personal y recursos (software, hardware) del proceso de aseguramiento de la calidad.

Toda estrategia de pruebas debe incluir, como mínimo, la siguiente información acerca del proyecto de calidad del software que cubre:

1. Elementos/módulos a probar.
2. Funcionalidad no cubierta.
3. Riesgos (identificación, evaluación y mitigación).
4. Criterios de suspensión de las pruebas y requisitos para la reanudación.
5. Enfoque (estrategia) de pruebas.
6. Planificación, componentes del proyecto y recursos (software y hardware).

A continuación vamos a tratar cada uno de los principales puntos indicados anteriormente.

1.Elementos/módulos a probar

Lista de funcionalidad/áreas/módulos que van a ser probados de forma que se garantice la calidad final del producto cumpliendo con las exigencias fijadas por la compañía propietaria del producto.

En este punto se indica el grado de cobertura que se va a aplicar a cada una de las partes y, además, el tipo de prueba/s que le aplica.

Existen diferentes tipos de pruebas a poder ser ejecutadas en cada uno de los módulos. Cabe destacar las mostradas a continuación:

• Funcionales manuales.
• Funcionales automáticas.
• Exploratorias.
• Rendimiento, carga y estrés.
• Seguridad.
• Usabilidad.
• Localización.
• Accesibilidad.
• Etc.

Se debe indicar qué se va a probar, es decir, indicar la cobertura de pruebas de cada una de las funcionalidades. Para ello se suelen fijar baremos para los tipos de cobertura existentes, típicamente se suele utilizar los criterios cobertura alta, media y baja.

• Cobertura Alta: Se corresponden a funcionalidades críticas en la aplicación/producto bajo pruebas, es decir, en el núcleo principal.
• Cobertura Media: Se aplica a funcionalidades importantes pero no imprescindibles para realizar flujos de la aplicación.
• Cobertura Baja: Aplica a funcionalidades de la aplicación que se consideran secundarias y de apoyo a las operativas principales de la aplicación.

2.Funcionalidad no cubierta

Si por las características del proyecto (planificación temporal, objetivos, tipo de proyecto, etc.) no se puede abarcar una cobertura total de las funcionalidades, se debe indicar cuáles son las áreas no cubiertas así como la justificación y aceptación del propietario del producto/aplicación.

3. Riesgos (identificación, evaluación y mitigación)

En este apartado se deben detallar los posibles riesgos que se detectan en el proyecto de calidad del software que puedan afectar al NO cumplimiento de las pruebas planificadas.

Los riesgos típicos suelen ser los siguientes:

• Retrasos en el desarrollo del software.
• Retrasos en la entrega del software.
• Entornos de prueba no disponibles.
• Falta de datos de pruebas.
• Errores en la planificación del proyecto.
• Falta de recursos (software y hardware).

Una vez identificados y analizados los riesgos se deben definir planes para prevenir cada uno de los riesgos detectados y resolverlos lo antes posible en caso de que se produzcan.

4.Criterios de suspensión de las pruebas y requisitos para la reanudación

Se deben detallar, en esta parte de la estrategia, claramente cuáles son los motivos para la suspensión de las pruebas de una funcionalidad y/o del proyecto entero. La compañía del producto debe aprobar los criterios de suspensión de la ejecución del proyecto, así como indicar y ratificar los criterios para la reanudación del proyecto una vez resueltos los problemas que causaron la paralización del mismo.

La experiencia dice que en la mayoría de las ocasiones que se debe parar un proyecto ha sido causado por un riesgo ya identificado en la estrategia de pruebas. Por ello, la necesidad de definir los riesgos antes del inicio del proyecto y cuantificar el “daño” que implica la aparición de cada riesgo para la suspensión temporal del proyecto hasta su correcta resolución.

Continuará…

Descubre solución integral de SOGETI para mejorar el proceso de pruebas y garantizar la calidad y la eficiencia de los sistemas de información de las empresas.

Alberto Garrido

Ingeniero de Test Senior | Software Control & Testing | SOGETI España