Métricas y KPIs de Testing: Midiendo Calidad y Progreso

Domina métricas y KPIs de testing: Densidad de Defectos, Fuga de Defectos, Cobertura de Pruebas, Velocidad, gráficos Burndown. Aprende a crear dashboards accionables que impulsen la mejora de calidad y la confianza de los stakeholders

TL;DR Las métricas de testing convierten evaluaciones subjetivas de calidad en decisiones basadas en datos. Las cinco métricas esenciales son: Densidad de Defectos (por KLOC), Fuga de Defectos (objetivo <5%), Eficiencia de Eliminación de Defectos (objetivo >90%), Cobertura de Automatización de Pruebas y Velocidad de Ejecución. Según investigación de SmartBear, los equipos que rastrean métricas de defectos sistemáticamente lanzan 35% menos defectos en producción que los equipos que dependen de la intuición.
Ideal para: gerentes de QA y líderes de testing que necesitan demostrar el valor del testing a stakeholders e impulsar la mejora de procesos Puedes omitirlo si: necesitas guía para escribir casos de prueba o configurar un framework de automatización

Las métricas y KPIs de testing transforman el “ejecutamos todas las pruebas” subjetivo en evidencia medible y basada en datos de la calidad del software. Según el informe SmartBear 2024 State of Software Quality, solo el 40% de los equipos de QA rastrea regularmente la fuga de defectos — sin embargo, los equipos que lo hacen detectan 35% más defectos en producción antes del lanzamiento comparado con los que no lo hacen. El glosario de ISTQB define más de 30 métricas distintas de testing, pero la mayoría de los equipos solo necesita 5-7 KPIs bien elegidos para tomar decisiones significativas. Esta guía cubre las métricas esenciales de defectos (densidad, fuga, DRE, edad), métricas de cobertura de pruebas (código, requisitos, ejecución), métricas de automatización (cobertura, ROI, tasa de éxito), velocidad y gráficos burndown, y creación de dashboards para diferentes audiencias de stakeholders.

“La métrica de testing más peligrosa es ‘casos de prueba ejecutados’ sin rastrear la tasa de éxito o la fuga de defectos. Los equipos pueden ejecutar el 100% de sus casos de prueba, lanzar con 20% de fuga de defectos, y llamarlo éxito porque la ejecución fue completa. Los KPIs deben estar anclados a resultados — calidad que llega a los usuarios — no a actividades.” — Yuri Kan, Senior QA Lead

Según el glosario de ISTQB y la investigación de testing de SmartBear, las organizaciones que implementan un programa estructurado de métricas de testing reducen su tiempo medio de detección de defectos en producción en un 48% y disminuyen las tasas de fuga de defectos en un promedio de 23% dentro de los 12 meses de adopción.

Las métricas de testing alimentan el Test Summary Report para comunicar resultados a stakeholders, se definen en el Test Plan y se visualizan en Quality Dashboards para seguimiento en tiempo real.

Introducción: Por Qué Importan las Métricas de Testing

El Desafío Sin Métricas

Sin métricas, los equipos de testing enfrentan:

"¿Terminamos de probar?" — No hay forma objetiva de responder
"¿Está mejorando la calidad?" — Intuición en lugar de datos
"¿Dónde deberíamos enfocarnos?" — Adivinando en lugar de analizando
"¿Es efectivo el testing?" — No hay forma de probar el valor

El Poder de las Métricas

Las métricas bien elegidas proporcionan:

Visibilidad: Perspectiva en tiempo real del progreso del testing y la calidad
Responsabilidad: Medición objetiva del rendimiento del equipo
Toma de decisiones: Datos para impulsar la asignación de recursos y priorización
Mejora continua: Las tendencias revelan qué funciona y qué no
Confianza de stakeholders: Demostrar el valor del testing y estado de calidad

Métricas vs KPIs

Métrica: Cualquier medición que rastreas

Ejemplo: Número de casos de prueba ejecutados

KPI (Indicador Clave de Rendimiento): Métrica crítica vinculada a objetivo de negocio

Ejemplo: Cobertura de automatización de pruebas (vinculada al objetivo de reducir tiempo de testing)

No todas las métricas son KPIs. Elige KPIs que:

Se alineen con objetivos de negocio
Impulsen acción y mejora
Sean medibles y rastreables
Proporcionen insights significativos

Métricas de Defectos

Densidad de Defectos

Definición: Número de defectos por unidad de tamaño del software (típicamente por 1000 líneas de código o por punto de función).

Fórmula:

Densidad de Defectos = Total de Defectos Encontrados / Tamaño del Software

Donde el tamaño puede ser:

- Líneas de Código (LOC) — típicamente por 1000 LOC
- Puntos de Función (FP)
- Número de módulos
- Número de requisitos

Ejemplo de Cálculo:

Aplicación: Módulo de checkout de e-commerce
- Líneas de Código: 5,000
- Defectos encontrados: 25

Densidad de Defectos = 25 / (5,000 / 1,000) = 25 / 5 = 5 defectos por KLOC

Interpretación:

Densidad de Defectos	Evaluación de Calidad
0-2 por KLOC	Calidad excelente
2-5 por KLOC	Buena calidad
5-10 por KLOC	Aceptable, necesita mejora
10+ por KLOC	Mala calidad, alto riesgo

Benchmarks de la Industria:

Sistemas críticos: 0.1-0.5 defectos por KLOC
Software comercial: 1-5 defectos por KLOC
Herramientas internas: 5-15 defectos por KLOC

