Conoce nuestro método recomendado para planificar una buena cobertura de prueba durante múltiples ciclos de testing.

Queremos probar tanto código como sea humanamente (o mecánicamente) posible, ¿verdad? Si y no. Para cada ciclo de prueba, es importante considerar múltiples estrategias para medir la cobertura de la prueba y establecer una manera para maximizarla a largo plazo.

La cobertura de la prueba es una de las medidas de la calidad que nos dice qué parte de la aplicación que se está probando se ha probado previamente.

En Abstracta, creemos que la cobertura es útil para definir ciertas entidades del sistema con el propósito de cubrirlas con pruebas. También nos dice cuándo hemos probado lo suficiente, nos da ideas de qué más probar (ampliando así la cobertura) y nos ayuda a saber cuantitativamente el alcance de nuestras pruebas. Y es que incluso con una cobertura del 100%, nunca se nos garantizará que nuestra aplicación esté libre de errores.

También es importante tener en cuenta que el porcentaje de cobertura de la prueba no lo es todo. Incluso si solo logró lograr una cobertura del 20%, no sería malo porque la cantidad ideal de cobertura de prueba debe determinarse después de realizar un análisis de riesgos y debe ser acorde con tus prioridades.

Hay muchas maneras de considerar la cobertura de la pruebas. A continuación veremos la cobertura de código, la cobertura orientada a datos y otras técnicas de las que dispone un tester.

Cobertura de código

La cobertura de código (test coverage) es la métrica más popular para medir la cobertura. Hay diferentes niveles, no solo se cubren las líneas de código, sino que también hay ramas, decisiones dentro de los constructores lógicos, etc.

Cobertura orientada a Datos

Con la cobertura orientada a datos (Data-Oriented Coverage), tienes parámetros de entrada y salida, cada uno de ellos con su propio dominio (el espectro de posibles valores que pueden tener) y si piensas en todas las posibilidades, ves que terminas con un producto cartesiano (porque puedes probar todas las combinaciones posibles).

Por otro lado, puedes probar menos e ir con la cobertura de “cada opción”, lo que significa que eliges cada valor posible al menos una vez. También está el de todos los pares, del que se dice empíricamente que tiene la mejor relación costo-beneficio, siendo la mejor combinación entre cada opción y todas las combinaciones.

Otros tipos de cobertura de pruebas

Además de las mencionadas anteriormente, hay varias formas más de cubrir el producto que está probando, como state-machines, tablas de decisión, árboles de decisión, partición de equivalencia y valores límite, etc.

Es muy interesante ver que cada técnica es apoyada por una “teoría del error”. La teoría del error tiene en cuenta los errores típicos que cometen los programadores, como por ejemplo, la partición de equivalencia y los valores límite consideran el error de, por ejemplo, usar un “<” en lugar de un “<=”, malinterpretar la lógica empresarial, o por ejemplo, un árbol de decisión que intenta ejecutar todas las “decisiones” y combinaciones de condiciones interesantes que tiene un programa, que no es más que intentar maximizar la cobertura de ramas en el código.

Para mí, el último punto mencionado sobre la caja negra es muy interesante: un criterio de cobertura con una visión muy de caja negra puede mejorar las pruebas de caja blanca en términos de cobertura.

Además, existen otros tipos de cobertura de pruebas que no están relacionados con las líneas de código o la introducción de datos de prueba. Una cosa que debemos cubrir es la fragmentación móvil: ¿estamos cubriendo los principales dispositivos móviles, sistemas operativos y tamaños de pantalla?

Cuando se trata de navegadores y sistemas operativos, debemos considerar cómo se comportará nuestro sistema web en cualquier combinación de sistemas operativos y navegadores y cuántas combinaciones debemos probar. Por último, piense en el entorno de prueba, el contexto, etc.

Diseño de un plan

¿Qué sucede cuando nunca tienes suficiente tiempo para alcanzar ciertos criterios para tus ciclos de prueba? A continuación presentaré una solución que funciona bien en estos casos. Lo he usado antes y espero que tenga sentido para ti también.

Para ilustrar la idea principal, digamos que tenemos diferentes funciones para probar en diferentes navegadores y hemos organizado diferentes casos de prueba con diferentes conjuntos de pruebas, cada uno con su propia prioridad.

Necesitamos ejecutar los más críticos contra todos los navegadores, pero el resto, podemos decidir ejecutar en un navegador diferente. En los siguientes ciclos de prueba, podemos intercambiar todos los pares (suite/navegador). De esa forma, en cada ciclo de prueba no tenemos una gran cobertura, pero después de múltiples ciclos de prueba, la mejoramos. Nunca podemos estar seguros de que hemos terminado con las pruebas, pero cuando el tiempo es escaso, tenemos que usarlo sabiamente y hacer todo lo posible para reducir el riesgo.

Este es un ejemplo de cómo planificar una buena cobertura de prueba durante múltiples ciclos de testing.

Donde dice “fecha 1”, también podría decir “sprint 1”, “iteración 1”, “día 1”, “versión 1”, etc. El objetivo aquí es distinguir qué casos de prueba ejecutarás en cada iteración en cada entorno. Para algunos de ellos, es obligatorio ejecutar la prueba cada vez en todos los navegadores (probablemente los más críticos). Otros se pueden dividir en grupos y ejecutar solo en un navegador, pero de una manera muy inteligente para que cada uno se ejecute en cada navegador por la cuarta ejecución.

Aquí hay otro ejemplo aplicado a las pruebas móviles para reducir el riesgo relacionado con la “fragmentación” del dispositivo.

Después de la tercera ejecución, tendría esta cobertura:

Conclusión

Los criterios de cobertura de prueba son muy útiles, pero debes tener cuidado con ellos porque no garantizan nada. Unos criterios van ligados a otros, cuando olvidas uno, olvidas el resto y viceversa.

Necesitamos elegir los criterios que mejor se adapten a nuestras necesidades y también considerar las prioridades para cada módulo y definir la cobertura para mirar cada uno según la prioridad y la complejidad. Finalmente, podemos aplicar criterios de cobertura para optimizar la cobertura de la prueba a largo plazo.

Otros contenidos relacionados

Cobertura de Pruebas de Software: ¿cómo aumenta con la automatización?

Automatización de pruebas: el motor de la ingeniería de calidad

4 desafíos comunes de la automatización de pruebas: ¿cómo enfrentarlos?