Panel Calidad (Agile y CMMI)

 

Puede utilizar el panel de calidad para obtener información general sobre el progreso en las áreas de prueba, desarrollo y compilación ya que afectan a la calidad del software que se está desarrollando. El equipo puede utilizar el panel de calidad para obtener información y tomar decisiones que respalden los objetivos del equipo en materia de calidad de producto.

Con este panel, puede revisar el progreso de las pruebas, los estados de compilación, el progreso a la hora de resolver y cerrar errores, la tasa de reactivación de errores, el porcentaje de código que se ha probado y las tendencias en los cambios de código. Se representa gráficamente cada una de estas métricas para las últimas cuatro semanas.

En este tema Datos que aparecen en el panel Actividades necesarias para realizar un seguimiento de la calidad Solucionar problemas de calidad

Este panel se puede usar para responder a las siguientes preguntas: ¿El esfuerzo de prueba va por el buen camino? ¿El equipo está probando la funcionalidad adecuada? ¿Las correcciones de errores que realiza el equipo son de alta calidad? ¿Las pruebas están obsoletas? ¿Dispone el equipo de suficientes pruebas? ¿Hay algún cuello de botella?

Requisitos

Los mismos requisitos definidos en Paneles del portal del proyecto.

Datos que aparecen en el panel

Los miembros del equipo pueden utilizar el panel de calidad para determinar la calidad global del producto que están desarrollando. En el mejor de los casos, las tasas de pruebas superadas, los errores y la renovación de código apuntan todos a lo mismo pero, en muchos casos, no es así. Cuando se detecta una discrepancia, se han de examinar más detenidamente la compilación y la serie de datos pertinentes. En el panel de calidad, se combinan los resultados de pruebas, la cobertura de código de las pruebas, la renovación de código y los errores, de modo que le ayuden a comprender muchas perspectivas a la vez.

Para obtener información sobre los elementos web que se muestran en el panel Calidad, consulte la ilustración y la tabla que siguen.

Nota

El informe Progreso del plan de pruebas solo está disponible cuando el equipo crea planes de pruebas y ejecuta las pruebas.

Los gráficos de progreso, compilación y código (informes del al ), no aparecen cuando no está disponible el almacén de datos para el proyecto de equipo.

Para obtener más información sobre cómo interpretar, actualizar o personalizar los gráficos que aparecen en el panel de calidad, vea los temas que figuran en la siguiente tabla.

Elemento web	Datos mostrados	Tema relacionado
	Gráfico de áreas apiladas en el que se muestran los resultados de pruebas de todos los casos de prueba agrupados por su último resultado registrado (No ejecutar nunca, Bloqueada, Con errores o Correcta) en las últimas cuatro semanas.	Informe de progreso del plan de pruebas
	Columnas apiladas que muestran el número de compilaciones Con errores o Correctas en las últimas cuatro semanas.	Informe de Excel Estado de la compilación
	Gráfico de áreas apilado que muestra el número acumulativo de todos los errores, agrupados por estado, en las últimas cuatro semanas.	Informe de Excel Progreso de los errores
	Gráfico de áreas apiladas que muestra el número de errores reactivados por el equipo desde el estado Resuelto o Cerrado en las últimas cuatro semanas.	Informe de Excel Reactivaciones de errores
	Gráfico de líneas que muestra el porcentaje de código probado mediante pruebas de comprobación de la compilación (BVT) y otras pruebas en las últimas cuatro semanas.	Informe de Excel Cobertura de código
	Gráfico de áreas apilado que muestra el número de líneas de código que el equipo agregó, quitó y modificó en las protecciones antes de la compilación durante las últimas cuatro semanas.	Informe de Excel Renovación de código
	Lista de próximos eventos. Esta lista se deriva de un elemento web de SharePoint.	No aplicable
	Número de elementos de trabajo activos, resueltos y cerrados. Puede abrir la lista de elementos de trabajo eligiendo cada número. Esta lista se deriva de un elemento web de Team Web Access.	No aplicable
	Lista de las últimas compilaciones y sus estados. Puede ver más detalles si elige una compilación concreta. Esta lista se deriva de un elemento web de Team Web Access. Leyenda: : Compilación no iniciada : Compilación en curso : Compilación correcta : Error de compilación : Compilación detenida : compilación completada parcialmente	Ejecutar, supervisar y administrar compilaciones
	Lista de las protecciones más recientes. Puede ver más detalles si elige una protección concreta. Esta lista se deriva de un elemento web de Team Web Access.	Desarrollar código y administrar cambios pendientes

