Traçabilité des exigences

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

La traçabilité des exigences est la possibilité de mettre en relation et de documenter deux phases ou plus d’un processus de développement, qui peuvent ensuite être tracées à la fois vers l’avant ou vers l’arrière depuis son origine. La traçabilité des exigences aide les équipes à obtenir des insights sur des indicateurs tels que la qualité des exigences ou la préparation à l’expédition de l’exigence. Un aspect fondamental de la traçabilité des exigences est l’association des exigences aux cas de test, aux bogues et aux modifications du code.

Lisez le glossaire pour comprendre la terminologie des rapports de test.

Équipes agiles exécutant des tests automatisés

Les équipes agiles ont des caractéristiques, notamment, mais sans s’y limiter

• Cycles de mise en production plus rapides
• Test continu dans un pipeline
• Empreinte de test manuel négligeable ; limité aux tests exploratoires
• Degré élevé d’automatisation

Les sections suivantes explorent la traçabilité du point de vue de la qualité, du bogue et de la source pour les équipes Agile.

Traçabilité de la qualité

Reliez les exigences du projet aux résultats des tests pour une traçabilité de bout en bout, avec un moyen simple de contrôler les résultats des tests. Pour lier des tests automatisés à des exigences, consultez Rapport de test.

1. Dans la section des résultats, sous l’onglet Tests d’un résumé de build ou de mise en production, sélectionnez le ou les tests à lier aux exigences, puis choisissez Lier.

   

2. Choisissez un élément de travail à lier au test sélectionné de l'une des manières suivantes :

   • Choisissez un élément de travail applicable dans la liste des éléments de travail suggérés. La liste est basée sur les derniers éléments de travail affichés et mis à jour.
   • Spécifiez un ID d’élément de travail.
   • Recherchez un élément de travail basé sur le texte de titre.

   

   La liste affiche uniquement les éléments de travail appartenant à la catégorie Exigences.

3. L’équipe souhaite souvent épingler la vue résumée de la traçabilité des exigences à un tableau de bord. Utilisez le widget Qualité des exigences pour cela.

   

4. Configurez le widget Qualité des exigences avec les options requises et enregistrez-le.

   • Requête De configuration requise : sélectionnez une requête d’élément de travail qui capture les exigences, telles que les récits utilisateur dans l’itération actuelle.
   • Données de qualité : spécifiez l’étape du pipeline pour laquelle la qualité des exigences doit être tracée.

   

5. Affichez le widget dans le tableau de bord de l’équipe. Il répertorie toutes les exigences dans l’étendue, ainsi que le taux de réussite pour les tests et le nombre de tests ayant échoué. La sélection d’un nombre de tests ayant échoué ouvre l’onglet Tests pour la build ou la mise en production sélectionnée. Le widget permet également de suivre les exigences sans aucun test associé.

   

Traçabilité des bogues

Les tests donnent une mesure de la confiance nécessaire pour envoyer une modification aux utilisateurs. Un échec de test signale un problème avec la modification. Les échecs peuvent être dus à des erreurs dans la source testée, à un code de test défectueux, à des problèmes environnementaux, à des tests défectueux, etc. Les bogues fournissent un moyen robuste de suivre les échecs des tests et d’amener l’équipe à rendre des comptes pour prendre les mesures correctives nécessaires. Pour associer des bogues aux résultats des tests, consultez la section Rapport de test.

1. Dans la section des résultats de l’onglet Tests , sélectionnez les tests sur lesquels le bogue doit être créé, puis choisissez Bogue. Plusieurs résultats de tests peuvent être associés à un seul bogue, ce qui est généralement le cas lorsque la raison des échecs est attribuée à une cause unique, telle qu'un service dépendant indisponible, une défaillance de la connexion à la base de données ou d'autres problèmes similaires.

   

2. Ouvrez le document de travail. Le bug capture le contexte complet des résultats des tests, y compris les informations clés telles que le message d’erreur, l’arborescence des appels de procédure, les commentaires, etc.

   

3. Affichez le bogue avec le résultat du test, directement dans le contexte, sous l’onglet Tests. L’onglet Éléments de travail répertorie également les exigences liées pour le résultat du test.

   

4. À partir d’un élément de travail, accédez directement aux résultats des tests associés. Le cas de test et le résultat du test spécifique sont liés au bogue.

   

5. Dans l’élément de travail, sélectionnez Cas de test ou Résultat du test pour accéder directement à la page Tests de la build ou de la mise en production sélectionnée. Vous pouvez résoudre l’échec, mettre à jour votre analyse dans le bogue et apporter les modifications nécessaires pour résoudre le problème le cas échéant. Les deux liens vous conduisent à l'onglet Tests, dont les sections par défaut sont Historique et Débogage.

   

Traçabilité des sources

Lors de la résolution des échecs de test qui se produisent de manière cohérente sur une période donnée, il est important de remonter à l’ensemble initial des modifications, à l’origine de l’échec. Cette étape peut contribuer de manière significative à limiter l’étendue de l’identification du test problématique ou de la source en cours de test. Pour découvrir la première instance d’échecs de test et la retracer jusqu’aux modifications de code associées, consultez l’onglet Tests dans la build ou la mise en production.

1. Sous l’onglet Tests, sélectionnez un échec de test à analyser. Selon qu’il s’agit d’une build ou d’une mise en production, choisissez la colonne Build défaillante ou Mise en production défaillante pour le test.

   

   Une autre instance de l'onglet Tests s'ouvre dans une nouvelle fenêtre, montrant le premier cas d'échecs consécutifs pour le test.

   

2. En fonction du pipeline de build ou de mise en production, vous pouvez choisir la vue chronologie ou pipeline pour voir quelles modifications de code ont été validées. Vous pouvez analyser les modifications apportées au code pour identifier la cause racine potentielle de la défaillance du test.

   

Équipes traditionnelles utilisant des tests planifiés

Les équipes qui passent des tests manuels aux tests continus et automatisés, et qui disposent d'un sous-ensemble de tests déjà automatisés, peuvent les exécuter dans le cadre du pipeline ou à la demande. Les tests planifiés, ou « tests automatisés », peuvent être associés aux cas de test dans un plan de test et exécutés à partir des plans de test Azure. Une fois associés, ces tests contribuent aux métriques de qualité des exigences correspondantes.

Aide et support

• Consultez notre page de résolution des problèmes
• Obtenez des conseils sur Stack Overflow et de l’aide sur Developer Community