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é

Pour garantir que les exigences des utilisateurs répondent aux objectifs de qualité, les exigences d’un projet peuvent être liées aux résultats des tests, qui peuvent ensuite être affichés dans le tableau de bord de l’équipe. Cela permet une traçabilité de bout en bout avec un moyen simple de surveiller les résultats des tests. Pour lier les tests automatisés aux exigences, consultez le rapport de test dans la build ou la mise en production.

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 aux tests sélectionnés de l’une des manières spécifiées :

   • 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 se produire pour de nombreuses raisons, telles que des erreurs dans la source testée, un code de test incorrect, 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 le rapport de test dans la build ou la mise en production.

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 test peuvent être mappés à un seul bogue. Cela se produit généralement lorsque la raison des échecs est attribuable à une seule cause, telle que l’indisponibilité d’un service dépendant, un échec de connexion de base de données ou des problèmes similaires.

   

2. Ouvrez l’élément de travail pour voir le bogue. Il 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. Bien que les deux liens vous mènent à l’onglet Tests, la section par défaut affichée est Historique et Déboguer respectivement.

   

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. Cela 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.

   

2. Cela ouvre une autre instance de l’onglet Tests dans une nouvelle fenêtre, montrant la première instance de défaillance consécutive pour le test.

   

3. 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 (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 (voir rapport de test). Appelés tests planifiés, les tests automatisés peuvent être associés aux cas de test dans un plan de test et exécutés à partir de Azure Test Plans. 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