Actividades necesarias para supervisar la calidad

Para que el panel de calidad sea útil y preciso, el equipo debe realizar las actividades que se describen en esta sección.

Actividades necesarias para realizar un seguimiento del progreso del plan de pruebas

Para que el informe Progreso del plan de pruebas sea útil y preciso, el equipo debe realizar las actividades siguientes:

• Definir casos de prueba y casos de usuario, además de crear vínculos Prueba realizada por entre los casos de prueba y los casos de usuario.

• Definir planes de prueba y asignarles casos de prueba.

• Para las pruebas manuales, marcar los resultados de cada paso de la validación en el caso de prueba como superado o no superado.

  Importante

  Los evaluadores deben marcar un paso de prueba con un estado si se trata de un paso de prueba de validación.El resultado global de un caso de prueba refleja el estado de todos los pasos de prueba marcados por el evaluador.Por consiguiente, el caso de prueba tendrá el estado de no superado si el evaluador marcó algún paso de prueba como no superado o no lo marcó.

  Para las pruebas automatizadas, cada caso de prueba se marca automáticamente como superado o no superado.

• (Opcional) Para admitir el filtrado, asignar rutas de acceso de Iteración y Área a cada caso de prueba.

  Nota

  Para obtener información sobre cómo definir las rutas de área e iteración o establecer permisos, consulte este artículo sobre cómo crear y modificar áreas e iteraciones.

Actividades necesarias para realizar un seguimiento del progreso y de las reactivaciones de los errores

Para que los informes Progreso de los errores y Reactivaciones de errores sean útiles y precisos, el equipo debe realizar las actividades siguientes:

• Definir los errores.

• Actualizar el Estado de cada uno de los errores a medida que el equipo los corrija, compruebe, cierre o reactive.

• (Opcional) Especificar las rutas de acceso de Iteración y de Área de cada error si desea filtrar por esos campos.

Actividades necesarias para realizar un seguimiento del estado de la compilación, la cobertura de código y la renovación de código

Para que los informes Estado de la compilación, Cobertura de código y Renovación de código sean útiles y precisos, los miembros del equipo deben realizar las siguientes actividades:

• Configurar un sistema de compilación. Para utilizar Team Foundation Build, debe configurar un sistema de compilación.

  Para obtener más información, vea Configure and manage your build system.

• Crear definiciones de compilación. Puede crear varias definiciones de compilación y, a continuación, ejecutar cada una de ellas a fin de generar código para una plataforma diferente. Asimismo, puede ejecutar cada compilación para una configuración diferente.

  Para obtener más información, vea este artículo sobre cómo Definir el proceso de compilación.

• Definir las pruebas que se ejecutarán automáticamente como parte de la compilación. Como parte de la definición de compilación, puede definir las pruebas que se ejecutarán como parte de la compilación o que generarán un error si no se superan las pruebas.

  Para obtener más información, vea Utilizar la plantilla predeterminada para el proceso de 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 informe, los miembros del equipo deben instrumentar las pruebas para recopilar esos datos.

  Para obtener más información, vea Ejecutar pruebas en el proceso de compilación.

• Ejecutar compilaciones con regularidad. Puede ejecutar compilaciones a intervalos regulares o después de cada protección. Puede crear compilaciones periódicas cuando utilice el desencadenador de programación.

  Para obtener más información, vea Crear o modificar una definición de compilación y este otro artículo sobre cómo Ejecutar, supervisar y administrar compilaciones.

  Nota

  Aunque un miembro del equipo puede valorar manualmente una compilación utilizando Explorador de compilaciones, esta valoración no se refleja en el informe Indicadores de calidad de la compilación.La valoración de las compilaciones aparece en el informe Resumen de la compilación.Para obtener más información, vea Valorar la calidad de una compilación completada e Informe Resumen de la compilación.

