3 indicadores infaltables en el "survival kit" de un equipo de testing de software

Creo que podemos coincidir sin mediar demasiada discusión o argumentación que medir es importante. Cualquier disciplina de ingeniería requiere mediciones para mejorar y si no me creen, permítanme desempolvar una imagen del arcón de los recuerdos que muestra a Watts Humphrey diciendo exactamente esto.

La imagen está hosteada aquí junto con notas sobre una charla del '99. Transcribo una parte:

Measurements provide

• a factual basis for analysing the work

• the historical data for planning

• an objective assessment of job status

Without measurements, we are forced to rely on

• opinion

• mythology

• power and politics

El testing de software, como era de esperarse, no es ajeno a esta realidad. Sabemos que para ser entendida y mejorada, la actividad de testing debe ser medida en múltiples dimensiones en simultáneo. No es mi intención aquí hacer un análisis exhaustivo de todos los indicadores posibles a la hora de medir las actividades de testing. Lo que quiero es llamar la atención sobre algunos que encuentro particularmente importantes a la hora de gestionar actividades de un equipo de testing.

#1 Eficacia del testing

Defino este indicador como el total de errores encontrados en la fase de testing sobre el total de errores encontrados en la fase de testing sumado al total de errores encontrados en producción. Este número porcentual nos permite entender cuán exitosa es la actividad de testing en la tarea de impedir que los errores lleguen a producción. Un número superior al 95% es esperable en este indicador. Menos que eso nos diría que estamos ante una fase de testing débil que deja pasar muchos errores que luego son encontrados en producción.

#2 Efectividad de los casos de prueba

Tengo dos variantes para medir la efectividad de los casos de prueba. En la primera variante defino el indicador como la cantidad de casos de prueba ejecutados con error sobre la cantidad de casos ejecutados. Este número nos permite entender qué tan buenos son nuestros casos de prueba a la hora de encontrar errores. Los valores esperables dependerán fuertemente del tipo de desarrollo. Números cercanos a uno son esperables en software más nuevo.

En la segunda variante para este indicador lo defino como el total de errores encontrados sobre la cantidad de casos ejecutados. En el ideal este número debería dar entre 0 y 1 pues no deberíamos tener más de un error por caso ejecutado (una especie de probabilidad). Sin embargo me he encontrado en situaciones donde el tester se ve obligado a reportar más de un error por caso. Un indicador superior a uno indica que para cualquier caso que se le ocurre al tester, seguro encontraremos un error.

#3 Errores críticos por hora de testing

Defino este indicador como el total de errores clasificados como críticos sobre el total de horas dedicadas al testing. Es importante monitorear este indicador durante la prueba porque nos permitirá decidir cuándo parar de probar (a medida que pasa el tiempo, será cada vez más costoso encontrar un error crítico) [1]. Contabilizamos solo los errores críticos para minimizar las discusiones sobre las distorsiones que agregar los errores menores en la medición.

Como cierre es importante señalar que es en la medición sistemática de este tipo de indicadores donde podemos sacar el provecho máximo. Midiendo sistemáticamente podemos detectar tendencias y a partir de eso sacar conclusiones.

Seguimos pensando..
---
[1] En Testing es tan importante saber cuándo empezar como saber cuándo parar.