Las métricas de testing ayudan a observar el avance, los riesgos y ciertos aspectos de la calidad del proceso de pruebas. Permiten responder preguntas como: cuántos casos se ejecutaron, cuántos fallaron, qué defectos siguen abiertos o qué requisitos tienen pruebas asociadas.
Sin embargo, una métrica mal interpretada puede generar conclusiones incorrectas. Por ejemplo, tener muchos casos ejecutados no significa necesariamente haber probado lo importante. Tener alta cobertura de código tampoco garantiza ausencia de defectos.
En este tema veremos métricas básicas de testing y cobertura, junto con sus límites y buenas prácticas.
Una métrica es una medida que aporta información sobre un aspecto del proceso o producto. En testing, las métricas pueden referirse a ejecución de pruebas, defectos, cobertura, tiempo, estabilidad o riesgo.
Ejemplos simples:
Una métrica no reemplaza el análisis. Es una señal que necesita contexto.
Las métricas pueden servir para:
El objetivo no es juntar números por costumbre, sino obtener información útil para decidir.
Las métricas de ejecución muestran el estado de los casos de prueba durante una ronda de testing.
Ejemplos:
Estas métricas ayudan a saber cuánto se ejecutó, pero no indican por sí solas si se cubrieron los riesgos más importantes.
| Estado | Cantidad | Interpretación inicial |
|---|---|---|
| Aprobados | 70 | Casos ejecutados sin diferencias observadas. |
| Fallidos | 10 | Casos con diferencias entre esperado y obtenido. |
| Bloqueados | 5 | No pudieron ejecutarse por ambiente, datos u otra dependencia. |
| No ejecutados | 15 | Pendientes de ejecución. |
Si los 15 casos no ejecutados son de bajo riesgo, la situación es distinta a si incluyen pagos o seguridad. Por eso hace falta contexto.
Las métricas de defectos ayudan a analizar problemas encontrados.
Ejemplos:
Estas métricas ayudan a detectar áreas problemáticas y entender si la versión está estabilizándose.
Una métrica útil es la distribución de defectos por severidad.
| Severidad | Cantidad | Riesgo |
|---|---|---|
| Crítica | 1 | Puede bloquear publicación. |
| Alta | 4 | Requiere análisis y corrección prioritaria. |
| Media | 8 | Puede planificarse según impacto. |
| Baja | 12 | Impacto menor, pero debe gestionarse. |
No es lo mismo tener 25 defectos menores que tener 2 defectos críticos. La severidad cambia la interpretación.
Analizar defectos por módulo puede revelar zonas de riesgo.
Ejemplo:
Si compras y pagos concentran la mayoría de defectos, conviene investigar si hay problemas de requisitos, diseño, integración o cobertura de pruebas en esas áreas.
Un defecto reabierto es un defecto que se marcó como corregido, pero volvió a fallar en retest o reapareció después.
Una cantidad alta de defectos reabiertos puede indicar:
No debe usarse para culpar personas, sino para mejorar análisis, comunicación y verificación de correcciones.
La cobertura indica qué parte de algo fue alcanzada por las pruebas. Ese "algo" puede ser requisitos, funcionalidades, casos de uso, riesgos, código o combinaciones de datos.
Ejemplos:
La cobertura ayuda a saber qué se revisó y qué puede haber quedado fuera.
La cobertura de requisitos indica qué requisitos tienen pruebas asociadas.
Ejemplo:
| Requisito | Casos asociados | Estado |
|---|---|---|
| R-LOGIN-01 | CP-LOGIN-001, CP-LOGIN-002 | Cubierto |
| R-PAGO-01 | CP-PAGO-001, CP-PAGO-002, CP-PAGO-003 | Cubierto |
| R-REPORTE-04 | Sin casos asociados | No cubierto |
Que un requisito tenga casos asociados no garantiza que esté bien probado, pero ayuda a detectar requisitos sin pruebas.
La cobertura funcional analiza qué funcionalidades o flujos fueron probados.
Ejemplo para una tienda en línea:
Esta información ayuda a comunicar zonas no probadas o cubiertas de forma limitada.
La cobertura de código indica qué porcentaje del código fue ejecutado por pruebas automatizadas. Puede medirse por líneas, sentencias, ramas, funciones o condiciones.
Ejemplos:
La cobertura de código es útil, pero debe interpretarse con cuidado. Un porcentaje alto no garantiza que las pruebas verifiquen correctamente los resultados.
Una prueba puede ejecutar una línea de código y aun así no verificar si el resultado es correcto. Por eso la cobertura mide ejecución, no calidad de las aserciones.
Ejemplo conceptual:
La cobertura de código responde "qué código fue ejecutado", no "qué comportamiento fue validado correctamente".
La cobertura de riesgos analiza si los riesgos principales tienen pruebas asociadas.
Ejemplo:
Esta cobertura suele ser más útil para decisiones que una simple cantidad de casos ejecutados.
También pueden medirse tiempos relacionados con testing y defectos:
Estas métricas ayudan a detectar cuellos de botella. Por ejemplo, si muchos casos quedan bloqueados por datos, quizá el problema no sea la ejecución sino la preparación del ambiente.
Algunas métricas pueden generar conclusiones equivocadas si se usan sin contexto.
| Métrica | Riesgo de mala interpretación |
|---|---|
| Cantidad de casos de prueba | Más casos no siempre significa mejor cobertura o mayor calidad. |
| Porcentaje de casos aprobados | Puede ser alto aunque no se hayan probado riesgos críticos. |
| Cantidad de defectos encontrados | Más defectos puede indicar mala calidad, pero también testing más profundo. |
| Cobertura de código | Alta cobertura no garantiza buenas verificaciones. |
Las métricas deben interpretarse junto con contexto, riesgo y criterio técnico.
Una buena métrica ayuda a tomar decisiones. Por ejemplo:
Estas métricas no solo describen actividad; ayudan a decidir qué hacer.
| Suite ejecutada | Regresión crítica versión 2.4.0 |
|---|---|
| Casos ejecutados | 45 de 50 |
| Aprobados | 40 |
| Fallidos | 3 |
| Bloqueados | 2 |
| Defectos críticos abiertos | 0 |
| Riesgo pendiente | No se ejecutaron dos casos de pago por indisponibilidad del sandbox. |
El informe incluye números y contexto. Eso lo vuelve más útil para decidir.
Al usar métricas de testing, algunos errores frecuentes son:
Para usar métricas de forma útil conviene:
Las métricas y la cobertura ayudan a entender el estado del testing, pero no reemplazan el criterio profesional. Un número aislado puede ser engañoso si no se acompaña de contexto, riesgos y análisis.
Las mejores métricas son las que ayudan a decidir: qué falta probar, qué defectos bloquean, qué riesgos siguen abiertos y dónde conviene enfocar el esfuerzo.
En el próximo tema estudiaremos trazabilidad entre requisitos, pruebas y defectos, una práctica que permite conectar lo que se pidió, lo que se probó y lo que falló.