¿Qué es la cobertura de pruebas?

Quiero reflotar algo que escribí hace unos años por acá, sobre test coverage (o sea, lo que a veces se le llama cobertura de pruebas y otras veces cubrimiento de pruebas). En parte lo que me motivó a repasar estos conceptos es que estoy preparando un webinar sobre el tema, que daré en conjunto a los amigos de SmartBear.

Mucha gente dice que la cobertura sirve para dar una medida de calidad de las pruebas, y creo que esto trae algo de confusión por lo que creo que hay que tener cuidado cómo se mide y cómo se interpreta. Yo prefiero ver el concepto de cobertura como una medida de qué tanto examinamos un sistema con nuestras pruebas en base a determinado criterio.

Ese criterio nos hace definir cierto tipo de entidades o elementos del sistema, que serán las unidades que vamos a intentar cubrir, y por esto es que será lo que vamos a dar como medida de cobertura: cuál es el porcentaje de unidades que consideramos en nuestras pruebas con respecto al total. Esta medida puede ser útil para determinar cuándo probamos suficiente, o para tomar ideas de qué otra cosa probar (pensando en aumentar la cobertura en base al criterio elegido).

Para verlo de manera más simple, usemos una analogía: pensemos la cobertura al barrer la casa.

Una forma de hablar sobre cómo barro la casa, es indicar si cubrí todas las habitaciones o no. Así estamos midiendo la calidad de mi barrida, y a su vez me da una idea para saber cuándo puedo parar de barrer: cuando haya cubierto cada habitación.

Ahora, lograr el 100% de cobertura con ese criterio, ¿indica que la casa está limpia?

¡NO, porque la cocina y el comedor ni los miré! Entonces, ¡ojo!, se debe manejar el concepto con cuidado. Tener cierto nivel de cobertura es un indicador de la calidad de las pruebas en base al criterio con el cual estamos midiendo esa cobertura, pero nunca es un indicador de la calidad del sistema, ni me garantizará que está todo probado ni qué tan bien está probado (el criterio puede haber sido mal definido, o no ser el más apropiado ni el único).

¿Para qué me sirve medir la cobertura de pruebas?

Algunos ejemplos podrían ser:

Medir la calidad de cómo barro (en base al criterio establecido).
Determinar cuándo parar de barrer (en base al criterio establecido).
Viendo lo que ya barrí, pensar en qué más barrer (en base al criterio establecido).

Imaginarás lo importante que es establecer un buen criterio.

Tal como dice Michael Bolton en este artículo, lo útil de la cobertura es poder decir qué tan profundo examinamos un sistema X en base a un modelo del sistema X.

Unos criterios pueden ser más fuertes que otros, entonces el conocerlos me puede dar un indicador de qué tan profundas son las pruebas, cuándo aplicar uno y cuándo otro. Por ejemplo, se dice que un criterio A subsume a otro criterio B si cualquier conjunto de casos de prueba que cubre el criterio A también cubre el criterio B.

Siguiendo la analogía:

Criterio 1: barrer cada habitación.
Criterio 2: barrer cada pieza (habitaciones, comedor, cocina, baño, etc.).
Criterio 3: barrer cada pieza, incluso en las esquinas, porque ahí hay más posibilidades de que se acumule mugre.

El criterio 3 subsume al criterio 2, el cual subsume al criterio 1 (y la relación es transitiva, con lo cual el criterio 3 subsume al criterio 1).

La analogía es evidente 😉

Ejemplos más aplicados a las pruebas de software podrían ser:

Risk coverage: qué tanto examinamos el sistema en base a un modelo de riesgos.
Requirements coverage: qué tanto examinamos el sistema en base a un modelo de requerimientos.
Code coverage: qué tanto examinamos el sistema en base a un modelo del código.

Las técnicas de diseño de casos de prueba están siempre asociadas a un criterio de cobertura, y justamente lo que plantean es realizar un modelo del sistema bajo pruebas, y luego indicar cómo cubrirlo:

Partición de equivalencias: se establece un modelo donde se identifican variables y se dividen en subconjuntos en base a un modelo de comportamiento de estas variables. Luego, la técnica dice cómo diseñar los casos de prueba para poder cubrir todas las clases identificadas.
Árboles de decisión: se realiza un modelo de las distintas decisiones anidadas teniendo en cuenta las variables que cambian el comportamiento del sistema, y se pretende cubrir las combinaciones de estas variantes.
Máquinas de estado: se realiza un modelo del comportamiento del sistema basado en estados, y se establecen mecanismos para poder cubrir distintos criterios, como todos los estados, todas las transiciones, etc.

En cada caso tenemos que pensar qué modelos pueden ser útiles para modelar nuestro sistema, y luego sobre estos modelos analizar qué cobertura tenemos y qué cobertura queremos lograr. De esta forma podremos ampliar nuestro conocimiento sobre el comportamiento del sistema bajo pruebas.