Casos de Uso:

Comparación de módulos: Identificar módulos con alta densidad que necesitan refactorización
Comparación de equipos: Evaluar calidad de código entre equipos
Análisis de tendencias: Rastrear mejora de calidad entre releases

Vista de Dashboard de Ejemplo:

Densidad de Defectos por Módulo (por KLOC)

Checkout:    ████████ 8.2
User Auth:   ████ 4.1
Search:      ██ 2.3
Product:     ██████ 6.5
Cart:        █████ 5.0

→ Acción: Enfocar testing y refactorización en módulos Checkout y Product

Limitaciones:

LOC varía por lenguaje (Python vs Java)
No considera la severidad del defecto
Puede incentivar escribir menos código (no siempre es bueno)
Los módulos complejos naturalmente tienen mayor densidad

Fuga de Defectos

Definición: Porcentaje de defectos encontrados en producción (por clientes) versus total de defectos.

Fórmula:

% de Fuga de Defectos = (Defectos encontrados en Producción / Total de Defectos) × 100

Donde:
Total de Defectos = Defectos encontrados en Testing + Defectos encontrados en Producción

Ejemplo de Cálculo:

Release 3.5:

- Defectos encontrados durante testing: 85
- Defectos encontrados en producción (primeros 30 días): 15

Total de Defectos = 85 + 15 = 100

Fuga de Defectos = (15 / 100) × 100 = 15%

Interpretación:

Fuga de Defectos	Evaluación
0-5%	Excelente — muy pocos defectos escapan
5-10%	Bueno — fuga aceptable
10-20%	Regular — necesita mejora
20%+	Pobre — problemas significativos de calidad

Por Qué Importa la Fuga de Defectos:

Los defectos en producción son 10-100x más costosos que los defectos encontrados en testing:

Insatisfacción del cliente
Pérdida de ingresos
Correcciones de emergencia y hotfixes
Costos de soporte
Daño a la reputación

Fuga de Defectos por Severidad:

Es más revelador rastrear la fuga por severidad:

Análisis de Fuga de Defectos - Release 3.5

Severidad    | Testing | Producción | Fuga % | Objetivo
-------------|---------|------------|--------|----------
Crítica      |    5    |     2      |  28.5% |   <5%  ❌
Alta         |   20    |     3      |  13.0% |  <10%  ❌
Media        |   35    |     8      |  18.6% |  <15%  ❌
Baja         |   25    |     2      |   7.4% |  <20%  ✅

→ Acción: Defectos Críticos y Altos escapando — mejorar testing temprano, agregar más casos de prueba negativos

Análisis de Causa Raíz:

Cuando la fuga de defectos es alta, analiza:

Brechas de cobertura de pruebas: ¿Qué escenarios no se probaron?
Diferencias de entorno: Problemas de entorno de producción vs prueba
Problemas de datos: Los datos de producción revelaron casos extremos
Presión de tiempo: Testing apresurado por plazos ajustados
Brechas de requisitos: Requisitos faltantes o poco claros

Ejemplo de Desglose de Causa Raíz:

Defectos en Producción (15 total) - Causas Raíz:

7 defectos (47%) - Brechas de cobertura de pruebas (escenarios de prueba faltantes)
4 defectos (27%) - Diferencias de entorno (problemas de datos de producción)
2 defectos (13%) - Problemas de integración con terceros
1 defecto (7%)   - Condición de carrera (concurrencia)
1 defecto (7%)   - Degradación de rendimiento bajo carga

→ Acción: Agregar pruebas de casos extremos, mejorar datos de prueba, agregar pruebas de concurrencia

Eficiencia de Eliminación de Defectos (DRE)

Definición: Porcentaje de defectos encontrados antes del lanzamiento a producción.

Fórmula:

DRE % = (Defectos encontrados antes del lanzamiento / Total de Defectos) × 100

Donde:
Total de Defectos = Defectos encontrados antes del lanzamiento + Defectos encontrados en producción

Ejemplo:

Defectos encontrados en testing: 85
Defectos encontrados en producción: 15

DRE = (85 / 100) × 100 = 85%

Interpretación:

90%+ DRE: Excelente efectividad del testing
80-90% DRE: Bueno
70-80% DRE: Aceptable
<70% DRE: Pobre — el testing necesita mejora significativa

DRE por Fase de Prueba:

Rastrea qué fases de prueba capturan más defectos:

Eficiencia de Eliminación de Defectos por Fase

Fase                    | Defectos Encontrados | % del Total | Acumulativo
------------------------|----------------------|-------------|-------------
Testing Unitario        |         30           |     30%     |     30%
Testing de Integración  |         25           |     25%     |     55%
Testing de Sistema      |         20           |     20%     |     75%
UAT                     |         10           |     10%     |     85%
Producción              |         15           |     15%     |    100%

DRE = 85%

→ Insight: Testing de unidad/integración fuerte; UAT encontrando menos defectos (buena señal)

Tasa de Rechazo de Defectos

Definición: Porcentaje de defectos reportados rechazados como “no es un bug” o “funciona según diseño.”

Fórmula:

Tasa de Rechazo de Defectos % = (Defectos Rechazados / Total de Defectos Reportados) × 100

Ejemplo:

Defectos reportados: 120
Defectos rechazados: 18

Tasa de Rechazo = (18 / 120) × 100 = 15%

Interpretación:

