Testing (II) - Planificación de las pruebas

Este es el segundo de una serie de artículos sobre el testing y el cmmi:

• Testing (I) - Las pruebas según el CMMi
• Testing (II) - Planificación de las pruebas
• Testing (III) - Analizar los resultados de las pruebas

En las pruebas, se suele dejar de lado aspectos fundamentales como son:

• Preparación/planificación
• Análisis
• Reporting de los resultados de las pruebas

Hoy voy a intentar dar un repaso al primero de ellos.

Preparación de las pruebas.

Como cualquier tarea de verificación, las pruebas de software no pueden pasar por alto estas prácticas, que se encuentran por otro lado perfectamente identificadas en el modelo CMMI. Antes de empezar con las pruebas, tiene que haber una etapa de preparación en la cual se seleccionan los productos de trabajo a probar, se establece el entorno de pruebas y se disponen los  procedimientos y los criterios a aplicar en las pruebas. Para los fanáticos anti-burocracia, esta etapa puede ser mucho más simple de lo que estáis pensando. En un proyecto pequeño puede ser unas frases y listas de requisitos. Si siempre hacemos igual las pruebas, puede bastar hacer referencia a nuestro estándar o a un proyecto anterior.

En esta etapa para cada producto a probar se tienen que identificar los requisitos que tiene que satisfacer, y se tiene que buscar la estrategia de pruebas adecuada.

Se tienen que seleccionar los métodos de pruebas que se van a usar, por ejemplo decidir si es adecuado incluir  pruebas de cobertura de caminos, de carga, de esfuerzo, de rendimiento, pruebas basadas en tablas de decisión, y en descomposición funcional, y si se van a reutilizar casos de prueba.

Otro aspecto dentro de la preparación de las pruebas es el establecimiento del entorno de pruebas. Una prueba de producto puede requerir simuladores, emuladores, generadores de escenarios, herramientas de reducción de datos, controles ambientales e interfaces con otros sistemas. De las características del entorno de pruebas se derivan las tareas necesarias para su preparación, que deberán incorporarse al calendario del proyecto.

También se tienen que establecer los criterios que se van a seguir en las pruebas. Para especificarlos es preciso consultar los requisitos del producto y de componentes de producto, estándares, políticas de la organización, tipo de prueba, parámetros de compromiso entre la calidad y el coste de las pruebas, propuestas y acuerdos. Dos de los criterios que tienen que estar fijados especialmente y con objetividad es el de finalización de las pruebas, y el de aceptación del producto. En qué momento se puede dejar  de probar y qué se tiene que cumplir para que se acepte el producto, estos criterios no tienen que ser subjetivos, deben referirse a condiciones susceptibles de ser medidas (por ejemplo: las pruebas terminarán cuando la detección del siguiente error tenga un coste superior a …)

Las pruebas se desarrollan en el entorno establecido e incrementalmente durante todo el ciclo de vida del proyecto. Una organización y realización adecuada de las pruebas contribuye desde un principio a conseguir productos con la calidad acordada.

Como producto de las pruebas no solamente está el resultado de las mismas sino que también se tiene que preparar un informe sobre esos resultados, constatar las acciones a emprender seguidamente y algo que no es frecuente: un registro del método seguido, “cómo se hizo”, para asegurar que las pruebas se pueden repetir exactamente igual. Esto último es importante en labores de mantenimiento,  cuando se hacen pruebas de regresión, para evitar que una alteración en el método confunda el resultado de las pruebas.

Algo importante a tener en cuenta: es posible que por contrato, legislación, normas del cliente, etc., se nos exijan documentos y pruebas específicas que no hayamos inicialmente considerado. Por ejemplo, un cliente en la Administración Pública que use la metodología "X", si por contrato, hemos dicho que vamos a usar dicha metodología, deberemos revisar a qué documentos, tipos y ciclos de pruebas nos hemos de someter. También puede ser típico que no sea directamente el cliente, sino una empresa certificadora de aplicaciones (un proveedor externo), quien en su nombre verifique la calidad de nuestro desarrollo. Por supuesto, que deberemos recoger como requisitos, las pruebas a las que van a someter a nuestro producto.
Vamos a ver en resumen, cual podría ser (en un proyecto grande, y siempre que se estime necesario), la información a recopilar en esta fase de preparación/planificación de las pruebas:

• Tipos de pruebas. Identificar qué pruebas vamos a realizar a nuestro desarrollo.
• Ciclos de pruebas
• Recursos físicos: principalmente, equipos y entornos, software. Al menos, habrá que identificar qué pruebas se realizan en cada entorno (desarrollo, pruebas, pre-producción, producción, formación...). Los recursos también pueden ser los datos de pruebas. Habrá que tener en cuenta si son necesarios, quién es el responsable de proporcionarlos, etc.
• Recursos humanos: personal del cliente responsable o participante en las pruebas, miembros de nuestro equipo y su rol en la prueba a realizar, otras personas (proveedores externos, etc.)
• Calendario de pruebas: tratar de ajustar a nuestro plan de trabajo, las pruebas a realizar. Con ello, no sólo tendremos un calendario orientativo de cuándo tenemos que estar disponibles para hacer las pruebas, sino que además podremos avisar con tiempo de que ciertas personas estén disponibles (por ejemplo, el responsable de sistemas del cliente), o de que se haya comprado e instalado ese servidor Unix que tenemos planificado.
• Restricciones/limitaciones: las que se nos ocurran. Son notas a tener en cuenta para "no meter la pata".
• Dependencias: ¿dependemos de servicios/funcionalidades que proporcionan otros proveedores? ¿Proporcionamos nosotros servicios o funcionalidades que van a requerir otros proyectos?

¿Pero tú estás loco?¿Todo esto es necesario?

La respuesta es sí y no. Es necesario tener en cuenta estas cosas, y es algo que de forma natural, los que hemos estado metidos en muchos proyectos solemos recopilar en mayor o menor grado. Para evitar que se olviden estas cosas, el CMMi (y casi todas las metodologías), nos recomiendan usar una Checklist. Por supuesto, los que nunca lo han hecho, les parecerá la primera vez un gran esfuerzo. Luego, conforme lo usas en varios proyectos, te das cuenta que normalmente sólo haces realmente una parte de lo aquí comentado (¡claro, sólo lo que aplica a tu proyecto, nunca hay que trabajar por trabajar!)

Normalmente, todas estas cosas sólo serán necesarias en proyectos grandes, complejos o con riesgos tecnológicos y/o de integración.

Aquí va una típica conversación entre programador y jefe de proyecto:

• Jefe de Proyecto: venga, lo instalas en pruebas y le das un par de vueltas hasta que estés seguro de que funcione. (notar aquí que el Jefe de Proyecto echa la responsabilidad al programador, pero no le guía en qué, cómo, cuándo ni porqué...)
• Programador: ¿Oye, y que pruebo?
• Jefe de Proyecto: bah, tú simplemente revisa que todo lo que hemos tocado funciona.

Bueno, seguro que vosotros os habéis visto en situaciones similares. La realidad supera como siempre, a la peor de las ficciones.