Un dashboard que muestra un ochenta y ocho por ciento de cobertura puede generar una falsa sensación de seguridad. Si detrás de ese número hay defectos críticos abiertos y casos bloqueados, el porcentaje no refleja la realidad del producto. Un número sin una decisión asociada es solo ruido [0:22]. Aquí se aborda cómo pasar de reportar actividad a construir herramientas de decisión reales dentro de un sprint de pruebas.
¿Cómo saber si las pruebas van a terminar a tiempo?
Las métricas de progreso responden la pregunta más urgente de cualquier ciclo de pruebas: ¿vamos a terminar a tiempo? [1:02]. Dos indicadores marcan el pulso del avance.
La cobertura de ejecución se calcula dividiendo los casos ejecutados entre los casos planificados, multiplicado por cien. Si planificaste cien pruebas y corriste ochenta, tienes un ochenta por ciento. Es como una lista de tareas: planificar pone ítems, ejecutar los tacha [1:14].
La tasa diaria de ejecución divide los casos corridos entre los días transcurridos. Si en siete días ejecutaste ciento setenta y cinco casos, tu velocidad promedio es de veinticinco por día [1:38]. Funciona como un viaje por carretera: si te faltan veinticinco kilómetros pero tu destino cierra en treinta minutos, sabes que tienes un problema.
¿Por qué rastrear el avance cada día?
Esperar al último día para revisar el progreso es como mirar el indicador de combustible solo cuando el carro se detiene [2:08]. El seguimiento diario permite detectar desviaciones antes de que sea tarde.
Pero la tasa diaria puede engañar. No todos los casos pesan igual: un flujo completo de pagos no equivale a verificar un campo de texto [2:22]. Si el porcentaje sube pero los casos por día bajan, el equipo entró en pruebas más complejas. La solución es complementar el conteo con horas invertidas contra horas presupuestadas. Si gastaste sesenta por ciento de las horas pero solo completaste cuarenta por ciento de los casos, lo que queda es más difícil de lo previsto [2:44].
¿El producto mejora o empeora sprint a sprint?
Las métricas de calidad revelan la dirección en la que se mueve el producto. Aquí entran indicadores que van más allá del simple conteo de bugs.
¿Qué dice la distribución de defectos por severidad?
Ya se conocen los niveles — crítica, alta, media, baja — pero lo que importa es cómo se distribuyen [3:08]. El Índice de Severidad de Defectos asigna pesos: crítico vale diez, alto cinco, medio tres, bajo uno. Se multiplica cada defecto por su peso, se suma y se divide entre el total de defectos.
- Cinco críticos más diez altos más veinte medios dan ciento sesenta puntos entre treinta y cinco defectos.
- El resultado es un índice de cuatro punto cincuenta y siete [3:30].
- Un índice alto señala problemas serios.
- Si la gráfica se desplaza hacia defectos bajos con el tiempo, el producto se estabiliza.
Cuando los defectos críticos suben a mitad de sprint, se aplica la fórmula de riesgo: probabilidad por impacto [4:22]. Un pico de críticos indica que ambas dimensiones empeoraron. Ahí se actualiza el plan de riesgo, se mueven esas áreas al inicio de la cola de ejecución y se redirigen recursos.
¿Qué revela la tasa de reapertura sobre las correcciones?
La tasa de reapertura se obtiene dividiendo defectos reabiertos entre defectos corregidos [3:56]. Es como un taller mecánico que dice haber arreglado los frenos, pero dos días después fallan de nuevo. Una tasa alta indica:
- Análisis incompleto de causa raíz.
- Verificación pobre de la corrección.
- Diferencias entre ambientes de desarrollo y pruebas.
¿Por qué las métricas mal usadas crean más daño que valor?
Cuando un equipo siente que las métricas evalúan personas y no procesos, esconde problemas o infla números [4:50]. Es como una escuela que rastrea tasas de aprobación: un buen director pregunta si el material se enseñó bien, mientras que un mal director señala al profesor que falló. El primero mejora el currículo; el segundo crea miedo.
Para cada métrica la pregunta correcta es: ¿qué está mejorando, qué empeora, qué nos sorprendió? [5:18]. Si la fuga de defectos sube, no se busca qué tester falló, sino dónde hay huecos en la cobertura. Y si una métrica no responde a la pregunta "¿qué haríamos diferente?", no vale la pena rastrearla.
- Mantén entre cinco y siete métricas centrales.
- Más que eso y las señales se pierden en ruido [5:38].
El ejercicio mental que se plantea es revelador: con setenta y seis casos, cuarenta y seis aprobados, ocho fallidos, seis bloqueados y dos defectos críticos abiertos, el equipo detiene funcionalidades nuevas y ataca los críticos primero [5:52]. Un defecto crítico es una alarma de incendio: no sigues almorzando. Los bloqueados se escalan porque representan riesgo desconocido.
Tu actualización de estado se construye con dos métricas y un riesgo: tasa de aprobación para decidir si el producto es estable para release, tasa de fallos para saber si desarrollo debe pausar features, y casos bloqueados para evaluar si extender el calendario [6:16].
Para cada métrica que presentes, hazte una verificación final: ¿puedes nombrar la decisión que respalda? [6:34]. Si la respuesta es sí, tu status dejó de ser un reporte de actividad y se convirtió en una herramienta de decisión. ¿Qué métricas usa tu equipo hoy y qué decisiones respaldan realmente?
