“Tenemos 85% de cobertura de tests” suena a un buen número. No dice casi nada sobre si tu software es confiable. La cobertura de código es probablemente la métrica de calidad más citada en reportes ejecutivos y, medida sola, una de las que menos correlaciona con calidad real percibida por el usuario.

Esto no significa que la cobertura no importe. Significa que medir calidad con una sola métrica bonita es mentirse a uno mismo de forma elegante.

Por qué las métricas vanidosas engañan

Una métrica vanidosa es la que sube fácil, se ve bien en un dashboard, y no obliga a cambiar ninguna decisión. El número de casos de prueba escritos es una. El porcentaje de cobertura, medido sin contexto, es otra: se puede llegar a 90% de cobertura con tests que no verifican nada significativo, solo ejecutan código sin aserciones útiles.

El problema de fondo es que estas métricas miden esfuerzo, no resultado. Cuántos tests escribiste, no cuántos bugs reales evitaste que llegaran a producción.

Qué medir en su lugar

Escape rate (tasa de fuga de defectos). Cuántos bugs llegan a producción versus cuántos se detectan antes del release. Es la métrica más honesta de si tu proceso de calidad está funcionando, porque mide el resultado final, no el esfuerzo intermedio.

Tiempo de ciclo de regresión. Cuánto tiempo le toma al equipo tener confianza suficiente para hacer un release. Si ese número no baja con más automatización, algo en la estrategia está mal diseñado — no alcanza con automatizar, hay que automatizar lo que realmente acorta el ciclo.

Estabilidad de la suite (flakiness). Qué porcentaje de los tests automatizados fallan de forma intermitente sin que haya un bug real. Una suite con alta tasa de falsos positivos termina ignorada por el equipo — y una suite ignorada no aporta calidad, aporta ruido.

Densidad de defectos ponderada por severidad. No todos los bugs pesan igual. Contar bugs sin pesarlos por impacto (un typo en un texto versus un error de cálculo en un cobro) hace que la métrica global no refleje el riesgo real del producto.

Tiempo medio de detección y de resolución (MTTD / MTTR). Cuánto tiempo pasa entre que se introduce un defecto y se detecta, y cuánto entre que se detecta y se resuelve. Equipos maduros no necesariamente tienen menos bugs — tienen ciclos de detección y corrección mucho más cortos.

El error de medir para mostrar, no para decidir

La pregunta que conviene hacerse antes de adoptar cualquier métrica no es “¿esto se ve bien en un reporte?” sino “¿esta métrica, si cambia, me hace tomar una decisión distinta?”. Si la respuesta es no, probablemente es una métrica vanidosa, sin importar cuánto se use en la industria.

Un buen sistema de métricas de calidad es chico — cuatro o cinco indicadores, no veinte — y cada uno está atado a una decisión concreta: si el escape rate sube, se revisa la estrategia de cobertura; si la suite se vuelve inestable, se invierte tiempo en estabilizarla antes de seguir agregando tests nuevos.

Dónde entra la IA acá

La IA puede ayudar a calcular y cruzar estos indicadores más rápido — por ejemplo, analizando logs de fallos para distinguir flakiness real de bugs genuinos — pero no resuelve el problema de fondo si el equipo sigue midiendo lo que es fácil de medir en vez de lo que de verdad importa. La estrategia de métricas sigue siendo una decisión humana.

Si tu reporte de calidad tiene muchos números pero no te dice si podés confiar en el próximo release, eso es justamente lo que se revisa en un diagnóstico de madurez de QA. Hablemos.