Optimizando la realización de pruebas: uso de métricas

Durante el diseño y la ejecución de las pruebas debemos recoger diferentes métricas. La utilidad más habitual es informar al responsable del proyecto del estado del sistema bajo prueba: defectos encontrados, severidad de los mismos, etc.

Habitualmente también se recogen métricas para conocer el grado de cobertura que se ha conseguido con la ejecución de las pruebas: casos de prueba propuestos, ejecutados, fallidos, no ejecutados, bloqueados, etc.

Pero el responsable de pruebas debe prever también la recogida de información suficiente para hacer más efectivas las pruebas realizadas en cada iteración. "Hacer más efectiva" significa aquí detectar el mayor numero posible de errores, o errores más importantes.

Para esto, debemos pensar con antelación cual será nuestra estrategia de mejora de la efectividad, de cara a recoger la información necesaria. Algunas de las suposiciones que podemos seguir son:

Los errores tienden a "agruparse" (1):

• Por zonas de código: un módulo o conjunto de funciones que presenta problemas en un ciclo de pruebas es propenso a presentar problemas en los siguientes
• Por equipos de trabajo de desarrolladores: un equipo que crea código con incidencias tiene a generar incidencias en nuevo código o correcciones
• Por equipos de trabajo de testers: un equipo o grupo de testers es capaz de identificar mayor numero de errores que otro, o un grupo levanta mas errores no reales (que luego, al ser revisados, resultan no ser errores) que otro.

En este caso, deberemos recoger información que nos permita trazar cada error detectado durante las pruebas con la zona en la que se ha producido. Una vez finalizado el ciclo de pruebas, podremos ver las zonas en las que debemos poner mayor atención en los siguientes ciclos de pruebas y en cuales podemos disminuir la intensidad o tomar medidas de mejora.

A la hora de determinar o analizar las zonas, podemos tener en cuenta los distintos factores que determinan el éxito o fracaso durante un proceso de test (2):

• Producción
• Personal
• Comunicaciones
• Operaciones
• Mantenimiento
• Entorno
  

Referencias

1. McGowen, D.J. “C4I Operational Test and Evaluation in Support of Evolutionary Acquisition Strategy.” ITEA Journal of Test and Evaluation 21.2 (2000): 34-39.
2. Phadke, M.S. “Planning Efficient Software Tests.” CrossTalk Oct. 1997 <www.stsc.hill.af.mil/crosstalk/1997/10/index.html>.