¿Para qué monitorizar la calidad? Aspectos, scores, KPIs y otros duendes

Introducción

Después de tanto tiempo sin escribir en el blog, vuelvo a aparecer para cumplir mi última promesa antes de año nuevo! Espero que estés genial dentro del año que hemos pasado, sino es así te mando mucha fuerza.

Si lees la palabra testing o calidad, es probable que lo primero que te haya venido a la cabeza es la palabra “test” o prueba, como si el desarrollar los teses fuera el objetivo principal de una estrategia de calidad. Esto es normal, y la razón es porque estamos muy acostumbrados a pensar que con tener una buena cantidad de pruebas vamos a mejorar la “calidad”.

Pero, ¿qué es la calidad?, ¿No tener bugs?. ¿Es el bug el indicador principal de la calidad de nuestras aplicaciones?

En este post me gustaría hablar sobre los aspectos que creo que definen la calidad de nuestras aplicaciones, cómo monitorizar la estrategia de testing y cómo ayudarnos en la toma de decisiones.

Aspectos de la calidad

Como he comentado en la introducción, creo que la calidad no debería basarse únicamente en si nuestro producto tiene muchos o pocos bugs, estoy de acuerdo en que es un aspecto importante, pero tenemos que tener un prisma más holista.

En mi caso separo los aspectos de calidad en tres grupos: funcionales, técnicos y productivos.

Aspectos funcionales

Son aquellos que evalúan que el producto se comporta como el usuario/cliente o negocio lo espera. Por ejemplo, podríamos evaluar que el comportamiento es el esperado, la UX etc.

En este post no voy a entrar al detalle de los KPIs para evaluar los aspectos funcionales ya que creo que puede ser interesante poner el foco en los siguientes. ¡Perdonadme! 

Aspectos técnicos

Son aquellos que evalúan la calidad técnica del producto. Estaríamos hablando por ejemplo de vulnerabilidades, code smells, código duplicado, complejidad ciclomática y arquitectónica, deuda técnica etc.

Aspectos productivos

Muy poco valorados en el testing, son aquellos que nos ayudan a medir si el producto bloquea o no a la productividad del equipo. Por ejemplo podríamos evaluar cuánto tiempo nos lleva corregir un bug, añadir una nueva funcionalidad, falsos en los tests etc.

Cómo veis, no hemos hablado de bugs como tal en ninguno de los aspectos. Este punto es interesante y abre el debate de lo que consideramos como bug y en qué aspectos recaería este concepto. 

Si consideramos el bug únicamente como algo técnico, es decir, un cambio en el código que provoca posibles fallos o errores, lo podemos ubicar en el aspecto técnico. Pero, ¿Y si ese fallo es debido a una falta de definición o un corner case lo llamamos “bugature”?

Se está creando una tendencia a categorizar los bugs, por ejemplo: bug técnico, bug en producción o en desarrollo, bug de infraestructura, bug de definición etc. Esto nos ayudaría a poner el foco y encontrar el punto de mejora mucho más fácil. Cómo he dicho, esto da para un buen debate.

Tenemos que cambiar nuestra forma de pensar y de entender la estrategia de calidad. Debemos darnos cuenta de que las técnicas de testing las aplicamos no sólo para encontrar o prevenir los bugs, sino para garantizar de alguna manera estos aspectos y la productividad del equipo.

¿Entonces, no desarrollamos las pruebas solo para encontrar o prevenir bugs? No. No dejes que el árbol no te deje ver el bosque, toma frase de abuelo cebolleta.

KPIs y el score de calidad

Vamos a la parte interesante. ¿Qué KPIs seguimos para evaluar todos estos aspectos y qué “demontres” es eso del score de calidad? 

Me gustaría decir que a día de hoy he llegado a evaluar todos los aspectos que he comentado en la introducción con KPIs, pero como os he dicho, la realidad es que no es así. Solo he tenido oportunidad o solo he conseguido evaluar algunos de ellos. 

KPIs de los aspectos técnicos

