2010-03-08

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.

2 comentarios:

  1. Hola, cuanto deberia ser el valor como meta esperada, por ejm en este caso la metrica de velocidad de definicion?? y tambien velocidad de ejecución.
    Yo trabajo en Peru., como responsable del area de testing y estoydando inicio a comenzar a medirnos y a trazarnos metas para los siguientes años o meses. me gustaria compartir mas tu conocimiento y experiencia.

    ResponderEliminar
    Respuestas
    1. Hola Yefry,
      gracias por tu comentario.

      Respecto a tu pregunta es difícil hablar en general para este tipo de cosas. Usualmente la velocidad depende de diversos factores: tipo de aplicación, calidad de la documentación, calidad del software bajo prueba, madurez del equipo de testing.

      Mi recomendación es que tomes tus propias mediciones y trabajes en mejorarlas paulatinamente.

      Saludos,

      Eliminar

Muchas gracias por comentar. Por favor deja tu nombre y/o email, los comentarios son mucho más valiosos cuando se sabe quien los hace.