Un tablero lleno de números no es lo mismo que un equipo de calidad bien medido. Muchas áreas de QA reportan cifras que impresionan (casos ejecutados, bugs abiertos) pero que a la gerencia no le dicen nada sobre si el producto está mejorando. Elegir bien las métricas de QA es lo que convierte tu trabajo en algo visible y valioso para el negocio, así que vamos a separar las que importan de las que solo hacen bulto.
Qué hace buena a una métrica
Una métrica útil responde a una pregunta del negocio: "¿estamos entregando con calidad?", "¿somos más rápidos que hace seis meses?". Es accionable, porque si cambia sabes qué hacer. Es difícil de manipular, de modo que no mejora haciendo trampas. Y se entiende fuera de QA: si necesitas veinte minutos para explicar qué significa, probablemente no sirva para tomar decisiones.
Las métricas de QA que sí le importan a la gerencia
La más directa son los bugs que escapan a producción, los defectos que encuentran los usuarios después del lanzamiento: es la medida más clara de la efectividad de tu proceso. Muy relacionada está la eficacia de detección de defectos, la proporción de los que se encuentran antes de la entrega frente al total, incluyendo los que escaparon; indica qué tan bien filtra tu proceso.
El tiempo de regresión mide cuánto tarda comprobar que nada se rompió antes de liberar, y si baja gracias a la automatización, se traduce directamente en entregas más rápidas. El tiempo medio de resolución, desde que se reporta un defecto hasta que se corrige, revela cuellos de botella entre QA y desarrollo. La estabilidad de las pruebas automáticas, el porcentaje de ejecuciones fiables sin fallos intermitentes, dice si el equipo puede confiar en ellas. La cobertura de riesgos críticos, no de código por sí sola, sino qué parte de los flujos de negocio importantes está protegida por pruebas. Y la frecuencia y estabilidad de las entregas completan el cuadro: cada cuánto se libera y qué proporción necesita corrección inmediata.
Las que conviene evitar
El número de casos ejecutados mide actividad, no calidad: puedes ejecutar mil y no haber probado lo importante. La cantidad de bugs reportados por persona incentiva reportar mucho, no reportar bien, y suele provocar enfrentamientos con desarrollo. Perseguir un porcentaje de cobertura de código como objetivo único es otro clásico, porque se infla fácilmente con pruebas de poco valor. Lo mismo ocurre con contar pruebas automatizadas sin mirar si son frágiles o redundantes, o con mostrar bugs abiertos sin contexto, porque un número aislado no dice si el producto está sano.
Cómo presentárselas a quien decide
Habla de negocio: traduce los números a tiempo ahorrado, riesgo evitado o impacto en clientes. Enseña tendencias, que dicen mucho más que la foto de un día, y acompáñalas con contexto para explicar por qué subió o bajó algo. Elige pocas: cinco o seis bien escogidas valen más que veinte. Y cierra con acciones: qué harás a partir de lo que revelan, porque una métrica que no cambia ninguna decisión es decoración.
Dos cosas más a tener presentes. No uses las métricas para evaluar personas, porque se distorsionan y generan miedo, y no cambies de indicadores continuamente, porque entonces no se ven tendencias. Si no tienes datos históricos, empieza a registrarlos hoy: en dos o tres ciclos de entrega tendrás una línea base útil.
Si quieres que tu equipo aprenda a medir y comunicar calidad, pide información en el formulario de contacto y te contamos nuestras capacitaciones.
¡Hasta la próxima!