En la parte técnica es donde suelo tener mayor número de KPIs dado que son más fáciles de obtener y evaluar los datos.

  • Número de bugs vivos. Los bugs vivos los identifico como aquellos que no están en un estado resuelto. Cuando este KPI crece es realmente interesante ver si es porque el producto se degrada, o porque tenemos que mejorar la gestión del panel de bugs dentro del equipo.
  • Número de bugs vivos VS tareas vivas. Es un KPI interesante para ver dentro de todas las tareas que tenemos que parte de la tarta se las lleva los bugs. A día de hoy he dejado de usar este KPI ya que realmente no lo tenía en cuenta para la toma de decisiones.
  • Número de bugs creados por prioridad. Realmente no nos interesa hablar de cantidad, sino de prioridad o de impacto.
  • Número de bugs resueltos por prioridad. Al igual que el KPI anterior, nos interesa saber el número por prioridad o impacto, ya que realmente es lo que nos va a hacer decidirnos que bug solucionamos primero.
  • Estado del análisis estático. Este dato es un agregado de otros KPIs. Por ejemplo con una herramienta como Sonar podemos evaluar el estado del código: vulnerabilidades, code smells, seguridad, mantenibilidad, código duplicado, complejidad, cobertura etc.

En este punto me gustaría recomendaros utilizar pruebas de mutación, ya que el análisis estático nos va a evaluar el resultado de su ejecución, viendo así la calidad de nuestras pruebas. Este dato si lo analizamos junto con la cobertura, realmente tendremos un resultado bastante más objetivo que lo que es realmente analizar  la propia cobertura.  

KPIs de los aspectos productivos

Las estrategias de testing no solo tienen que ayudarnos a prevenir el número de bugs, también deben ayudar al equipo a ser más productivos. Tenemos que conseguir una estrategia que equilibre la calidad y productividad. 

  • Tiempo de resolución de bugs por prioridad. Importante para ver si estamos resolviendo los bugs en los tiempos estimados por prioridad o simplemente estamos priorizando bien.
  • Número de bugs descartados. ¿Estamos creando bugs que no lo son?, ¿Reproducimos los bugs antes de darlos de alta?  Este KPI nos va a dar el estado de la calidad de nuestro panel de bugs.
  • Puntos de historia desarrollados. Puede ser interesante si queremos saber si los cambios en nuestra estrategia de testing están afectando al delivery. Este es uno de los KPIs con los que más dudas he tenido en implementar ya que no es del todo determinista, pero sí puede servir como alerta.
  • Números de tareas no validadas. Este KPI es uno de los más importantes de cara a valorar si la estrategia preventiva funciona. Vamos a ver cuantas tareas se echan atrás en el proceso de code review por un bug en el código, y por qué no lo han detectado las técnicas preventivas.
  • Falsos positivos/negativos en las pruebas. Es un KPI que puede ayudarnos a valorar tanto la calidad de nuestras pruebas como el impacto en la productividad que tienen. Realmente no lo he llegado a implementar ya que el decidir si los resultados de las pruebas son falsos o no, puede ser un proceso manual. A día de hoy estoy dando vueltas para ver si es interesante implementarlo.

Score de calidad

Ya hemos visto el número de KPIs que podemos utilizar para valorar la calidad de nuestro producto, pero ¿realmente vamos a saber utilizar tanta información y tanto numerito para hacer una evaluación?

Donde trabajo actualmente hemos creado un sistema donde podemos definir un perfil de reglas que puntúan los diferentes KPIs, devolviendonos el score del producto. De esta forma evaluamos objetivamente el software y vemos su evolución. Si observamos que el score del producto se degrada, con entrar a ver la puntuación asignada por cada KPI veremos donde está el problema y podemos tomar acciones.

De forma resumida así es más o menos como funciona nuestro sistema:

  1. Damos de alta el proyecto que queremos analizar en el sistema.
  2. Asignamos un nuevo “minero” al proyecto para que se ejecute cada X horas y extraiga la información de las tareas y los bugs del proyecto.
  3. Cada resultado del análisis estático del proyecto se enviará al sistema.
  4. Cada vez que el proyecto se actualice con nueva información de calidad, el algoritmo re-calculará el score en base a un perfil de reglas que se le ha asignado al proyecto. 

Un ejemplo de perfil de reglas (score profile) podría ser:

En nuestro caso la puntuación de cada proyecto va de 0 a 100, asignándole una label de calidad, A, B, C o D, dependiendo el valor del score.

De momento los scores de calidad nos están dando buen resultado para ver cómo afecta la estrategia de calidad al proyecto. 

Otra recomendación que os doy, es que si trabajáis con OKRs de calidad podéis utilizar el score como OKR ya que agrupa diferentes KPIs, es totalmente medible y es fácil poner objetivos alcanzables.

