En el post anterior publiqué una introducción al tema de reportes Ágiles y un resumen de uno de los reportes.

Seguimos la serie con:

Bug Trend Report

El siguiente reporte ayuda a obtener y seguir la tasa de detección y resolución de errores del equipo. Este reporte muestra un promedio acumulado o móvil de los errores notificados, resueltos y cerrados a lo largo del tiempo, obteniendo una visión de la medida en que el equipo está encontrando, resolviendo y cerrando los errores.

Información que proporciona el reporte

El reporte calcula un promedio acumulado del número de errores que el equipo ha abierto, resuelto y cerrado. El promedio acumulado se basa en los siete días antes de la fecha para la que se calcula. Es decir, el reporte calcula el promedio del número de errores en cada estado para cada uno de los siete días antes de la fecha y, a continuación, divide el resultado entre siete.

Para que el reporte sea fiable se deben de alimentar correctamente los siguientes parámetros:

• Definir los errores y especificar sus rutas de acceso de Área e Iteración.
• Actualizar el Estado de cada error cuando se ha corregido, probado y cerrado.
• Especificar la Prioridad y Gravedad de cada error durante la evaluación de errores.

Análisis del reporte

Las tasas de errores se interpretan mejor comparándolas con todas las actividades de proyecto de equipo actuales y las otras métricas que proporcionan los reportes de Estado del error y Reactivaciones. Por ejemplo, el equipo podría encontrar errores con especial rapidez en código mal escrito, en código recientemente integrado, con pruebas mejoradas o durante un evento excepcional como una búsqueda intensiva de errores. Por otra parte, los errores son más difíciles de encontrar en un producto de alta calidad y con pruebas ineficaces. Cuando el producto se estabiliza hacia el fin de un ciclo del producto, el equipo debería encontrar errores con menos frecuencia.

El reporte podría informar determinadas situaciones que se deberían evaluar porque surgen:

· El equipo encuentra el mismo número de errores aproximadamente en períodos de tiempo sucesivos.

o ¿Son adecuados los casos de prueba para probar los casos de uso que se están desarrollando?

o ¿Las pruebas se han vuelto obsoletas o están probando la funcionalidad equivocada?

o ¿El equipo de pruebas está probando cada caso de uso rigurosamente?

· El equipo resuelve muchos errores en cada período

o ¿Se cierran rápidamente los errores resueltos? La tasa de errores cerrados debe ser similar a la de errores resueltos.

o ¿Permanecen las reactivaciones de errores dentro de los límites esperados?

· El equipo resuelve los errores rápidamente pero no los cierra.

o ¿Están sobreasignados los recursos de pruebas?

o ¿Debería el equipo volver a revisar las prioridades de pruebas?

Versión positiva del reporte

Un reporte positivo muestra que el equipo encuentra más errores en el inicio de un ciclo de desarrollo y menos errores hacia el fin de una iteración. Cuando el equipo resuelve los errores más rápidamente que los encuentra, el número de errores activos empezará a disminuir. Cuando el equipo empieza a encontrar menos errores, el producto se estará estabilizando.

Versión negativa del reporte

Un reporte negativo podría mostrar que el equipo encuentra errores más rápidamente a medida que se acerca la fecha de envío y los resuelve más lentamente. En esta situación, el trabajo pendiente del equipo está aumentando, ya que los errores no se corrigen y sería conveniente investigar las causas.