Tasa de Rechazo	Evaluación
0-10%	Excelente — los testers entienden bien los requisitos
10-20%	Aceptable
20-30%	Alta — indica problemas de claridad de requisitos
30%+	Muy alta — ruptura importante de comunicación

Una alta tasa de rechazo indica:

Requisitos poco claros o faltantes
Falta de capacitación de testers
Pobre comunicación entre QA y desarrollo
Testers sin entender el dominio de la aplicación

Elementos de Acción para Alta Tasa de Rechazo:

Mejorar documentación de requisitos
Realizar sesiones de revisión de requisitos con QA
Crear criterios de aceptación de forma colaborativa
Capacitar a QA en el dominio de negocio

Edad del Defecto

Definición: Tiempo desde la creación del defecto hasta el cierre.

Fórmula:

Edad del Defecto (días) = Fecha de Cierre - Fecha de Creación

Seguimiento:

Edad Promedio de Defecto por Severidad

Severidad | Edad Prom | Objetivo | Estado
----------|-----------|----------|--------
Crítica   | 1.5 días  |  1 día   |   ⚠️
Alta      | 3.2 días  |  3 días  |   ✅
Media     | 8.5 días  |  7 días  |   ⚠️
Baja      | 15 días   | 14 días  |   ✅

Reporte de Envejecimiento de Defectos:

Defectos Abiertos por Edad

Rango de Edad | Crítico | Alto | Medio | Bajo | Total
--------------|---------|------|-------|------|-------
0-3 días      |    2    |  5   |   8   |  12  |  27
4-7 días      |    0    |  3   |   6   |   8  |  17
8-14 días     |    0    |  1   |   4   |  10  |  15
15-30 días    |    0    |  0   |   2   |   8  |  10
30+ días      |    0    |  0   |   1   |   5  |   6

→ Alerta: 1 defecto Medio y 5 Bajos mayores a 30 días — revisar y cerrar o diferir

Por Qué Importa la Edad del Defecto:

Los defectos viejos obstruyen el backlog
Indica cuellos de botella en la resolución de defectos
Los defectos obsoletos pueden ya no ser válidos
Afecta la moral del equipo

Métricas de Cobertura de Pruebas

Cobertura de Código

Definición: Porcentaje de código ejecutado por pruebas automatizadas.

Tipos de Cobertura de Código:

1. Cobertura de Sentencias (Cobertura de Línea)

Cobertura de Sentencias % = (Sentencias Ejecutadas / Total de Sentencias) × 100

2. Cobertura de Ramas (Cobertura de Decisión)

Cobertura de Ramas % = (Ramas Ejecutadas / Total de Ramas) × 100

3. Cobertura de Función

Cobertura de Función % = (Funciones Ejecutadas / Total de Funciones) × 100

4. Cobertura de Condición

Cubre todas las sub-expresiones booleanas

Ejemplo:

function applyDiscount(user, cartTotal) {
    if (user.isPremium && cartTotal > 100) {  // 2 condiciones, 4 ramas
        return cartTotal * 0.9;  // 10% descuento
    }
    return cartTotal;
}

Casos de Prueba:

1. isPremium=true, cartTotal=150  → ejecuta rama de descuento ✅
2. isPremium=false, cartTotal=150 → ejecuta rama sin descuento ✅

Cobertura de Sentencias: 100% (todas las líneas ejecutadas)
Cobertura de Ramas: 50% (solo 2 de 4 combinaciones de condición probadas)

Combinaciones faltantes:

- isPremium=true, cartTotal=50
- isPremium=false, cartTotal=50

Objetivos de Cobertura de Código:

Tipo de Proyecto	Cobertura Objetivo
Crítico (médico, aeroespacial)	95-100%
Financiero, sensible a seguridad	85-95%
Aplicaciones comerciales	70-85%
Herramientas internas	60-70%

Dashboard de Cobertura de Código:

Cobertura de Código - Release 3.5

General:        ████████████░░░░░░░░  60% (Objetivo: 80%) ❌

Por Módulo:
Autenticación:  ████████████████████  95% ✅
Checkout:       █████████████████░░░  85% ✅
Búsqueda:       ████████████░░░░░░░░  60% ⚠️
Admin:          ██████░░░░░░░░░░░░░░  30% ❌

→ Acción: Aumentar cobertura de prueba para módulos de Búsqueda y Admin

Advertencia Importante:

Alta cobertura de código ≠ Testing de alta calidad

❌ Mal Ejemplo: 100% cobertura, testing pobre

function withdraw(amount) {
    balance = balance - amount;
    return balance;
}

Prueba:
test('withdraw', () => {
    withdraw(50);  // Ejecuta código, ¡pero sin aserciones!
});

Cobertura: 100%
Calidad: 0% (sin verificación)

✅ Buen Ejemplo: Menor cobertura, mejor testing

test('withdraw reduce saldo correctamente', () => {
    const initialBalance = 100;
    const result = withdraw(50);
    expect(result).toBe(50);
    expect(balance).toBe(50);
});

test('withdraw maneja fondos insuficientes', () => {
    balance = 20;
    expect(() => withdraw(50)).toThrow('Fondos insuficientes');
});

Cobertura: 80% (algunos caminos de error no cubiertos)
Calidad: Alta (aserciones significativas)

Cobertura de Requisitos

Definición: Porcentaje de requisitos cubiertos por casos de prueba.

Fórmula:

