La cobertura de líneas mide si el código se ejecutó. No mide si alguien verificó que fuera correcto. Son cifras distintas, y solo una sobrevive a una auditoría.
La mayoría de las organizaciones de verificación puede reportar cobertura de líneas con dos decimales y no puede responder una pregunta más simple: ¿de qué partes del comportamiento implementado nadie ha escrito una prueba? Las herramientas miden la ejecución porque es fácil de instrumentar. La intención no lo es.
Del estándar
“Verification and validation (V&V) processes are used to determine whether the development products of a given activity conform to the requirements of that activity and whether the product satisfies its intended use and user needs.”
Por qué divergen ambas cifras
Una línea se ejecuta cuando cualquier prueba la toca. Una prueba que recorre una ruta de inicialización de forma incidental marca decenas de líneas como cubiertas sin verificar nada sobre lo que hacen.
El resultado es un estado familiar y peligroso: alta cobertura de líneas, baja cobertura de comportamiento, y un equipo que cree que la primera cifra describe a la segunda. Suele aparecer cuando un defecto escapa a una entrega a través de código que el reporte mostraba como plenamente ejercitado.
Tres preguntas de cobertura, y normalmente solo una tiene respuesta
¿Se ejecutó el código? La cobertura de líneas lo responde. ¿Está verificado cada requisito? Una matriz de trazabilidad lo responde, si está al día. ¿Está verificado cada comportamiento implementado? Casi nada lo responde — y es la que detecta comportamiento construido pero nunca especificado.
La tercera pregunta es donde vive el riesgo
La cobertura de requisitos asume que los requisitos están completos. En la práctica, los sistemas acumulan comportamiento que ningún requisito describe: un enclavamiento agregado durante la integración, un tiempo de espera ajustado para resolver un problema en campo, una ruta alternativa introducida para sortear un componente de un proveedor.
Cada uno es real, cada uno se entrega, y ninguno aparece en un reporte de cobertura basado en requisitos — porque el reporte solo puede medir contra lo que se escribió. El comportamiento que entró al sistema por una solicitud de cambio y no por una especificación le resulta invisible.
Calcular la brecha
Responder la tercera pregunta es aritmética una vez que se tienen las dos entradas. Enumere lo que existe — cada elemento de interfaz y función en la implementación, en cada variante de configuración que el producto entrega. Luego reste todo lo que ejercita algún prueba existente. El resto es la brecha.
La dificultad está enteramente en la primera entrada. Un inventario de elementos de interfaz mantenido a mano se desactualiza en un sprint, por la misma razón que una matriz de trazabilidad mantenida a mano. El inventario debe derivarse analizando la implementación misma, de modo que se regenere en lugar de actualizarse.
La segunda entrada está disponible si las pruebas registran qué elementos ejercitan al momento de crearse, en lugar de en un documento aparte. Donde esa procedencia existe, la resta es una consulta.
El multiplicador de configuraciones
En un producto de una sola configuración la brecha es una lista. En un producto que se entrega en variantes — distintas regiones, subsistemas opcionales, revisiones de hardware — la cobertura no es una cifra sino una matriz, y un comportamiento verificado en una variante puede estar sin probar en otras cuatro.
Aquí el seguimiento manual se vuelve genuinamente imposible y no solo tedioso. El número de variantes crece multiplicativamente mientras el equipo crece linealmente, y la respuesta habitual — verificar a fondo la configuración más común y hacer muestreos en el resto — es un compromiso de ingeniería defendible que es muy difícil de defender ante un auditor, porque nadie puede enunciar qué comportamientos quedaron sin cubrir.
Triaje, porque la lista cruda es inservible
El primer escaneo de un sistema maduro devuelve miles de brechas. Entregada a un equipo sin priorizar, esa salida se ignora — con razón, porque la lista contiene contadores de diagnóstico y estado interno junto al enclavamiento que nadie probó.
La priorización es lo que la convierte en una cola de trabajo. Las señales que participan en funciones de seguridad, los elementos referenciados por requisitos con mayor nivel de integridad y el comportamiento que cambió recientemente van por encima de un contador estable desde hace tres años. El triaje asistido puede proponer esa priorización; un ingeniero debería confirmarla, porque el costo de priorizar mal una brecha de seguridad es asimétrico.
Ejecútelo antes de la auditoría, no por causa de una
Una brecha descubierta por su propio escaneo es un ítem de backlog que usted programa. La misma brecha descubierta por un evaluador es un hallazgo, con plan de acción correctiva, fecha límite de respuesta y una conversación sobre madurez de proceso. El trabajo de ingeniería es el mismo en ambos casos; todo lo demás no.
Para qué sirve la cifra
No para ser una meta. Un porcentaje de cobertura adoptado como objetivo se convierte en una métrica que la gente optimiza, y la forma más barata de subirlo es escribir pruebas superficiales sobre elementos que nunca fueron riesgosos.
Su uso es direccional: saber dónde se concentra el comportamiento sin probar, para que el esfuerzo de verificación vaya donde está el riesgo y no donde ocurrió el último defecto. Eso es una entrada de planificación para un líder de ingeniería, no un indicador para un tablero.
Axionalytics
IA agéntica en producción para equipos empresariales de ingeniería, datos e ingresos.