Luces y sombras de los indicadores de gestión de calidad

Al inicio de un proyecto de desarrollo de software se establecen plazos de tiempo, presupuesto y mínimos niveles de calidad esperados. Y en el día a día se usan varias métricas para controlar el avance y tener la oportunidad de corregir cualquier desviación de los objetivos iniciales.

De aquí surge la importancia de que los indicadores sean alcanzables, medibles y coherentes con los objetivos del proyecto.  Las dos primeras características, aunque no son triviales, por lo general son decisiones que se pueden especificar. Es decir, tras un análisis del equipo de proyecto se puede estimar si una meta es alcanzable en el tiempo. Y para medir estos indicadores basta con habilitar las herramientas o mecanismos necesarios para hacerlo. Pero, saber si son coherentes con el fin que persigue un proyecto es clave para el éxito y es la motivación para escribir estas líneas.

Imaginemos un ejemplo hipotético, sin ánimos de ofender ni desprestigiar a un gremio honorable como lo es el cuerpo de bomberos. Supongamos que se les asocia un incentivo directamente proporcional a la cantidad de fuegos que apagaban. Eso podría promover un comportamiento no deseado como lo sería que se produzcan incendios provocados. Algo similar se puede producir cuando se asocia un incentivo proporcional a las líneas de código que escriba un programador o casos de prueba que se puedan ejecutar. Este tipo de indicadores provoca distorsiones a escribir líneas de código sin pensar en mantenibilidad o a ejecutar un sinfín de pruebas sin estrategia, las cuales nadie revisa ni aportan información porque sólo pretenden cubrir una meta y distan de una adecuada cobertura de funcionalidad.

La metodología TMAP (Test management approach) indica que las características de calidad de un producto son la base para definir la calidad del mismo y por lo tanto las métricas asociadas a cada una de esas características. Cuando pensamos en características de calidad tenemos una variedad como rendimiento, portabilidad, seguridad, funcionalidad, experiencia de usuario y mantenibilidad entre muchas otras. Es necesario considerar equilibrio entre estas características para no provocar problemas o resultados no deseados en el sistema. Usaremos un ejemplo entre las características de rendimiento y experiencia de usuario.

Para tener los conceptos frescos, la definición de rendimiento, es la velocidad con la que el sistema maneja el procesamiento de transacciones en determinadas situaciones. Estas mediciones pueden ser bajo una excesiva carga para medir el punto en que se rompe el sistema o puede que se quiera medir un nivel aceptable para el usuario con un uso normal en el día a día. Por otro lado, la experiencia de usuario es una característica que busca medir la facilidad con que los usuarios finales pueden operar el sistema.

Por ejemplo, si se fija un indicador para medir el rendimiento y se desprecia la experiencia de usuario, se podría diseñar un buscador de transacciones dado el identificador de esa transacción con el objetivo de que la búsqueda sea muy rápida. Sin embargo, para el usuario final que necesita consultar su transacción será muy complicado recordar un código alfa numérico, que es la entrada que la interfaz de usuario requiere para funcionar. Entonces, simplemente el sistema no cumple los criterios mínimos de experiencia de usuario. Este ejemplo muestra cómo lo que se hace en beneficio de una característica de calidad podría ser en decremento de otra.

Hay mucho que decir acerca de definición de indicadores y características de calidad. Lo más importante para empezar, es definir muy bien el objetivo del proyecto, priorizar las características de calidad del producto y luego definir los indicadores de calidad. Y Sólo así, se tendrá una guía a la hora de diseñar, desarrollar, probar y monitorizar el sistema final para que sea exitoso.

Autor | Gloriana Aguirre – Ingeniera de Pruebas Senior