Cobertura de Requisitos % = (Requisitos con Pruebas / Total de Requisitos) × 100

Seguimiento con Matriz de Trazabilidad:

Reporte de Cobertura de Requisitos

Categoría           | Total Reqs | Cubiertos | % Cobertura
--------------------|------------|-----------|-------------
Autenticación       |     12     |    12     |    100% ✅
Checkout            |     18     |    16     |     89% ⚠️
Búsqueda de Producto|     10     |    10     |    100% ✅
Dashboard Admin     |     15     |     8     |     53% ❌
Reportes            |      8     |     5     |     63% ⚠️

General:            |     63     |    51     |     81%

Requisitos No Cubiertos:

Requisitos No Cubiertos (12 total)

ID          | Título                          | Prioridad | Razón
------------|---------------------------------|-----------|------------------
REQ-CHK-017 | Checkout exprés para clientes   | Alta      | Caso de prueba pendiente
REQ-CHK-018 | Optimización checkout invitado  | Media     | Diferido a v3.6
REQ-ADM-005 | Importación masiva de usuarios  | Media     | Entorno de prueba no listo
REQ-ADM-008 | Dashboard de analytics avanzado | Baja      | No en alcance

→ Acción: Crear pruebas para REQ-CHK-017 (Alta prioridad)

Cobertura de Ejecución de Pruebas

Definición: Porcentaje de casos de prueba ejecutados del total de pruebas planificadas.

Fórmula:

% de Ejecución de Pruebas = (Pruebas Ejecutadas / Total de Pruebas) × 100

Ejemplo:

Progreso de Ejecución de Pruebas - Sprint 23

Total de Casos de Prueba: 250
Ejecutados: 235
No Ejecutados: 15

Cobertura de Ejecución = (235 / 250) × 100 = 94%

Desglose de Estado:

- Pasadas: 215 (86%)
- Fallidas: 18 (7.2%)
- Bloqueadas: 2 (0.8%)
- No Ejecutadas: 15 (6%)

Ejecución por Prioridad:

Prioridad   | Total | Ejecutadas | No Ejecut. | % Ejecutado
------------|-------|------------|------------|-------------
Crítica     |  50   |     50     |     0      |    100% ✅
Alta        |  80   |     78     |     2      |     98% ✅
Media       |  70   |     65     |     5      |     93% ⚠️
Baja        |  50   |     42     |     8      |     84% ⚠️

→ Insight: Todas las pruebas críticas ejecutadas; 15 pruebas media/baja no ejecutadas (aceptable)

Métricas de Automatización

Cobertura de Automatización de Pruebas

Definición: Porcentaje de casos de prueba automatizados.

Fórmula:

Cobertura de Automatización % = (Pruebas Automatizadas / Total de Pruebas) × 100

Ejemplo:

Total de Casos de Prueba: 500
Automatizadas: 350

Cobertura de Automatización = (350 / 500) × 100 = 70%

Automatización por Tipo de Prueba:

Tipo de Prueba      | Total | Automatizadas | % Automatizado | Objetivo
--------------------|-------|---------------|----------------|----------
Pruebas Smoke       |  20   |      20       |      100%      |   100% ✅
Pruebas Regresión   | 300   |     270       |       90%      |    85% ✅
Pruebas Integración |  80   |      50       |       62%      |    70% ⚠️
Pruebas UI          | 100   |      10       |       10%      |    30% ❌

→ Acción: Enfocar esfuerzos de automatización en pruebas de Integración y UI

Pirámide de Automatización de Pruebas:

Distribución ideal siguiendo la estrategia de pirámide de automatización de pruebas:

              /\
             /  \    E2E: 10% automatizado (10 de 100)
            /    \
           /------\
          /        \  Integración: 70% automatizado (56 de 80)
         /          \
        /------------\
       /              \ Unitaria: 90% automatizado (450 de 500)
      /________________\

Distribución Actual de Automatización:

- Unitaria: 90% ✅
- Integración: 70% ✅
- E2E: 10% ⚠️ (objetivo: 10-20%)

→ La estructura general es saludable

ROI de Automatización

Definición: Retorno de inversión de la automatización de pruebas.

Cálculo:

ROI de Automatización = (Ahorros de Automatización - Costo de Automatización) / Costo de Automatización

Donde:
Ahorros = (Tiempo ahorrado por ejecución × Número de ejecuciones × Tarifa por hora)
Costo = Tiempo de desarrollo + Tiempo de mantenimiento

Ejemplo:

Suite de Pruebas: Pruebas de regresión
- Tiempo de ejecución manual: 40 horas por ejecución
- Tiempo de ejecución automatizada: 2 horas por ejecución
- Tiempo ahorrado: 38 horas por ejecución
- Ejecuciones por mes: 20 (diarias + bajo demanda)
- Tarifa horaria QA: $50

Ahorros por mes = 38 horas × 20 ejecuciones × $50 = $38,000

Costos de automatización:

- Desarrollo inicial: 200 horas × $50 = $10,000
- Mantenimiento mensual: 10 horas × $50 = $500

Primer mes:
ROI = ($38,000 - $10,500) / $10,500 = 262% (punto de equilibrio en ~8 días)

Meses subsiguientes:
ROI = ($38,000 - $500) / $500 = 7400%

→ ROI extremadamente positivo; automatización altamente valiosa

Tasa de Éxito de Automatización

Definición: Porcentaje de pruebas automatizadas que pasan.

Fórmula:

