La cobertura es un concepto relacionado con la medición de la relación entre factores, y se la define como el grado en el cual un elemento específico es sometido a una bateria de pruebas, donde el «elemento» de la cobertura puede ser cualquier cosa que debamos cubrir durante las pruebas.
Este concepto se vincula con otro y que es el de la «trazabilidad», ya que estamos midiendo nuestras pruebas contra los requisitos que han definido respecto al producto.
Es decir, debemos determinar cómo se vincula lo que estamos probando con el pedido del cliente y expresado en el requerimiento original, convertido tal vez en especificación funcional.
De la medición que podamos hacer, resultará el grado de cobertura en la que nuestras pruebas están dando respuesta a todo lo que se necesita cubrir.
Un primer análisis que resulta de esta medición es conocer en qué área hace falta agregar más cobertura, por ejemplo.
Para las pruebas basadas en requisitos, debemos planificar medir contra las especificaciones.
Para las pruebas basadas en riesgos, debemos planificar medir contra aquellos eventos de amenazas que podamos detectar.
Para las pruebas basadas en interoperabilidad, debemos planificar medir la cobertura de las configuraciones y las interfaces.
También existe la cobertura de código, tema que esta tratado en el capitulo 4 del ISTQB Foundation Level.
Por otra parte y si lo vemos desde el punto de vista de las pruebas de Caja Blanca, pasadas las pruebas de caja negra podemos considerar trabajar sobre un programa marcando las líneas de código que se ejecutan, de esta manera podremos determinar qué porcentaje de líneas ha sido ejecutado alguna vez, porcentaje que se conoce como cobertura de sentencias.
Si logramos alcanzar una cobertura de caja negra del 100%, y una cobertura de sentencias del 100%, por lo tanto podemos pasar a la siguiente fase: prueba de condiciones.
También puede ocurrir que partes del código no hayan sido ejecutadas jamás (cobertura de sentencias inferior al 100%), por lo que para estos casos habrá que realizar más pruebas buscando que se ejecuten todas y cada una de las sentencias del programa.
En este sentido, puede ser que hayamos conseguido una cobertura elevada de sentencias, pero tal vez nos estemos contemplando las ramas condicionales. Por ejemplo:
x= 0;
if (y < 100)
x++;
Si consideramos durante nuestras pruebas un valor de y inferior a 100, habremos ejecutado todas las líneas; pero nunca la variante de que x no se incremente.
Se habla de una cobertura de ramas al 100% cuando se ha ejercitado todas y cada una de las posibles vías de ejecución controladas por condiciones.
La cobertura de ramas es indiscutiblemente deseable; pero habitualmente es un objetivo excesivamente costoso de alcanzar en su plenitud, salvo que lo hagamos con herramientas de automatización.
Por lo tanto, muchos recomiendan
- realizar pruebas de caja negra hasta alcanzar una cobertura funcional del 100% (idealmente)
- inspeccionar código ejecutado y agregar condiciones para someter a prueba a aquellas partes del programa no ejecutadas
- inspeccionar condiciones con un cierto grado de complejidad «difíciles» del código para intentar forzar variedad
Una forma de calcular la trazabilidad para la cobertura de pruebas
Por medio de una planilla de cálculo podemos hacer el cálculo de la trazabilidad respecto de los casos de prueba contra requisitos.
Básicamente deberíamos disponer los casos de prueba en forma horizontal y las especificaciones de forma vertical. A la intersección de la celda se le puede definir una medida de grado de cobertura y así tener inventariado todo el universo en cuestión.
El espacio en blanco o «0», significaría sin cobertura, el «1» significaría una cobertura indirecta, es decir que solo cubre los límites o fronteras del elemento afectado, mientras que «2» significaría una cobertura directa, es decir que cubre un 100% el elemento afectado.
A través de la técnica de tabla dinámica hasta podríamos llegar a conclusiones importantes en cuanto al tamaño de la cobertura que tenemos entre casos de pruebas y sus correspondientes especificaciones.
Ahora bien, y bajando ésto a terreno, nos podemos dar cuenta que dependiendo de la magnitud del sistema, estaremos enfrentando una administración bastante pesada por ser planilla de cálculos, y ésto nos obligaría a destinar menos tiempo al nuestro verdadero objetivo que son las pruebas y en análisis de la trazabilidad.
Por lo tanto, las alternativas para la gestión de este tema podrían ser un gestor de base de datos o bien, una herramienta que nos brinde solución a esta problemática.
Y para seguir con el tema, abriendo un debate, les propongo leer y analizar el siguiente artículo
«El % de cobertura no significa nada»
(http://softwareagil.blogspot.com.ar/2009/08/el-cobertura-no-significa-nada.html)
en el próximo artículo ampliaremos al respecto y espero que otros se sumen a discutir sobre este tema y podamos conocer diferentes perspectivas.
Saludos,
Gustavo
