por Viviana Chelini
28. septiembre 2010
Siguiendo con los comentarios sobre los reportes ágiles de TFS 2010 iniciados en :
Bug Status Report
Bug Trend Report
Reactivation Report
Seguimos en este post con:
Build Quality Indicators Report
El siguiente reporte muestra la cobertura de pruebas, la renovación de código y el número de errores para una compilación especificada.
Información que proporciona el reporte
En el reporte se puede visualizar sobre el eje X las compilaciones que incluye el reporte, sobre la base de los filtros establecidos para la plataforma, la configuración y la definición de la compilación.
Cada barra vertical representa un conjunto de datos derivados de una o más compilaciones. En la variante de tamaño de código del reporte, la longitud de cada barra vertical representa el tamaño de la base de código protegida. Las pruebas manuales se pueden ejecutar en cualquier momento después de la compilación y están asociadas a esa compilación. Las pruebas que no se han ejecutado todavía se cuentan como "no concluyentes".
En la siguiente tabla se describe la información que aparece en el reporte:
|
Indicador
|
Descripción
|
|
Errores activos (número)
|
Gráfico de líneas que representa el número de errores que estaban activos al momento de la compilación.
|
|
Renovación de código (líneas)
|
Gráfico de líneas que describe el número de líneas de código que el equipo agregó, quitó y modificó antes de la compilación. La renovación de código se calcula determinando el número de líneas de código que se han agregado, eliminado o modificado en la compilación dividido por el número total de líneas de la compilación.
|
|
Cobertura de código (porcentaje)
|
Gráfico de líneas que representa el porcentaje de código que cubren las pruebas.
|
|
Pruebas no concluyentes
|
Gráfico de barras apiladas de color gris que indica el número de pruebas que no tuvieron un resultado correcto o se pusieron en pausa. Si la compilación no tuvo un resultado correcto, las pruebas no se cuentan o se cuentan como no concluyentes.
|
|
Pruebas no superadas
|
Gráfico de barras apiladas de color rojo que indica el número de pruebas no superadas para la compilación.
|
|
Pruebas superadas
|
Gráfico de barras apiladas de color verde que indica el número de pruebas superadas para la compilación.
|
Para que el reporte sea fiable los miembros del equipo deben realizar las siguientes actividades para administrar pruebas y compilaciones:
- Configurar un sistema de compilación. Para utilizar Team Foundation Build, debe configurar un sistema de compilación.
- Crear definiciones de compilación. Puede crear varias definiciones de compilación, de modo que cada una de ellas pueda ejecutarse para generar código para una plataforma diferente.
- Definir las pruebas que se ejecutarán automáticamente como parte de la compilación.
- Configurar las pruebas para recopilar datos de cobertura de código. Para que los datos de cobertura de código aparezcan en el reporte, los miembros del equipo deben instrumentar las pruebas para recopilar esos datos.
- Ejecutar compilaciones con regularidad. Puede ejecutar compilaciones a intervalos establecidos o después de cada protección. Puede crear compilaciones periódicas cuando utilice el desencadenador de programación.
Análisis del reporte
El reporte permite responder las siguientes preguntas:
- ¿Cuál es la calidad del software?
- ¿Está el equipo probando suficiente código?
- ¿Se están superando las pruebas?
- ¿Es probable que el equipo termine en función del código y las métricas de pruebas?
- ¿Con qué frecuencia se superan las pruebas y con qué frecuencia se prueba el código?
Versión positiva del reporte
Un reporte positivo muestra los siguientes indicadores:
- La mayoría de las pruebas se superan (áreas grandes de color verde) y pocas pruebas no se superan (cantidades pequeñas de color rojo).
- El porcentaje de color rojo es inferior al 20-30 por ciento.
Versiones negativas del reporte
Una versión negativa mostrará uno o más de los siguientes indicadores:
- Menos cobertura de código y más renovación de código. Podría indicar que el nuevo código se protege sin las correspondientes pruebas unitarias que lo cubran.
- Baja tasa de pruebas en ejecución. Estos datos podrían indicar que el equipo no está realizando suficientes pruebas. Este bloqueo podría indicar falta de recursos o que los evaluadores estén haciendo otras tareas, como escribir la automatización de pruebas en lugar de probar la funcionalidad actual.
- Alta renovación de código, baja tasa de cobertura de código. Una alta renovación de código sugiere que los errores se introducirán como efectos secundarios de los cambios. De lo contrario, una alta renovación de código podría indicar una cobertura reducida y la necesidad de reescribir pruebas.
- Tasa alta de pruebas no superadas. La siguiente ilustración muestra que muchas pruebas se realizan con una cobertura de código razonable, pero que no se están superando las pruebas. Estos datos podrían indicar prácticas de desarrollo poco rigurosas o, en iteraciones tempranas, que las pruebas son demasiado duras para esta etapa del producto.
- Alta tasa de pruebas que se superan y alta tasa de errores activos. La siguiente ilustración muestra una alta tasa de pruebas superadas pero, no obstante, un alta tasa de errores de entrada. Esta situación se puede producir por varias razones. Es posible que las pruebas no sean suficientemente rigurosas para esta etapa del producto.
- Tasa creciente de superación de pruebas sin aumento en la cobertura de código. Habitualmente, cuantas más pruebas se realizan, se debe cubrir más código. Por otro lado, si la ejecución de pruebas y las tasas de superación de pruebas aumentan sin un aumento correspondiente en la cobertura de código, es posible que las pruebas incrementales sean redundantes.
- El número de errores activos aumenta, pero las pruebas no superadas no aumentan. Es probable que las pruebas no estén probando la misma funcionalidad que indican los errores.
- El número de errores activos está disminuyendo, pero las pruebas superadas no aumentan. Puede que exista un aumento en la tasa de reactivación.