Tasa de Éxito de Automatización % = (Pruebas Automatizadas Pasadas / Pruebas Automatizadas Ejecutadas) × 100

Tasa de Éxito Saludable: 95%+ indica automatización estable

Problemas de Tasa de Éxito Baja:

Tendencia de Tasa de Éxito de Automatización

Semana 1: 98% ✅
Semana 2: 96% ✅
Semana 3: 78% ❌
Semana 4: 65% ❌

→ Alerta: Caída significativa — investigar pruebas inestables o problemas de aplicación

Análisis de Pruebas Inestables:

Reporte de Pruebas Inestables (Pruebas con <100% tasa de éxito en últimas 30 ejecuciones)

Nombre de Prueba                      | Ejec. | Éxitos | % Éxito | Inestabilidad
--------------------------------------|-------|--------|---------|---------------
test_checkout_payment_processing      |  30   |   22   |   73%   | Alta ❌
test_search_autocomplete              |  30   |   27   |   90%   | Media ⚠️
test_user_login_success               |  30   |   30   |  100%   | Ninguna ✅

→ Acción: Corregir o poner en cuarentena pruebas inestables

Causas de Pruebas Inestables:

Condiciones de carrera y problemas de sincronización
Dependencia de servicios externos
Problemas de datos de prueba
Inconsistencias de entorno
Esperas codificadas (sleep) en lugar de esperas dinámicas

Métricas de Velocidad y Burndown

Velocidad

Definición: Cantidad de trabajo (puntos de historia o casos de prueba) completados por sprint/iteración.

Fórmula:

Velocidad = Puntos de Historia Completados / Sprint

O para testing:
Velocidad de Prueba = Casos de Prueba Ejecutados / Día

Ejemplo: Velocidad del Equipo

Velocidad de Sprint - Equipo Scrum Alpha

Sprint | Puntos Planificados | Puntos Completados | Velocidad
-------|---------------------|--------------------|-----------
21     |         40          |         35         |     35
22     |         42          |         38         |     38
23     |         45          |         42         |     42
24     |         45          |         40         |     40

Velocidad Promedio: 38.75 puntos de historia por sprint

→ Usar para planificación de sprint: Planificar ~39 puntos para próximo sprint

Velocidad de Ejecución de Pruebas:

Velocidad Diaria de Ejecución de Pruebas - Release 3.5

Día  | Pruebas Ejecutadas | Velocidad (pruebas/día)
-----|--------------------|--------------------------
1    |        25          |          25
2    |        30          |          28 (prom)
3    |        35          |          30 (prom)
4    |        28          |          30 (prom)
5    |        32          |          30 (prom)

Velocidad Promedio: 30 pruebas/día

Pruebas Restantes: 100
Días Estimados para Completar: 100 / 30 = 3.3 días

→ En camino de terminar para Día 8 (objetivo: Día 10)

Gráfico Burndown

Definición: Representación visual del trabajo restante en el tiempo.

Burndown de Ejecución de Pruebas:

Gráfico Burndown de Ejecución de Pruebas

Pruebas
250 |●
    |  ●
200 |    ●
    |      ●
150 |        ●
    |          ● ● (real)
100 |            ●
    |              ● ● (proyectado)
50  |                ●
    |                  ●
0   |____________________●________
    Día 1  3  5  7  9  11  13  15

Leyenda:
● Burndown planificado (lineal)
● Burndown real

Estado: Adelantado del cronograma ✅

Interpretación del Burndown:

Escenario 1: Adelantado del Cronograma
  |●
  |  ●●
  |     ●●● (real por encima del planificado)
  |        ●●●
  |___________
→ Equipo ejecutando más rápido de lo planificado

Escenario 2: Atrasado del Cronograma
  |●
  |  ●
  |    ●
  |      ● (real por debajo del planificado)
  |        ●●●●
  |___________
→ Equipo más lento de lo planificado — investigar bloqueadores

Escenario 3: Aumento de Alcance
  |●
  |  ●
  |    ● ↑ (línea sube — alcance agregado)
  |      ●
  |        ●●
  |___________
→ Nuevas pruebas agregadas a mitad de sprint

Burndown de Defectos:

Burndown de Defectos Abiertos

Defectos
50  |●
    |  ●
40  |    ●
    |      ●●
30  |        ●
    |          ●● (real)
20  |            ●
    |              ●● (objetivo)
10  |                ●
    |                  ●
0   |____________________●________
    Día 1  3  5  7  9  11  13  15

Actual: 12 defectos abiertos
Objetivo: 0 para Día 15
→ En camino de cerrar todos los defectos antes del lanzamiento

Diagrama de Flujo Acumulativo (CFD)

Definición: Gráfico de áreas apiladas que muestra elementos de trabajo en diferentes estados en el tiempo.

Estado de Casos de Prueba - Diagrama de Flujo Acumulativo

Pruebas
250 |
    |           [No Iniciado]
200 |      ___________________
    |     /   [En Progreso]  /
150 |    /___________________/
    |   /      [Pasado]     /
100 |  /___________________/
    | /      [Fallado]     /
50  |/___________________/
    |_____________________
    Día 1    5    10    15

Insights:

- "No Iniciado" reduciéndose ✅
- "Pasado" creciendo constantemente ✅
- Banda "Fallado" delgada (pocas fallas) ✅
- Ancho de "En Progreso" consistente (buen flujo) ✅

→ Flujo saludable de ejecución de pruebas

