Utilice la cobertura de código de forma inteligente para maximizar el esfuerzo de prueba

Inteligentemente usar métricas de cobertura de código para centrar los esfuerzos de prueba donde más se necesitan mediante la comprensión de dónde se requieren nuevas pruebas y la creación de conjuntos de pruebas mantenibles.

Uno de los principios clave de Agile es garantizar la calidad de envío de los entregables incrementales mientras se responde a los requisitos cambiantes. Pero el desafío de equilibrar la prueba de la nueva funcionalidad mientras se valida la operación correcta de la funcionalidad existente hace que muchos equipos de desarrollo ágiles se atasquen en la creación, administración y mantenimiento de un conjunto de pruebas en expansión. Al final, puede resultar muy difícil acelerar la agilidad y tener confianza tanto en la calidad como en la seguridad del producto sin la cantidad adecuada de información.

Observar la cantidad de código ejercido durante las pruebas es una métrica útil para comprender el nivel de mitigación de riesgos que se está realizando, pero a menudo se usa incorrectamente y, a nivel macro, no es un buen indicador de calidad. En esta publicación, le mostraré cómo usar inteligentemente las métricas de cobertura de código para enfocar los esfuerzos de prueba donde más se necesitan, al comprender dónde se requieren nuevas pruebas. También veremos algunas de las mejores prácticas para crear conjuntos de pruebas que se puedan mantener.

Cómo pensar en la cobertura útil del código

La cobertura del código no es “el” número para determinar cuándo tiene suficientes pruebas, pero es “un” número que puede ser muy útil para guiar a los equipos sobre dónde enfocarse.

Desafortunadamente, a menudo se usa incorrectamente para administrar equipos al enfocarse en el número en sí y buscar un porcentaje específico contra la base del código, por ejemplo, usando políticas como "debemos tener una cobertura del 80% antes de poder publicar" o "el número de cobertura debe ser igual o superior a la versión anterior ".

El problema con este enfoque es que obtener y mantener un número de cobertura objetivo es difícil y requiere mucho tiempo en sí mismo, por lo que trabajamos ciegamente hacia el número y nadie se toma el tiempo para hacer preguntas importantes, tales como:

• Cual 80% estamos cubriendo?
• ¿El esfuerzo de prueba validará la calidad y reducirá el riesgo de que se entregue la aplicación?
• ¿Cómo mantendré las pruebas a medida que evolucione el código?

Como discutí en un blog anterior, cada cambio en la base del código representa una introducción de riesgo, y comprender el impacto específico de cada cambio en el código existente es importante además de comprender cómo mitigar ese riesgo.

Al identificar los cambios en la base del código y utilizar la cobertura del código para correlacionar las pruebas con esos cambios, se puede crear un plan de prueba óptimo en función de dónde se necesite volver a probar (lea más sobre las pruebas basadas en cambios aquí).

Pero esto no cubre todos los riesgos. Obviamente, todavía necesitamos crear pruebas para la nueva funcionalidad, pero ¿qué pasa con el código existente / heredado? Muchas organizaciones con las que hablamos tienen objetivo de una cobertura de código del 60-80%, pero en realidad luchan por superar el 50%. Por lo tanto, existe una buena posibilidad de que un caso de prueba existente no cubra un cambio en el código existente. Centrándose únicamente en preservar, o crecer de forma incremental, el objetivo de cobertura macro no protege de la introducción de regresiones en la funcionalidad heredada que "ha estado funcionando durante años".

En cambio, al observar más de cerca los detalles de la cobertura, las líneas modificadas específicas que NO se han cubierto se pueden identificar rápidamente, para que pueda enfocar al equipo en dónde se deben crear nuevas pruebas. Además, al utilizar la trazabilidad entre los casos de prueba y el código específico que están ejerciendo, puede identificar posibles casos de prueba que se pueden duplicar o ampliar para cubrir los cambios.

Al enfocarse en lograr una cobertura del 100% del código modificado, en comparación con un objetivo arbitrario del equipo de "cobertura total del 80%", el equipo puede ser mucho más eficiente para mitigar el riesgo de código nuevo mientras elimina los factores que afectan la estabilidad general del proyecto (por ejemplo, modificaciones a código heredado.)

Cobertura de código modificado en acción

Es posible medir esta cobertura de código inteligente utilizando el widget Cobertura de código modificado de Parasoft DTP (un "segmento" analítico del motor de inteligencia de procesos (PIE) de Parasoft DTP). Aquí, puede ver fácilmente la cobertura del código que se ha agregado o cambiado entre dos compilaciones (por ejemplo, la compilación actual y una compilación de destino de su elección). Por ejemplo, la figura 1 muestra un widget de este tipo. En este ejemplo, se agregaron o cambiaron 177 líneas de código entre las dos compilaciones y se probaron 109 de esas líneas, es decir, el 61.6%. Esto significa que hay 68 líneas de código nuevo o modificado que no están cubiertas por ninguna prueba y, por lo tanto, no han sido validadas y representan un riesgo en la base del código.

Sentado detrás de este widget hay un informe de cobertura modificado. El informe proporciona detalles exactos sobre qué código falta en las pruebas adecuadas. Esta es la información clave que los desarrolladores y evaluadores necesitan para enfocar sus esfuerzos. La Figura 2 muestra un informe de este tipo, en el que los archivos modificados se pueden ordenar en función del número de cambios, o pruebas de código faltante, con líneas modificadas descubiertas marcadas en rojo.

Este informe responde a la pregunta "¿qué pruebas me estoy perdiendo?" Según la información aquí para cada compilación, se puede crear un plan de prueba.

¿Qué tipo de prueba crear?

Una vez que haya identificado el código en el que faltan pruebas, en realidad debe ponerse a trabajar y crear las pruebas para llenar el vacío, pero ¿qué tipo de pruebas crea? La pirámide de prueba (como fue evangelizada por Martín Cazador y  mike cohn) describe cómo crear una cartera de pruebas eficiente, manejable y mantenible. Al minimizar las pruebas de nivel de interfaz de usuario frágiles y centrándose en una base sólida de pruebas unitarias (respaldado con pruebas integrales de nivel de servicio/API) puede crear una estrategia de prueba que sea escalable, mantenible y que pueda ejecutarse continuamente.

No vamos a entrar en los detalles de la creación de pruebas unitarias o API en este blog, pero puede consultar mi blog anterior sobre pruebas unitarias y estar atento a un próximo blog sobre cómo Prueba SOA de Parasoft se puede utilizar para simplificar la creación de pruebas de nivel de API / servicio.

Conclusión

La cobertura del código es una métrica importante, pero a menudo se usa en exceso y en forma incorrecta, especialmente cuando se usa para medir la calidad. Para obtener más valor de la cobertura del código, aproveche la inteligencia analítica de Parasoft DTP para detectar dónde se necesitan nuevas pruebas, mitigar los riesgos, enfocar sus pruebas y lograr de manera óptima sus objetivos de calidad.

por Mark Lambert

Mark, vicepresidente de productos de Parasoft, es responsable de garantizar que las soluciones de Parasoft brinden un valor real a las organizaciones que las adoptan. Mark ha estado con Parasoft desde 2004, trabajando con una amplia variedad de clientes de Global 2000, desde implementaciones de tecnología específicas hasta iniciativas de mejora de procesos SDLC más amplias.