Métricas de testing

Algo que muchas veces me han preguntado, ya sea clientes, colegas, por las redes, es relacionado a métricas de testing. En particular el tema métricas es algo que por un lado no me convence, o no me gusta, y por otro lado no creo tanto en lo cuantitativo, más cuando eso hace que uno deje de lado lo cualitativo. Habiendo hecho esta confesión a modo de disclaimer, quiero escribir un poco algunas ideas que quizá puedan ser útiles.

El testing siempre busca dar más información para así tener menos incertidumbre y así controlar mejor los riesgos, pero esa información la tenemos que revisar con cuidado.

Los problemas de las métricas

Problema con métricas es que determinan comportamiento, entonces hay que ser muy cuidadosos al determinarlas. Es como eso que siempre se dice que al medir un sistema lo estamos alterando con la propia medición.

Por ejemplo, si yo sé que alguien está midiendo los issues que reporta cada tester, yo voy a querer reportar tantos bugs como sea posible, para mejorar la métrica. ¿Cuál es el problema de eso? Que en lugar de enfocar mi testing a las cosas más importantes y riesgosas, tal vez dedique más tiempo a las áreas menos maduras, con más incidentes o con incidentes más fáciles de encontrar. Además, voy a reportar cualquier cosa, detalles incluso que no le aportaría valor al negocio. Eso sí, la métrica va a mejorar.

Otro problema es que toda métrica se puede engañar, como dice el dicho “hecha la ley hecha la trampa”. Imaginá que tenemos pautado e incluso configurado en alguna herramienta, que todo código tiene que tener un 80% de cobertura de test unitarios, y si no se cumple esto el código entonces se rechaza. Fácil, si tengo un método que es invocado por un test unitario, le agrego muchas líneas (muchas, tantas como haga falta) que simplemente haga algo inocuo, inútil, pero que no de trabajo y no haga daño, algo como esto:

String cobertura = "con esto mejoro la cobertura";

Con esto podría lograr cumplir y mejorar la métrica de cobertura.

Algunas conclusiones respecto a esto:

• La medición puede afectar lo que medimos, hay que pensar con cuidado qué medir.
• El foco debería estar siempre en métricas importantes para el negocio, algo que al buscar mejorarlo implique una mejora para el negocio.
• Una métrica sola cuenta solo parte de la historia.
• Es sumamente importante el compromiso del equipo por la calidad y no solo por las métricas.

Comenzar con el propósito

Como dice Simon Sinek, start with why, comencemos pensando el por qué, el propósito. ¿Para qué queremos medir algo?

Yo creo que no solo hay que pensar en las métricas y simplemente llevar el registro, sino que hay que pensar en definir umbrales y en qué decisiones se tomarían si se pasan ciertos umbrales. Para hacer esto tenemos que tener claro el why.

Por ejemplo, si la suite de test automatizado demora más de 2 horas en ejecutar, vamos a dividir en dos pipelines, uno con lo más crítico y otra para el test de regresión completo que ejecute en la noche. En este ejemplo el why podría ser “asegurar que la automatización nos da feedback rápido”.

Algunas métricas de testing a considerar

Con esto solo quiero dar algunos ejemplos para que esto no quede solo en filosofía, y poder bajar a tierra con ejemplos más concretos. Tampoco consideres que esto es útil para todos en todos los contextos, esto deberías usarlo solo para inspirarte.

Métricas de calidad:

• WTF vs WOW del cliente
• Encuestas de satisfacción de usuarios
• Bugs reportados por usuarios

Si medimos estas cosas y apuntamos a mejorarlas, el negocio irá mejor porque tendremos usuarios más satisfechos. En caso que la cosa vaya mal, habrá que hacer análisis causal de los problemas.

Métricas de Proceso:

• Lead time (tiempo entre que aparece un requerimiento y este está en producción)
• Cycle time (tiempo que lleva desarrollar una feature desde que se decide comenzar a trabajar en ella)
• Tiempo de respuesta en resolución de problemas. Tiempo en que los tickets (bugs) son resueltos, desde que se reportan hasta que se pone el fix en producción.

Conté de estas métricas en el webinar que di sobre estrategia de pruebas y en el webinar de cómo reducir costos de pruebas.

Métricas de Cobertura:

• Prefiero el enfoque top-down, comenzar viendo cobertura por módulos, bajar a funcionalidades, y luego se podría analizar la cobertura en datos en cada funcionalidad.
• Te recomiendo leer este post sobre qué es la cobertura y este sobre técnicas de cobertura de all pairs.

Métricas de Calidad de Código:

• Métricas relacionadas a calidad de código con herramientas como SonarQube
• Deuda técnica
• Tanto para los issues como para las vulnerabilidades, es importante revisar la criticidad y así tener una visión un poco más cualitativa.

Métricas de Bugs o Issues:

• En esto me parece importante al menos agregar tema de severidad de los issues y no considerarlos a todos por igual.
• Ver factores de calidad y ponderar (¿la accesibilidad es importante? ¿cuántos issues críticos hay?)
• Errores encontrados en producción antes que los usuarios (¿estamos haciendo testing en producción?)

Métricas de Casos de Prueba:

• En esto también es importante al menos considerarlos agrupados por criticidad.
• Para esto podría servir aplicar MoSCoW

Métricas de Testing Exploratorio:

• En cada sesión, tiempo destinado a ejecución, setup y bugs.
• En cada sesión, tiempo enfocado en la misión vs tiempo enfocado en la oportunidad.
• Más detalles sobre esto los di en esta charla.

Métricas de Automatización de Pruebas:

• Si vamos a contar los casos de prueba, pensar en agruparlos por importancia, módulos, criticidad, riesgo, prioridad, etc.
• Medir estabilidad o confianza que se le puede tener a un caso de prueba. Esto tiene que ver con falsos positivos.
• Medir tiempo de ejecución, ¿cuánto demora el feedback en llegar?

Métricas de Performance:

• Tiempo de respuesta y throughput
• Uso recursos (ver si podemos medir lo que identificamos como posibles cuellos de botella, porque te recuerdo que si optimizamos algo que no es el cuello de botella, es una ilusión de mejora)
• Te recomiendo leer este post que explica algunos conceptos matemáticos (promedio, percentiles, etc.) útiles al analizar métricas, especialmente para performance.

Métricas de “Felicidad”: (no se me ocurrió un nombre mejor)

• Tranquilidad del equipo, ¿se van de vacaciones? ¿trabajan menos horas extra o los fines de semana?
• ¿Los integrantes del equipo confían en que se pueden ir (vacaciones o lo que sea) y no se va a romper nada que tengan que llamarlos? Recuerdo hace un tiempo en Abstracta Andrei (uno de los integrantes del equipo que hace más años trabaja con nosotros) me dijo que se iba de vacaciones tranquilo de que hay un equipo que tomará lo que suceda y lo va a poder resolver sin que lo tengan que llamar.

Estos fueron puntos que estuve conversando con Melissa Eaden café por medio (esas lindas ventajas de vivir en Silicon Valley). Creo que son métricas a considerar, quizá difíciles de medir y no las únicas, pero pensar en estas cosas, en la unión del equipo y su bienestar también ayudan a que el negocio vaya mejor.

Métricas de testing para dar visibilidad

Las métricas son útiles para dar visibilidad y así poder tomar mejores decisiones. Hay que ser cuidadosos porque pueden generar comportamientos no deseados también.

Vuelvo otra vez con lo mismo para ir cerrando, ¿para qué queremos las métricas? Comencemos con eso, discutamos al respecto y luego veamos cómo medir y qué medir, porque todo tendrá más sentido y sobretodo, estaremos más motivados a relevar esa información porque tendremos un propósito para eso.