Creación de Dashboards

Principios de Dashboards Efectivos

1. Conoce a Tu Audiencia

Audiencia	Enfoque	Métricas
Ejecutivos	Estado de calidad de alto nivel	Salud general, fuga de defectos, preparación para lanzamiento
Product Managers	Calidad de funcionalidades, riesgos	Cobertura de requisitos, distribución de defectos por funcionalidad
Gerentes QA	Productividad del equipo, tendencias	Velocidad, cobertura de automatización, progreso de ejecución de pruebas
Desarrolladores	Info de defectos accionable	Defectos por módulo, edad, severidad, defectos abiertos asignados
Equipo QA	Ejecución día a día	Estado de ejecución de pruebas, bloqueadores, progreso diario

2. Sigue Mejores Prácticas de Diseño

Simplicidad: Evita el desorden; un insight por gráfico
Jerarquía visual: Métricas más importantes en la parte superior izquierda
Accionable: Incluye “qué hacer” basado en métricas
Tiempo real: Dashboards de auto-actualización
Codificación de colores: Verde (bueno), amarillo (advertencia), rojo (crítico)
Tendencias: Muestra tendencias históricas, no solo instantánea actual

3. Responde Preguntas Clave

Cada dashboard debe responder:

¿Cuál es el estado? (Estado actual)
¿Esto es bueno o malo? (Objetivos/benchmarks)
¿Qué cambió? (Tendencias)
¿Qué debo hacer? (Acciones)

Ejemplo de Dashboard Ejecutivo

┌──────────────────────────────────────────────────────────────┐
│  Dashboard de Calidad - Release 3.5                15 Oct    │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│  Salud General del Release: ●●●●○ 85/100  [Objetivo: 90] ⚠️ │
│                                                              │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐      │
│  │ Ejec Pruebas │  │ Defectos     │  │ Automatización│     │
│  │   94%        │  │ Abiertos: 12 │  │    70%       │      │
│  │  ✅ En ruta  │  │  ⚠️ 2 Altos  │  │  ✅ Objetivo │      │
│  └──────────────┘  └──────────────┘  └──────────────┘      │
│                                                              │
│  Tendencia de Defectos (Últimos 7 Días)                     │
│  50 ●                                                        │
│  40   ●                                                      │
│  30     ●●                                                   │
│  20       ●●                                                 │
│  10          ●●● (Actual: 12)                               │
│   0 ─────────────────────                                   │
│     1  2  3  4  5  6  7                                     │
│                                                              │
│  🚨 Riesgos y Acciones:                                     │
│  • 2 defectos Alta severidad abiertos (>3 días antiguos)   │
│    → Equipo dev trabajando en corrección, ETA: 16 Oct      │
│  • Prueba de rendimiento pendiente (programada: 16 Oct)    │
│    → En ruta                                                 │
│                                                              │
│  📅 Estado de Release: Decisión Go / No-Go: 17 Oct         │
└──────────────────────────────────────────────────────────────┘

Ejemplo de Dashboard de Gerente QA

┌──────────────────────────────────────────────────────────────┐
│  Dashboard de Equipo QA - Sprint 23                Semana 2  │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│  Progreso de Sprint                                          │
│  ████████████████░░░░  80% completado (8 de 10 días)        │
│                                                              │
│  Velocidad de Ejecución de Pruebas: 30 pruebas/día (Obj: 25)│
│                                                        ✅    │
│  ┌─────────────────────────────────────────────────┐        │
│  │ Burndown de Ejecución de Pruebas                │        │
│  │ 250│●                                            │        │
│  │    │  ●●                                         │        │
│  │ 150│     ●●● ← real                             │        │
│  │    │        ●●● ← planificado                   │        │
│  │  50│           ●●                                │        │
│  │   0└─────────────────                           │        │
│  │     1   3   5   7   9  11                       │        │
│  └─────────────────────────────────────────────────┘        │
│                                                              │
│  Productividad del Equipo                                    │
│  ┌─────────────────────────────────────────┐                │
│  │ Ingeniero QA │ Pruebas Ejec│ Defectos Enc│               │
│  ├─────────────────────────────────────────┤                │
│  │ Alice        │     65      │      12     │               │
│  │ Bob          │     58      │       9     │               │
│  │ Carol        │     62      │      11     │               │
│  │ David        │     50      │       6     │  ⚠️ Bajo     │
│  └─────────────────────────────────────────┘                │
│                                                              │
│  Bloqueadores: 2 pruebas bloqueadas por BUG-456             │
│  Acción: Hacer seguimiento con equipo de desarrollo         │
└──────────────────────────────────────────────────────────────┘

Ejemplo de Dashboard de Desarrollador

