Métricas de automatización que sí dicen algo (y las que solo hacen ruido)
Qué medir para saber si tu automatización aporta valor, qué indicadores engañan a la dirección y cómo montar un informe distinto para cada audiencia.
La métrica que todo el mundo pide y casi nadie debería usar
El "porcentaje de casos de prueba automatizados" es el indicador favorito de los comités y uno de los peores que existen. Sube automatizando lo fácil, no dice nada sobre el riesgo cubierto y premia exactamente el comportamiento que hace insostenible una suite: añadir pruebas sin criterio.
Ocurre lo mismo con el número de scripts o de ejecuciones: miden actividad, no resultado. Y como toda métrica que se convierte en objetivo, acaban optimizándose a costa de lo que de verdad importaba.
Qué medir, según lo que quieras saber
| Pregunta | Métrica útil |
|---|---|
| ¿La suite es fiable? | Tasa de fallos falsos y tasa de inestabilidad por prueba |
| ¿Cuánto cuesta mantenerla? | Tiempo medio de reparación de un test roto y horas dedicadas a mantenimiento por sprint |
| ¿Da feedback a tiempo? | Tiempo hasta el primer resultado y duración por etapa |
| ¿Detecta algo? | Defectos encontrados por la suite y defectos escapados a producción |
| ¿Cubre lo importante? | Riesgos de producto cubiertos por pruebas automatizadas |
| ¿Merece la pena? | Coste de creación y mantenimiento frente a ejecuciones ahorradas |
La tendencia importa más que el valor absoluto
Un 8% de fallos falsos no es bueno ni malo por sí solo: lo relevante es si hace dos meses era del 2%. Una duración de 50 minutos tampoco dice mucho hasta que ves que crece un 10% cada semana. Las dos señales juntas —tiempo que sube y fiabilidad que baja— describen una solución que se está degradando, y avisan mucho antes de que el equipo empiece a desactivar pruebas.
Por eso el informe útil es el que muestra series temporales y no la foto de la última ejecución, y por eso conviene guardar de cada ejecución su versión del sistema, su entorno, sus datos y sus evidencias: sin ese contexto, la serie no se puede interpretar.
Un informe por audiencia
- Para el equipo: detalle por prueba, evidencias del fallo, agrupación por causa y qué está en cuarentena. Publicado automáticamente tras cada ejecución.
- Para la gestión del proyecto: estado de los flujos críticos, riesgo abierto, tendencia de duración y qué bloquea la entrega. Sin trazas de excepción.
- Para la dirección: dos o tres cifras con su tendencia y una conclusión explícita sobre si se puede publicar y con qué riesgo.
Y una regla de honestidad que ahorra disgustos: si hay pruebas excluidas o en cuarentena, el informe lo dice. Un verde que oculta veinte pruebas desactivadas es peor que un rojo, porque genera decisiones basadas en información falsa.
Análisis de fallos: agrupar antes de investigar
Cuando una ejecución nocturna deja ciento veinte pruebas en rojo, el impulso es abrir un informe de defecto por cada una. Casi siempre es un error: lo eficaz es agrupar por causa aparente y comprobar primero si comparten una sola —un despliegue a medias, un servicio caído, los datos base borrados—. En suites grandes, esa agrupación elimina la mayor parte del trabajo de análisis.
Es también donde las técnicas de aprendizaje automático empiezan a resultar útiles de verdad: agrupar fallos similares, detectar anomalías en los logs y priorizar qué ejecutar primero. El syllabus del CTAL-TAE v2.0 lo recoge de forma explícita, con el matiz importante de que la herramienta sugiere y la decisión sigue siendo del ingeniero.