Un 95% de tasa de aprobación de tests puede significar que tu suite es efectiva o que eliminaste silenciosamente los tests difíciles que seguían fallando: el número solo no dice nada si no sabes qué estás midiendo. La misma ambigüedad aplica al conteo de bugs por sprint y a los casos de prueba escritos, que miden actividad, no calidad. Este artículo cubre las seis métricas que dan datos accionables, cómo calcular cada una, y los antipatrones que hacen que los equipos parezcan productivos mientras la calidad cae.

Métricas que importan

Tasa de escape de defectos

Definición: Porcentaje de bugs que llegaron a producción vs. bugs encontrados en testing. 

Tasa de escape = (Bugs encontrados en producción / Total de bugs encontrados) × 100%

Ejemplo: 20 bugs encontrados en testing + 5 bugs encontrados en producción = 25 total. Tasa de escape = 5/25 = 20%. Por qué importa: Esta es la métrica más cercana a "¿qué tan bien estamos detectando bugs?" Una tasa de escape alta significa que QA no está detectando problemas antes que los usuarios. Objetivo: Por debajo del 10% es razonable. Por debajo del 5% es sólido.

Tiempo medio de detección (MTTD)

Definición: Tiempo promedio desde que se introduce un bug hasta que se reporta.

Un bug introducido en un commit el lunes pero no encontrado hasta la ejecución de regresión del viernes tiene un MTTD de 4 días. Un bug encontrado por un test automatizado 5 minutos después del commit tiene un MTTD de 5 minutos.

Por qué importa: Menos tiempo de detección = corrección más barata. Un bug encontrado en CI cuesta 10 veces menos de corregir que uno encontrado en QA, y 100 veces menos que uno encontrado en producción. Cómo mejorarlo: Shift left. Más tests unitarios, tests de integración automatizados y testing en cada commit empujan la detección más temprano.

Tasa de automatización de pruebas

Definición: Porcentaje de casos de prueba que están automatizados. 

Tasa de automatización = (Tests automatizados / Total de casos de prueba) × 100%

Por qué importa: Los tests automatizados se ejecutan en cada commit, detectan regresiones de inmediato y liberan tiempo de QA para testing exploratorio. Advertencia: La tasa de automatización bruta puede engañar. Un 90% de automatización de tests triviales es peor que un 50% de automatización de los flujos de alto riesgo. Mide la automatización de los caminos críticos, no solo todos los casos de prueba.

Cobertura de pruebas

Hay tres tipos que vale la pena rastrear: cobertura de requisitos (qué porcentaje de requisitos tiene tests correspondientes), cobertura de código (qué porcentaje del código se ejecuta con los tests, que es principalmente una métrica de desarrollo pero QA debería entenderla), y cobertura de riesgos (si las áreas de mayor riesgo están probadas). Las brechas de cobertura son donde los bugs se esconden sin ser detectados. Un 100% de cobertura de requisitos no significa que los casos extremos estén cubiertos. Úsalo junto con una evaluación de riesgos.

Densidad de defectos

Definición: Número de bugs por unidad de tamaño del software. 

Densidad de defectos = Total de defectos / Tamaño (kloc, story points, funcionalidad)

Comparar la densidad de defectos entre funcionalidades, equipos o sprints ayuda a identificar dónde se concentran los problemas de calidad. Si la funcionalidad X tiene consistentemente 3 veces más densidad de defectos que las demás, investiga por qué: ¿requisitos poco claros, desarrollo apresurado, código complejo?

Tasa de ejecución de pruebas

Definición: Casos de prueba planificados ejecutados vs. total planificado. 

Tasa de ejecución = (Casos de prueba ejecutados / Casos de prueba planificados) × 100%

Por qué importa: Una tasa de ejecución baja antes de un release es una señal de riesgo. No completaste el testing planificado.

Tasa de tests flaky

Definición: Porcentaje de tests que a veces pasan y a veces fallan sin cambios en el código. 

Tasa de flakiness = (Tests con resultados intermitentes / Total de tests) × 100%

Por qué importa: Los tests flaky destruyen la confianza del equipo en la suite de pruebas. Cuando falla el CI, nadie sabe si es un bug real o un test flaky. Los equipos empiezan a ignorar los fallos. Después los bugs reales también se ignoran. Objetivo: Por debajo del 2%. Si está más alto, es una prioridad corregirlo.

Métricas que parecen buenas pero engañan

Conteo de bugs por sprint