┌──────────────────────────────────────────────────────────────┐
│  Dashboard de Desarrollador - Mis Defectos      Juan García  │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│  Asignados a Mí: 5 defectos                                 │
│                                                              │
│  ┌────────────────────────────────────────────────┐         │
│  │ ID       │ Severidad│ Edad │ Módulo    │ Estado│         │
│  ├────────────────────────────────────────────────┤         │
│  │ BUG-123  │ Alta     │ 4d   │ Checkout  │En Prog│         │
│  │ BUG-127  │ Media    │ 2d   │ Checkout  │ Nuevo │         │
│  │ BUG-130  │ Media    │ 1d   │ Auth      │ Nuevo │         │
│  │ BUG-135  │ Baja     │ 3d   │ UI        │En Prog│         │
│  │ BUG-140  │ Baja     │ 0d   │ Búsqueda  │ Nuevo │         │
│  └────────────────────────────────────────────────┘         │
│                                                              │
│  🚨 Alerta: BUG-123 tiene 4 días de antigüedad (Alta sev)  │
│  → Resolución objetivo: <3 días                             │
│                                                              │
│  Mi Módulo: Checkout                                        │
│  - Defectos abiertos: 8                                     │
│  - Densidad de defectos: 8.2 por KLOC ⚠️ (Prom equipo: 4.5)│
│  - Pruebas fallidas: 3                                      │
│                                                              │
│  Cobertura de Código:                                       │
│  ████████████████████  85% (Objetivo: 80%) ✅               │
│                                                              │
└──────────────────────────────────────────────────────────────┘

Herramientas para Creación de Dashboards

Herramientas de BI y Dashboards:

Tableau: Visualizaciones avanzadas, grado empresarial
Power BI: Ecosistema Microsoft, buena integración con Excel
Grafana: Código abierto, excelente para monitoreo en tiempo real
Kibana: Parte del stack ELK, genial para análisis de logs

Herramientas de Gestión de Pruebas con Dashboards Integrados:

TestRail: Dashboards de prueba pre-construidos
qTest: Dashboards personalizables
Xray (Jira): Dashboards integrados con Jira
Zephyr: Dashboards de ejecución de pruebas

Dashboards Personalizados:

Google Data Studio: Gratis, se integra con Google Sheets
Redash: Código abierto, dashboards basados en SQL
Metabase: Código abierto, fácil de usar

Excel/Google Sheets:

Prototipado rápido
Bueno para equipos pequeños
Capacidades de tiempo real limitadas

Construyendo Tu Primer Dashboard

Paso 1: Define Objetivos

Preguntas a responder:

¿Quién es la audiencia?
¿Qué decisiones tomarán con este dashboard?
¿Qué acciones deben impulsar las métricas?

Paso 2: Selecciona Métricas

Elige 5-7 métricas clave (¡no 50!)

Ejemplo para Gerente QA:

Progreso de ejecución de pruebas (%)
Defectos abiertos por severidad
Tendencia burndown de defectos
Cobertura de automatización (%)
Velocidad de prueba (pruebas/día)

Paso 3: Recopila Datos

Fuentes de datos:

Herramienta de gestión de pruebas (TestRail, Xray)
Seguimiento de defectos (Jira)
Integración de pipeline CI/CD (Jenkins, GitLab)
Cobertura de código (SonarQube, Codecov)
Scripts personalizados

Paso 4: Diseña el Layout

Crea wireframe de tu dashboard:

┌─────────────────────────────────────┐
│ Encabezado: Título, Fecha, Estado   │
├─────────────────────────────────────┤
│ [Métrica Clave 1] [MC 2] [MC 3]     │ ← Tarjetas con números grandes
├─────────────────────────────────────┤
│ [Gráfico Principal: Tendencia o    ]│ ← Visualización principal
│ [                    Burndown      ]│
├──────────────────┬──────────────────┤
│ [Gráfico 2]      │ [Gráfico 3]      │ ← Detalles de soporte
├──────────────────┴──────────────────┤
│ 🚨 Alertas y Elementos de Acción    │ ← Qué necesita atención
└─────────────────────────────────────┘

Paso 5: Implementa e Itera

Construye versión inicial
Obtén retroalimentación de usuarios
Refina basado en uso real
Agrega/elimina métricas según sea necesario

Anti-Patrones y Trampas de Métricas

Anti-Patrón 1: Métricas de Vanidad

Problema: Rastrear métricas que se ven bien pero no impulsan acción.

Ejemplo:

Total de casos de prueba escritos: 5000 (¿Y qué? ¿Son buenas pruebas? ¿Se ejecutan?)

Solución: Enfócate en métricas accionables

Tasa de ejecución de pruebas: 94% (muestra progreso)
Tasa de éxito de pruebas: 92% (muestra calidad)

Anti-Patrón 2: Medir Lo Incorrecto

Problema: Optimizar para la métrica en lugar de la calidad.

Ejemplo:

Métrica: Número de defectos encontrados por tester
Resultado: Los testers reportan problemas triviales para aumentar números

Mejor Métrica: Densidad de defectos por módulo (se enfoca en calidad, no cantidad)

Anti-Patrón 3: Demasiadas Métricas

Problema: Dashboard con 30 métricas — nadie lo usa.

Solución: 5-7 métricas clave por dashboard; crear dashboards específicos por rol.

Anti-Patrón 4: Sin Contexto

Problema: Métrica sin objetivo o tendencia.

❌ Malo: Cobertura de prueba: 65%
   (¿Esto es bueno o malo? ¿Mejorando o declinando?)

✅ Bueno: Cobertura de prueba: 65% (Objetivo: 80%, era 60% último sprint ↑)

Anti-Patrón 5: Datos Obsoletos

Problema: Dashboard no actualizado, nadie confía en él.

Solución: Automatiza recopilación de datos y actualización.

Anti-Patrón 6: Sin Plan de Acción

Problema: Las métricas muestran problemas, pero nadie sabe qué hacer.

Solución: Cada métrica debe tener:

Valor objetivo
Valor actual
Tendencia (↑↓→)
Acción si está fuera del objetivo

Conclusión: Construyendo una Cultura de Calidad Basada en Métricas

