Métricas QA que Realmente Importan: Tasa de Escape de Defectos, MTTD y Más

La tasa de escape de defectos te dice qué porcentaje de bugs llegó a los usuarios en lugar de ser detectado en QA, lo que la convierte en el número más cercano a "qué tan bien está funcionando QA." El porcentaje de cobertura de tests te dice qué líneas de código fueron ejecutadas por los tests, algo fácil de inflar al 95% escribiendo aserciones que en realidad nunca verifican nada. Este artículo cubre cinco métricas que vale la pena rastrear, cómo calcular cada una, y tres métricas populares que parecen útiles pero engañan.

Métricas que importan

Tasa de escape de defectos

Qué es: El porcentaje de bugs encontrados por los usuarios (en producción) versus los encontrados durante QA. Fórmula: Bugs encontrados en producción / Total de bugs encontrados × 100 Por qué importa: Es la medida más directa de la efectividad de QA. Si encuentras el 90% de los bugs antes del release, tu tasa de escape es del 10%. Si los usuarios encuentran la mitad de los bugs, algo está mal con tu cobertura. Objetivo: Varía según el riesgo del producto. Los sistemas de pago deberían apuntar a menos del 2%. Las herramientas internas pueden tolerar tasas más altas. Antipatrón: Un equipo con cero bugs en producción no necesariamente hace un gran QA. Puede estar lanzando muy lentamente, o el producto se usa tan poco que los bugs no se reportan.

Densidad de defectos

Qué es: Bugs por unidad de código o funcionalidad. Fórmula: Bugs encontrados / Líneas de código (o story points, o funcionalidades) para un release Por qué importa: Rastrea dónde se concentran los bugs. Un módulo con 10 veces la densidad de defectos del resto del código necesita atención: más cobertura de pruebas, revisión de código, o un refactor. Para qué usarla: Identificar áreas de alto riesgo para priorizar en regresión. Justificar inversión en cobertura de pruebas para módulos específicos.

Tasa de aprobación de tests a lo largo del tiempo

Qué es: Porcentaje de tests que pasan en CI a lo largo del tiempo, rastreado por ejecución. Por qué importa: Una tasa de aprobación que cae gradualmente es una advertencia temprana. O el producto está acumulando regresiones, o la suite está acumulando flakiness. Ambos casos necesitan atención. Señal de alerta: Una tasa estable en el 85% significa que el 15% de los tests siempre falla, lo que significa que el equipo normalizó el fallo. La suite dejó de ser una señal fiable.

Tiempo medio de detección (MTTD)

Qué es: Tiempo promedio entre que se introduce un bug y que se detecta. Por qué importa: Si los bugs tardan dos semanas en detectarse, generalmente se encuentran después de que quien hizo el fix ya se movió a otra cosa, el contexto se perdió y la corrección es más cara. Un MTTD corto significa ciclos de feedback rápidos. Cómo reducirlo: Shift left. Los tests unitarios corren en segundos, los de integración en minutos, los E2E en CI en cada PR. Cuanto antes se detecten los bugs en el pipeline, más bajo el MTTD.

Tendencia del tiempo de ejecución de tests

Qué es: Cuánto tarda en ejecutarse tu suite de pruebas, rastreado en el tiempo. Por qué importa: Una suite que tarda 45 minutos no se ejecuta en cada commit. Los desarrolladores empiezan a saltársela. El ciclo de feedback se rompe. Tendencia saludable: El tiempo de ejecución debería crecer lentamente en relación al número de funcionalidades. Si añadir 10 funcionalidades duplica el tiempo de la suite, la arquitectura de tests tiene un problema de paralelización.

Métricas que parecen útiles pero no lo son

Porcentaje de cobertura de código

La cobertura es la métrica de QA más rastreada y menos útil. Un 95% de cobertura de líneas te dice qué líneas fueron ejecutadas por los tests. No dice nada sobre si esas líneas se verificaron correctamente.

Los equipos la manipulan constantemente: escriben tests que ejecutan código sin aserciones significativas, y la cobertura sube mientras la calidad real no va a ningún lado. Usa la cobertura como un piso ("no mergeamos código por debajo del 80% de cobertura"), no como señal de calidad.

Número de casos de prueba

"Tenemos 10.000 casos de prueba" no dice nada sin saber cuántos están automatizados, cuántos se ejecutan realmente y cuántos están mantenidos. Una suite con 500 tests bien mantenidos, rápidos y fiables vale más que 10.000 casos de prueba manuales desactualizados que nadie ejecuta.

Bugs cerrados por sprint

Cerrar bugs no es el objetivo, prevenirlos sí. Un equipo que cierra 50 bugs por sprint puede estar en una posición terrible (los bugs escapan tan rápido que generan trabajo constante) o en una posición normal (trabajando sobre deuda técnica vieja). El número solo no dice nada.

Métricas de QA útiles para comunicar con stakeholders

Cuando los stakeholders no técnicos preguntan sobre QA, generalmente quieren entender el riesgo, no la metodología. Enmarca las métricas en consecuencia.

Enfoque orientado al riesgo

Por ejemplo: "Tenemos 3 bugs de alta severidad abiertos contra el flujo de pago. Recomendamos retrasar el release móvil hasta que se resuelvan al menos 2." O: "La tasa de escape de defectos subió del 8% al 14% este trimestre. Estamos encontrando más bugs después del release. La causa raíz es menor cobertura de regresión en la capa de API."

Enfoque orientado al progreso

Por ejemplo: "La suite de tests E2E pasó de 22 minutos a 9 minutos después de la paralelización. El feedback de CI en los PRs ahora está por debajo de 10 minutos." O: "La tasa de tests flaky bajó del 15% al 3% este trimestre tras las correcciones de aislación."

Son conversaciones, no dashboards. Las métricas están al servicio de las decisiones (staffing, timing de release, inversión técnica), no de sí mismas.

Cómo empezar a rastrear

No necesitas una herramienta especializada de métricas de QA para empezar. Una hoja de cálculo con cuatro columnas funciona:

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

| 2026-S20 | 18 | 3 | 34 min |

| 2026-S21 | 22 | 1 | 34 min |

| 2026-S22 | 15 | 5 | 37 min |

Las tendencias son más accionables que los puntos de datos individuales. Después de cuatro semanas, vas a ver si los escapes a producción están subiendo o bajando, y si tu suite se está volviendo más lenta.