Analizando los datos para nuestra estrategia

El score como norma

Como hemos dicho anteriormente lo interesante es ver la evolución del score del producto y poder corregir a tiempo su degradación. Si observamos que el score baja podemos ver en detalle la evaluación del algoritmo y tomar las acciones que creamos necesarias para revertirlo.

Analizando los KPIs en detalle

A parte del score, también es interesante tener una visión en detalle de los KPIs y sus tendencias. Esto siempre nos puede ayudar poner el foco y valorar los cambios que tenemos que hacer en la estrategia de testing. 

Ejemplos:

  • El número de bugs aumenta y los code reviews suelen ser positivos. Puede ser que necesitemos invertir esfuerzos en la mejora de las pruebas, puede ser que tengamos que mejorar el proceso de code review etc.
  • El tiempo de resolución de los bugs de prioridad media es muy alto. Puede ser debido a que el equipo no gestiona bien la prioridad, puede ser que no se invierta puntos de historia en el sprint para solucionar bugs etc.

Veamos otro ejemplo, esta vez con un análisis de las tendencias. El siguiente gráfico muestra la evolución de los bugs creados, resueltos y rechazados.

  1. Vemos como en el primer punto el pico de bugs se dispara. Un primer análisis puede indicarnos que no se han invertido esfuerzos en implementar una estrategia de testing.
  2. Como primera acción se decide implementar técnicas reactivas y reducir el número de bugs, por lo que la tendencia baja, pero no tomamos medidas preventivas.
  3. El decidir no invertir esfuerzos en técnicas preventivas hace que el pico se vuelva a elevar. Por lo que se decide esta vez sí invertir esfuerzos en medidas preventivas.
  4. Tras aplicar una estrategia de testing preventiva vemos como el producto se va poco a poco estabilizando.

Todos estos datos nos ayudan a entender cómo afecta nuestra estrategia de testing al producto, es una forma de evaluarla. Pero no nos engañemos, tenemos que hacer un análisis más profundo del asunto, ya que también saca a relucir otro tipo de puntos de mejora, por ejemplo en la gestión del equipo o del producto.

  • ¿El no tener una estrategia de testing ha podido ser por falta de responsabilidad en el equipo, por prisas por sacar un producto o una funcionalidad?
  • ¿No tenemos una buena cultura de calidad?
  • ¿No se han definido bien las historias?

Y un largo etc, es decir, tenemos que hacer un análisis holista y por supuesto no podemos utilizarlos para juzgar, sino para buscar puntos de mejora. 

Conclusiones

Si habéis llegado hasta aquí puede ser que os haya interesado al menos un poquito el post, cosa me alegra!

Como conclusión me gustaría recalcar que tenemos que tomar los KPIs o el score como un sistema de control y alerta que nos indique si tenemos que hacer cambios en cómo aplicamos las técnicas de testing.

Tenemos que ser abiertos y entender que cada producto y equipo es diferente y lo que funciona en uno, no tiene porque funcionar en otro. Ninguna estrategia es una panacea y lo normal es que sea viva, se adapte y evolucione. ¿Podríamos llamarlo relatividad estratégica? ¡Me gusta la idea!

Tenemos que empezar a pensar que el testing no solo es para reducir el número de bugs, sino también lo es para ayudar a mejorar y optimizar la productividad y seguridad del equipo.

En mi caso la pelea con los KPIs es continua, es decir, lo que hoy me funciona, mañana igual no, es por eso que os invito a probar a implementar nuevos y a no tener miedo de descartar aquellos que creais que no os valen. 

Otro consejo que a mí me ha ayudado mucho a mejorar la cultura de la calidad en los equipos y promover la responsabilidad compartida es visibilizar y hacer partícipe al equipo de este dashboard. Si el equipo lo tiene presente y ven que van mejorando los datos o que un “para qué voy a meter un test unitario” hace que el score se degrade, les va a sensibilizar y a concienciar.

Creo que estos datos enfocados de otra manera, pueden ser muy interesantes para mostrar a negocio, también para que entiendan el esfuerzo que se hacen en el equipo y la importancia de que las prisas no son buenas o que la calidad no es algo que se pueda sacrificar.

¡Y esto es todo!

¡Feliz Solsticio de Invierno, Navidad, Hanukkah o lo que vuestras costumbres dicten!