Las métricas efectivas de testing transforman QA de centro de costos a generador de valor. Puntos clave:

1. Elige Métricas Sabiamente

Alinea con objetivos de negocio
Hazlas accionables
Balancea indicadores líderes (predictivos) y rezagados (históricos)

2. Métricas Esenciales a Rastrear

Métricas de defectos: Densidad, fuga, DRE, edad
Métricas de cobertura: Código, requisitos, automatización
Métricas de progreso: Velocidad, burndown, % de ejecución
Métricas de efectividad: ROI de automatización, tasas de éxito

3. Construye Dashboards Efectivos

Conoce a tu audiencia
Mantenlo simple (5-7 métricas clave)
Proporciona contexto (objetivos, tendencias)
Hazlo accionable
Automatiza recopilación de datos

4. Evita Trampas Comunes

No rastrees métricas de vanidad
No crees sobrecarga de métricas
No olvides actuar sobre insights
No manipules las métricas

5. Mejora Continua

Revisa métricas regularmente
Retira métricas que no impulsan acción
Agrega nuevas métricas a medida que evolucionan las necesidades (incluyendo métricas de prueba potenciadas por IA)
Celebra mejoras

Próximos Pasos:

Audita tus métricas actuales — ¿cuáles son accionables?
Crea un dashboard simple esta semana
Elige 3-5 KPIs alineados con tus objetivos de calidad
Automatiza la recopilación de datos donde sea posible
Comparte métricas en revisiones de sprint y retrospectivas
Usa métricas para impulsar mejora, no culpa

Recuerda: Las métricas son medios para un fin, no el fin en sí mismo. El objetivo es software de mayor calidad, mejor rendimiento del equipo y clientes satisfechos. Las métricas iluminan el camino—pero aún necesitas caminarlo.

¡Comienza a medir, comienza a mejorar, comienza a entregar mejor calidad!

Ver También

Test Summary Report - Comunicar métricas a stakeholders
Test Plan and Strategy - Definir métricas en el plan
Quality Dashboard Documentation - Visualización de métricas
Defect Life Cycle Management - Métricas de defectos
Test Coverage Report - Métricas de cobertura detalladas

Métricas y KPIs de Testing: Midiendo Calidad y Progreso

Introducción: Por Qué Importan las Métricas de Testing #

El Desafío Sin Métricas #

El Poder de las Métricas #

Métricas vs KPIs #

Métricas de Defectos #

Densidad de Defectos #

Fuga de Defectos #

Eficiencia de Eliminación de Defectos (DRE) #

Tasa de Rechazo de Defectos #

Edad del Defecto #

Métricas de Cobertura de Pruebas #

Cobertura de Código #

Cobertura de Requisitos #

Cobertura de Ejecución de Pruebas #

Métricas de Automatización #

Cobertura de Automatización de Pruebas #

ROI de Automatización #

Tasa de Éxito de Automatización #

Métricas de Velocidad y Burndown #

Velocidad #

Gráfico Burndown #

Diagrama de Flujo Acumulativo (CFD) #

Creación de Dashboards #

Principios de Dashboards Efectivos #

Ejemplo de Dashboard Ejecutivo #

Ejemplo de Dashboard de Gerente QA #

Ejemplo de Dashboard de Desarrollador #

Herramientas para Creación de Dashboards #

Construyendo Tu Primer Dashboard #

Anti-Patrones y Trampas de Métricas #

Anti-Patrón 1: Métricas de Vanidad #

Anti-Patrón 2: Medir Lo Incorrecto #

Anti-Patrón 3: Demasiadas Métricas #

Anti-Patrón 4: Sin Contexto #

Anti-Patrón 5: Datos Obsoletos #

Anti-Patrón 6: Sin Plan de Acción #

Conclusión: Construyendo una Cultura de Calidad Basada en Métricas #

Ver También #

Recursos Oficiales #

See Also #

Preguntas frecuentes

Introducción: Por Qué Importan las Métricas de Testing

El Desafío Sin Métricas

El Poder de las Métricas

Métricas vs KPIs

Métricas de Defectos

Densidad de Defectos

Fuga de Defectos

Eficiencia de Eliminación de Defectos (DRE)

Tasa de Rechazo de Defectos

Edad del Defecto

Métricas de Cobertura de Pruebas

Cobertura de Código

Cobertura de Requisitos

Cobertura de Ejecución de Pruebas

Métricas de Automatización

Cobertura de Automatización de Pruebas

ROI de Automatización

Tasa de Éxito de Automatización

Métricas de Velocidad y Burndown

Velocidad

Gráfico Burndown

Diagrama de Flujo Acumulativo (CFD)

Creación de Dashboards

Principios de Dashboards Efectivos

Ejemplo de Dashboard Ejecutivo

Ejemplo de Dashboard de Gerente QA

Ejemplo de Dashboard de Desarrollador

Herramientas para Creación de Dashboards

Construyendo Tu Primer Dashboard

Anti-Patrones y Trampas de Métricas

Anti-Patrón 1: Métricas de Vanidad

Anti-Patrón 2: Medir Lo Incorrecto

Anti-Patrón 3: Demasiadas Métricas

Anti-Patrón 4: Sin Contexto

Anti-Patrón 5: Datos Obsoletos

Anti-Patrón 6: Sin Plan de Acción

Conclusión: Construyendo una Cultura de Calidad Basada en Métricas

Ver También

Recursos Oficiales

See Also