Rastreabilidad de requisitos

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

La rastreabilidad de requisitos es la capacidad de relacionar y documentar dos o más fases de un proceso de desarrollo, que luego se pueden rastrear tanto hacia delante como hacia atrás desde su origen. Los requisitos de seguimiento permiten a los equipos a obtener información sobre indicadores como la calidad de los requisitos o la preparación para enviar el requisito. Un aspecto fundamental de la rastreabilidad de los requisitos es la asociación de estos para probar casos, errores y cambios de código.

Lea el glosario para comprender la terminología del informe de prueba.

Equipos ágiles que ejecutan pruebas automatizadas

Los equipos ágiles tienen características, entre las que se incluyen las siguientes:

• Ciclos de versión más rápidos
• Pruebas continuas en una canalización
• Superficie de pruebas manuales insignificante; limitada a las pruebas exploratorias
• Alto grado de automatización

En las secciones siguientes se explora la rastreabilidad desde el punto de vista de la calidad, el error y el origen para los equipos ágiles.

Rastreabilidad de la calidad

Para garantizar que los requisitos de usuario cumplan los objetivos de calidad, los requisitos de un proyecto se pueden vincular a los resultados de las pruebas, que se pueden ver en el panel del equipo. Esto permite la rastreabilidad de un extremo a otro con una forma sencilla de supervisar los resultados de las pruebas. Para vincular pruebas automatizadas con requisitos, consulte el informe de prueba sobre una compilación o versión.

1. En la sección de resultados, en la pestaña Pruebas de un resumen de compilación o versión, seleccione las pruebas que se vincularán a los requisitos y elija Vincular.

   

2. Elija un elemento de trabajo que se vinculará a las pruebas seleccionadas de una de las maneras especificadas:

   • Elija un elemento de trabajo aplicable en la lista de elementos de trabajo sugeridos. La lista se basa en los elementos de trabajo vistos y actualizados más recientemente.
   • Especifique un identificador de elemento de trabajo.
   • Busque un elemento de trabajo basado en el texto del título.

   

   En la lista solo se muestran los elementos de trabajo que pertenecen a la categoría Requisitos.

3. A menudo, Teams quiere anclar la vista resumida de los requisitos de rastreabilidad a un panel. Para ello, use el widget Calidad de los requisitos.

   

4. Configure el widget Calidad de los requisitos con las opciones necesarias y guárdelo.

   • Consulta de requisitos: seleccione una consulta de elemento de trabajo que capture los requisitos, como los casos de usuario en la iteración actual.
   • Datos de calidad: especifique la fase de la canalización para la que se debe realizar un seguimiento de la calidad de los requisitos.

   

5. Vea el widget en el panel del equipo. Enumera todos los requisitos dentro del ámbito, junto con la tasa de superación de las pruebas y el recuento de pruebas no superadas. Al seleccionar un recuento de pruebas no superadas, se abre la pestaña Pruebas de la compilación o versión seleccionada. El widget también permite realizar un seguimiento de los requisitos sin pruebas asociadas.

   

Rastreabilidad de errores

Las pruebas proporcionan una medida de la confianza para enviar un cambio a los usuarios. Un error de prueba indica un problema con el cambio. Los errores pueden producirse por muchas razones, como errores en el origen en pruebas, código de prueba incorrecto, problemas de entorno, pruebas no confiables, etc. Los errores proporcionan una manera sólida de realizar un seguimiento de los errores de prueba y controlar la responsabilidad en el equipo para llevar a cabo las acciones correctivas necesarias. Para asociar errores con los resultados de las pruebas, visite el informe de pruebas de una compilación o versión.

1. En la sección de resultados de la pestaña Pruebas, seleccione las pruebas con las que se debe crear el error y elija Error. Se pueden asignar varios resultados de pruebas a un único error. Suele hacerse cuando el motivo de los errores se imputa a una única causa, como la falta de disponibilidad de un servicio dependiente, un error de conexión de base de datos o problemas similares.

   

2. Abra el elemento de trabajo para ver el error. Captura el contexto completo de los resultados de la prueba, así como información clave, como el mensaje de error, el seguimiento de la pila, comentarios, etc.

   

3. Vea el error con el resultado de la prueba, directamente en contexto, dentro de la pestaña Pruebas. En la pestaña Elementos de trabajo también se enumeran los requisitos vinculados al resultado de la prueba.

   

4. En un elemento de trabajo, vaya directamente a los resultados de pruebas asociados. Tanto el caso de prueba como el resultado de la prueba específico están vinculados al error.

   

5. En el elemento de trabajo, seleccione Caso de prueba o Resultado de la prueba para ir directamente a la página Pruebas de la compilación o versión seleccionada. Puede solucionar el error, actualizar el análisis en el error y hacer los cambios necesarios para corregir el problema según corresponda. Aunque ambos vínculos le llevan a la pestaña Pruebas, las secciones predeterminadas que se muestran son Historial y Depuración, respectivamente.

   

Rastreabilidad del origen

Al solucionar errores de prueba que se producen de forma coherente durante un período de tiempo, es importante realizar un seguimiento al conjunto inicial de cambios, donde se originó el error. Esto puede ayudar a reducir significativamente el ámbito para identificar la prueba problemática o el origen en pruebas. Para detectar la primera instancia de errores de prueba y realizar un seguimiento de los cambios de código asociados, vaya a la pestaña Pruebas de la compilación o versión.

1. En la pestaña Pruebas, seleccione un error de prueba que se va a analizar. En función de si se trata de una compilación o una versión, elija la columna Compilación con errores o Versión con errores para la prueba.

   

2. Se abrirá otra instancia de la pestaña Pruebas en una nueva ventana, en la que se muestra la primera instancia de errores consecutivos para la prueba.

   

3. En función de la canalización de compilación o versión, puede elegir la escala de tiempo o la vista de canalización para ver qué cambios de código se confirmaron. Puede analizar los cambios de código para identificar la posible causa principal del error de prueba.

   

Equipos tradicionales que usan pruebas planeadas

Los equipos que pasan de las pruebas manuales a las pruebas continuas (automatizadas), y que tienen un subconjunto de pruebas ya automatizadas, pueden ejecutarlas como parte de la canalización o a petición (consulte el informe de prueba). Se conoce como Pruebas planeadas; las pruebas automatizadas pueden asociarse a los casos de prueba de un plan de prueba y ejecutarse desde Azure Test Plans. Una vez asociadas, estas pruebas contribuyen a las métricas de calidad de los requisitos correspondientes.

Ayuda y soporte técnico

• Vea la guía de solución de problemas
• Obtenga consejos sobre Stack Overflow y soporte técnico de Developer Community