Sigue rondándome la cabeza cómo cuantificar la calidad del software que se desarrolla. Mientras escribía el artículo sobre la validez como KPI de la cobertura de código, llegué a un artículo de KMS Technology interesante: The 8 Most Important KPIs for Software Quality Assurance. Ahora he vuelto a leerlo con más atención.

El artículo propone 8 KPIs para asegurar la calidad del software. Sin embargo, algunos de los KPIs mencionados presentan limitaciones en cuanto a su objetividad y otros, en mi opinión, son difícilmente cuantificables.

KPIs a descartar

En particular yo descartaría:

Eficiencia de los casos de prueba: Este KPI es subjetivo y difícil de cuantificar. La eficiencia de un caso de prueba depende de varios factores: calidad de los datos de prueba, la capacidad del caso para identificar defectos y la claridad de los resultados. No conozco una forma objetiva de medir estos factores.

Volumen de pruebas ejecutadas: Este KPI no dice nada sobre la calidad de las pruebas, es una métrica «al peso». Un bajo volumen es un mal síntoma pero un alto volumen no debe ser un objetivo y en cualquier caso se debe complementar con métricas que evalúen la efectividad de las pruebas.

Tiempo empleado en las pruebas: Similar al anterior, este KPI es altamente dependiente de la complejidad de la funcionalidad a probar y de la implicación y las habilidades del equipo de pruebas. Es una métrica interesante – de hecho dos, el tiempo de ejecución de las tests automatizadas y el tiempo empleado en tests manuales por el equipo – pero cuidado con convertirla en KPI y asignarle un valor objetivo. Ejemplo: el tiempo de ejecución se debe reducir si es por baja calidad de las tests o para conseguir que se ejecuten más frecuentemente, pero aumentar si la causa es que hay pocos tests. Ejemplo2: el equipo puede dedicar poco tiempo a pruebas porque está prácticamente todo automatizado o por desidia. Por su complejidad y por el alto riesgo de que lleve a los equipos a malos hábitos yo me inclino por mantenerlo como indicador pero no hacerlo key en la evaluación de la performance (KPI: key performance indicators, ¿recuerdas?)

Quality Ratio: Este no lo he debido entender. Si en las tests automatizadas no hay un Quality Ratio del 100% para las máquinas, anula el despliegue o bloquea la Pull Request. Punto. Y en las pruebas manuales… ¿queremos desincentivar que se encuentren defectos para que este ratio sea mejor? Lo dicho, no he debido de entenderlo.

KPIs a mejorar

Los siguientes son indicadores interesantes, pero que deben ser analizados con cuidado y no simplemente poner unos valores objetivos sin analizar cada contexto y sin tener en cuenta que asignar unos valores objetivos va a alterar la forma en la que trabaja el equipo.

Densidad de errores/defectos: Este KPI es útil, pero se puede debe considerar la severidad de los defectos. Un alto número de defectos menores puede ser menos preocupante que un pequeño número de defectos críticos. Se podría usar una escala ponderada para reflejar la importancia de cada defecto y se debe usar en combinación con el «Tiempo de resolución de defectos».

KPIs robustos

Vulnerabilidades no resueltas: Es un KPI crucial que cuantifica directamente el riesgo de seguridad. Es importante monitorizarlo y priorizar la resolución de las vulnerabilidades críticas. Mantener el número y el tiempo de resolución por debajo de ciertos umbrales sí es importante.

Tiempo de resolución de defectos: Este KPI es valioso, pero de nuevo se debe desglosar por tipo de defecto y severidad. También se debe prestar atención al tiempo de respuesta; el tiempo que pasa desde que se detecta el defecto hasta que se comienza a trabajar en su resolución. Esto permitirá identificar cuellos de botella en el proceso de resolución.

Proporción de pruebas automatizadas: El porcentaje de las pruebas que son automáticas es un indicador objetivo y cuantificable muy importante: las pruebas manuales son lentas, no escalan y son muy propensas a errores o a ser ejecutadas de manera inconsistente. El progreso en la automatización de pruebas no sólo redunda en la calidad del producto, también impacta positivamente en la eficiencia del equipo. La importancia de este KPI depende del contexto del equipo/producto pues una vez alcanzada una proporción quizá ya exista cultura de tests automáticas y no sea necesario prestar atención al KPI (o incluso sea conveniente para evitar la tentación de reducir las pruebas manuales remanentes para mejorar el ratio).

Conclusión

En definitiva, parece que por unas razones o por otras he terminado desechando la mitad de los propuestos y quedándome únicamente con Vulnerabilidades no resueltas, Tiempo de resolución de defectos y Proporción de pruebas automatizadas (y Densidad de defectos una vez mejorado). Haber desechado otros cuatro no me parece malo, porque el número de KPIs debe ser lo más bajo posible, no se puede apuntar a la vez en demasiadas direcciones distintas. ¿Qué opinas? ¿Qué otros indicadores deberían ser analizados?