La trampa: Encontrar más bugs no significa que QA esté trabajando más. El conteo de bugs depende de cuántas funcionalidades se desarrollaron, qué tan complejas eran y cuánto riesgo se asumió. Un sprint con correcciones simples siempre tendrá menos bugs que uno con funcionalidades nuevas complejas. Mejor alternativa: Rastrear el conteo de bugs junto con la velocidad de desarrollo y la evaluación de riesgos.

Casos de prueba escritos

La trampa: Escribir 100 casos de prueba por sprint no es inherentemente mejor que escribir 50. 100 casos de prueba obvios que prueban lo que claramente funciona añade menos valor que 50 casos extremos cuidadosamente elegidos que realmente encuentran bugs. Mejor alternativa: Rastrear la cobertura de casos de prueba sobre los requisitos, no el conteo bruto.

Tasa de aprobación

La trampa: "El 95% de los tests pasa" suena bien. Pero puede significar que tus tests son trivialmente fáciles de pasar, que eliminaste los tests difíciles que seguían fallando, o que los fallos conocidos se están omitiendo. Mejor alternativa: Rastrear la tendencia de la tasa de aprobación a lo largo del tiempo, e investigar por qué existen los tests que fallan.

Seguimiento de métricas a lo largo del tiempo

Las métricas solo se vuelven útiles cuando las rastreas en el tiempo. Un snapshot único no dice nada. Las tendencias te dicen si las cosas mejoran o empeoran.

Herramientas útiles: dashboards de Jira para métricas de defectos, TestRail para rastrear la ejecución de casos de prueba, GitHub Actions o Jenkins para métricas de automatización, Grafana para dashboards personalizados con datos de CI.

Enfoque simple, seguimiento semanal en una hoja de cálculo:

| Semana | Bugs encontrados | Bugs escapados | Tasa de automatización | Tasa de flakiness |

|--------|-----------------|----------------|----------------------|-------------------|

| S1 | 15 | 2 | 60% | 8% |

| S2 | 12 | 1 | 63% | 6% |

| S3 | 18 | 0 | 65% | 5% |

| S4 | 10 | 2 | 68% | 4% |

Tendencias: la automatización sube, la flakiness baja, la tasa de escape es baja.

Reportar métricas a stakeholders

Equipo técnico (retrospectiva de sprint): conteo y tendencia de tests flaky, progreso en la tasa de automatización, mejora en MTTD gracias a los tests añadidos. Gestión (mensual): tasa de escape de defectos, bugs P1/P2 en producción vs. el período anterior, cobertura de pruebas en funcionalidades críticas, tiempo ahorrado por automatización vs. testing manual. Stakeholders no técnicos (trimestral): traduce los números a impacto de negocio. "Prevenimos X problemas visibles para los usuarios este trimestre." "Nuestra suite automatizada corre en 15 minutos, detectando regresiones antes de que salgan." "La tasa de escape de defectos bajó del 25% al 8% interanual."

Empezar un programa de métricas

No trates de rastrear todo de una vez. Empieza con dos o tres.

Mes 1

Rastrear tasa de escape de defectos y tasa de tests flaky. Establecer una línea base.

Meses 2 a 3

Añadir tasa de automatización. Empezar a apuntar a la reducción de flakiness.

Mes 4 en adelante

Añadir MTTD y cobertura de requisitos. Revisar tendencias y establecer objetivos de mejora.

El objetivo es mejorar, no la perfección. Las métricas que exponen problemas están haciendo su trabajo.

Resumen

| Métrica | Qué mide | Por qué importa |

|---------|----------|-----------------|

| Tasa de escape de defectos | Bugs que llegan a producción | Efectividad central de calidad |

| MTTD | Velocidad de detección de bugs | Costo de corrección de bugs |

| Tasa de automatización | Madurez de la suite de pruebas | Velocidad y cobertura de regresión |

| Tasa de tests flaky | Fiabilidad de la suite | Confianza en la suite |

| Densidad de defectos | Concentración de bugs | Dónde enfocar el esfuerzo de calidad |

| Cobertura de pruebas | Requisitos probados | Identificación de brechas |

Las buenas métricas responden: "¿Estamos mejorando?" Si tus métricas no muestran mejora con el tiempo, o son las métricas equivocadas, o tienes problemas de proceso que resolver.

→ See also: Métricas QA que Realmente Importan: Tasa de Escape de Defectos, MTTD y Más | Informes de Tests en CI: Formatos, Herramientas e Integración | Convertirse en QA Lead: Responsabilidades, Habilidades y la Transición