Solucionar problemas de calidad

En la siguiente tabla, se describen los problemas de calidad específicos para los que el panel de calidad puede ayudarle a supervisarlos e identificar las acciones que el equipo puede emprender.

Problema	Informes que se deben revisar	Notas referentes a la solución del problema
Errores de compilación	Estado de la compilación	Una compilación nocturna es el pulso de los proyectos de desarrollo de software. Cuando las compilaciones no se completan correctamente o no superan las pruebas de comprobación de la compilación (BVT), el equipo debe corregir el problema inmediatamente.
Pruebas no superadas	Progreso del plan de pruebas Renovación de código	Cuando las tasas de pruebas no superadas y de renovación de código son altas, el equipo podría investigar por qué el software genera errores con tanta frecuencia. Entre las posibles causas figuran prácticas de desarrollo poco precisas o pruebas demasiado rigurosas para un ciclo de iteración temprano.
Pruebas superadas pero con una alta tasa de errores	Progreso del plan de pruebas Progreso de los errores	Cuando en el mismo período de tiempo hay muchas pruebas superadas y se detectan numerosos errores, el equipo podría investigar las siguientes posibilidades: Es posible que las pruebas no sean suficientemente rigurosas para la actual fase del producto. En iteraciones tempranas, basta con realizar pruebas sencillas. Sin embargo, a medida que el producto madura, las pruebas deberían ir dirigidas a escenarios e integraciones más amplios. Las pruebas podrían estar obsoletas o es posible que se esté probando la funcionalidad equivocada. Otras técnicas de prueba podrían dar mejores resultados. Los errores se notifican pero no se someten a pruebas. Cuando se notifican errores pero no se vinculan a ningún caso de prueba, no se someten a las pruebas de regresión.
Las pruebas están obsoletas	Progreso del plan de pruebas Cobertura de código Renovación de código	Cuando hay muchas pruebas superadas, cambia una cantidad significativa de código y disminuye la cobertura de código, es posible que el equipo no realice pruebas que ejecuten el nuevo código. Dado que las pruebas no se desarrollan a la misma velocidad que los cambios de código, es posible que la cobertura de pruebas no sea suficiente.
El equipo no prueba, cierra o reactiva los errores resueltos	Progreso de los errores	Cuando en el informe Progreso de los errores se registra un aumento de los errores resueltos, eso significa que los desarrolladores están resolviendo errores pero que los evaluadores no los han comprobado ni los han cerrado. El equipo deberá investigar por qué.
Insuficientes pruebas	Progreso del plan de pruebas Renovación de código	Cuando el equipo ejecuta pocas pruebas, la renovación de código es alta y la cobertura de código es inferior a lo esperado, es posible que el equipo tenga que asignar más recursos a las pruebas. Además, deberá asegurarse de que los evaluadores se centren en las mismas funciones que el resto del equipo.
Reactivaciones	Reactivaciones de errores	Cuando el equipo reactiva errores con gran frecuencia, los evaluadores rechazan a menudo las correcciones de los desarrolladores. El equipo debe resolver estos problemas para evitar que se asignen recursos significativos a la revisión de las correcciones rechazadas. Entre las posibles causas se encuentran una notificación deficiente de los errores, una administración inadecuada del laboratorio de pruebas o una evaluación de errores excesivamente rigurosa.
Pruebas unitarias inadecuadas	Cobertura de código Renovación de código	Cuando se producen a la vez una disminución en la cobertura de código y un aumento en la renovación de código, es posible que los desarrolladores estén protegiendo código sin ninguna prueba unitaria correspondiente para cubrirlo. En la mayoría de los casos, la cobertura de código debe aproximarse al 100% si el equipo aplica el desarrollo basado en pruebas o técnicas similares. Si las pruebas unitarias se reutilizan como pruebas BVT, la cobertura de código deberá aparecer en los informes correspondientes.

Ver también

Paneles del portal del proyecto