Partage via

Définir, capturer, trier et gérer les bogues logiciels dans Azure Boards

  • Article

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

Comment suivez-vous et gérez-vous les défauts dans votre code ? Comment vous assurez-vous que les problèmes logiciels et les commentaires des clients sont traités rapidement pour assurer des déploiements logiciels de haute qualité ? Comment progresser efficacement sur les nouvelles fonctionnalités et traiter votre dette technique ?

Au minimum, vous avez besoin d’un moyen de capturer vos problèmes logiciels, de les hiérarchiser, de les affecter à un membre de l’équipe et de suivre la progression. Vous souhaitez gérer vos défauts de code de manière cohérente avec vos pratiques Agile.

Pour soutenir ces scénarios, Azure Boards fournit un type d’élément de travail spécifique pour suivre les défauts de code nommé Bug. Les éléments de travail bogue partagent toutes les fonctionnalités standard des autres types d’élément de travail, avec quelques ajouts. Pour un aperçu des fonctionnalités standard, veuillez consulter la section À propos des éléments de travail et des types d’éléments de travail.

Les bugs offrent également les fonctionnalités suivantes :

  • Options permettant à chaque équipe de choisir la façon dont elle souhaite effectuer le suivi des bogues
  • Outils de test pour capturer les bogues
  • Intégration dans Azure DevOps pour suivre les bogues liés aux builds, aux versions et aux tests

Notes

Les types d’éléments de travail bogue ne sont pas disponibles avec le processus de base. Le processus de base suit les bogues en tant que problèmes et est disponible lorsque vous créez un projet à partir d’Azure DevOps Services ou Azure DevOps Server 2019.1 ou versions ultérieures.

Prérequis

  • Accès au projet : être ajouté à un projet.

  • Autorisations :

    • Vos autorisations Afficher vos éléments de travail dans ce nœud et Modifier les éléments de travail dans ce nœud doivent être définies sur Autoriser. Par défaut, le groupe des contributeurs dispose de ces permissions. Pour plus d’informations, consultez Définir les autorisations de suivi du travail.

    • Pour pouvoir ajouter de nouvelles balises à des éléments de travail, vous devez disposer d’un accès de base ou supérieur et avoir défini les autorisations de création de balises sur Autoriser.. Par défaut, ce jeu d’autorisations est défini sur le groupe Contributeurs.

      Remarque

      Les stakeholders ne peuvent pas ajouter de nouvelles étiquettes, même si la permission est explicitement définie, en raison de leur niveau d’accès. Pour plus d’informations, consultez Référence rapide sur l’accès de partie prenante.

  • Envoyer des éléments de travail par e-mail : Tous les membres du projet, y compris ceux du groupe Lecteurs, peuvent envoyer des e-mails contenant des éléments de travail.

Conseil

Pour signaler un bug, un utilisateur doit avoir au minimum un accès Stakeholder. Un utilisateur doit avoir la permission Modifier les éléments de travail dans ce nœud définie sur Autoriser pour la Chemin d’aire où il ajoute le bug. Pour plus d’informations, consultez Définir les autorisations de suivi du travail.

Type d’élément de travail bogue

L’image suivante montre le type d’élément de travail bogue pour le processus Scrum. Le type d’élément de travail Bug pour les processus Agile et Capability Maturity Model Integration (CMMI) suit des informations similaires. Il apparaît dans le backlog du produit avec les exigences ou dans le Taskboard avec les tâches.

Remarque

Les images que vous voyez depuis votre portail web peuvent différer de celles que vous voyez dans cet article. Ces différences résultent des mises à jour effectuées sur votre application web, des options que vous ou votre administrateur avez activées, et du processus choisi lors de la création de votre projet : Agile, Basique, Scrum ou CMMI. Le processus de base est disponible avec Azure DevOps Server 2019 Update 1 et versions ultérieures.

Une capture d’écran montre un formulaire de type d’élément de travail Bug pour le processus Scrum dans Azure DevOps Server 2020 et le service cloud.

Une capture d’écran montre un formulaire de type d’élément de travail Bug pour le processus Scrum dans Azure DevOps Server 2019.

Champs spécifiques aux bogues

Le type d’élément de travail bogue utilise certains champs spécifiques aux bogues. Pour capturer à la fois le problème initial et les découvertes en cours, utilisez les champs décrits dans le tableau suivant. Pour plus d’informations sur les champs spécifiques au bogue définis pour le processus CMMI (Capability Maturity Model Integration), consultez Informations de référence sur les bogues, les problèmes et les risques. Pour plus d’informations sur tous les autres champs, consultez Index des champs d’élément de travail.

Champ, Groupe ou Onglet

Utilisation

Étapes de reproduction (nom convivial = Étapes de repro)

Utilisez pour capturer suffisamment d’informations afin que les autres membres de l’équipe puissent comprendre pleinement le défaut de code. Inclut les actions entreprises pour rechercher ou reproduire le bogue et le comportement attendu.

Infos systèmeTrouvé dans le build

Informations sur la configuration logicielle et système qui se rapporte au bogue, et les tests à appliquer. Les champs Informations système et Trouvé dans la build sont automatiquement renseignés lorsque vous créez un bogue via un outil de test. Ces champs spécifient des informations sur l’environnement logiciel et créent l’emplacement où le bogue s’est produit. Pour plus d’informations, consultez Tester différentes configurations.

Critères d'acceptation

Fournissez les critères à respecter avant que le bogue puisse être fermé. Avant le début du travail, décrivez les critères d’acceptation des clients aussi clairement que possible. Les équipes doivent utiliser ces critères comme base pour les tests d’acceptation et pour évaluer si un élément est complété de manière satisfaisante.

Intégré dans la build

Spécifie le nom de la build qui contient le code permettant de résoudre le bogue. Ce champ doit être spécifié lorsque vous résolvez le bogue.

Pour Azure DevOps sur site, pour accéder à un menu déroulant de tous les builds qui ont été exécutés, vous pouvez mettre à jour les définitions FIELD pour Trouvé dans le build et Intégré dans le build pour faire référence à une liste globale. La liste globale est mise à jour automatiquement à chaque exécution d'une build. Pour plus d’informations, consultez Requête basée sur les champs de génération et d’intégration de test.

Pour des informations sur la façon de définir des numéros de build, veuillez consulter la section Configuration des pipelines classiques.

Priorité1

  • 1 : Le produit nécessite une résolution réussie et rapide de l’élément de travail avant d’être expédié.
  • 2 : Le produit nécessite une résolution réussie de l’élément de travail avant son expédition, mais il n’a pas besoin d’être traité immédiatement.
  • 3 : La résolution de l’élément de travail est facultative, en fonction des ressources, du temps et des risques.

Gravité1

Évaluation subjective de l’impact d’un bogue ou d’un élément de travail sur le projet ou le système logiciel. Par exemple : Si un lien distant dans l’interface utilisateur (un événement rare) provoque le crash d’une application ou d’une page web (une expérience client sévère), vous pouvez spécifier Gravité = 2 - Élevée et Priorité = 3. Les valeurs autorisées et les recommandations suggérées sont les suivantes :

  • 1 - Critique : doit être résolu. Défaut qui provoque l’arrêt d’un ou plusieurs composants système ou du système complet, ou provoque une altération importante des données. Il n’existe aucune méthode alternative acceptable pour obtenir les résultats requis.
  • 2 - Élevé : envisager de corriger. Défaut qui provoque l’arrêt d’un ou plusieurs composants système ou du système complet, ou provoque une altération importante des données. Une méthode alternative acceptable existe pour obtenir les résultats requis.
  • 3 - Moyen : (par défaut) un défaut qui amène le système à produire des résultats incorrects, incomplets ou incohérents.
  • 4 - Faible : un défaut mineur ou esthétique pour lequel il existe des solutions de contournement acceptables pour obtenir les résultats requis.

Déploiement

Le contrôle Déploiement prend en charge les liens vers et l’affichage des versions qui contiennent des éléments de travail. Pour utiliser le contrôle, vous devez activer les paramètres pour la mise en production. Pour plus d’informations, consultez Lier des éléments de travail à des versions plus loin dans cet article.

Développement

Le contrôle Développement prend en charge les liens vers et l’affichage des liens créés vers des objets de développement. Ces objets incluent les validations et les demandes de tirage Git, ou les ensembles de modifications TFVC et les éléments avec version. Vous pouvez définir des liens à partir de l’élément de travail ou des validations, des demandes de tirage ou d’autres objets de développement. Pour plus d’informations, consultez Lier des éléments de travail au développement plus loin dans cet article.

Notes

1 Pour modifier la sélection de menu ou la liste de choix, consultez Personnaliser l’expérience de suivi du travail. La méthode de personnalisation dépend du modèle de processus utilisé par votre projet.

Choisir la façon dont votre équipe effectue le suivi des bogues

Votre équipe peut suivre les bogues en tant qu’exigences ou tâches. Pour prendre en charge le choix de l’équipe, tenez compte des facteurs suivants.

  • Taille de votre équipe. Les petites équipes peuvent maintenir une empreinte légère en suivant les bogues comme exigences.
  • Exigences de l’organisation pour suivre le travail. Si votre équipe est tenue de suivre les heures, choisissez de suivre les bogues en tant que tâches.
  • Organisation du travail de votre équipe. Si votre équipe s’appuie sur le backlog de produit pour hiérarchiser le travail et ajouter des bogues, suivez les bogues en tant qu’exigences.
  • Les outils que votre équipe souhaite utiliser, comme le volet Planification, le graphique de vélocité, les prévisions, le cumul et les plans de livraison. Le suivi des bogues en tant que tâches empêche l’utilisation de plusieurs de ces outils.

Le tableau suivant récapitule les trois options dont disposent les équipes pour suivre les bogues. Pour en savoir plus et définir l’option pour votre équipe, consultez Afficher les bogues dans les backlogs et les tableaux.

Option

Choisir quand vous souhaitez...

Suivre les bogues en tant qu’exigences

Remarque

  • Les bogues sont attribués à la catégorie de configuration requise

Effectuer le suivi des bogues en tant que tâches

  • Estimer le travail pour les bogues similaires, comme pour les tâches
  • Mettre à jour l’état du bogue sur les tableaux de tâches de sprint
  • Lier les bogues aux exigences en tant qu’éléments enfants
  • Faites glisser les bugs vers le volet Planification pour assigner les bugs à un sprint

Remarque

  • Les bogues sont affectés à la catégorie de tâche
  • Récits utilisateur (Agile), Élément de backlog de produit (Scrum) ou Exigences (CMMI) sont les types d’élément de travail parent naturels pour les bogues
  • Les bugs ne sont pas visibles dans les plans de livraison

Les bogues n’apparaissent pas dans les backlogs et tableaux

  • Gérer les bogues à l’aide de requêtes

Remarque

  • Les bugs sont associés à la catégorie Bugs et n’apparaissent ni dans les backlogs ni dans les tableaux
  • Les bugs ne sont pas visibles dans les backlogs, tableaux, backlogs de sprint, tableaux de tâches, ou plans de livraison
  • Vous ne pouvez pas faire glisser les bugs vers le volet Planification pour les assigner à un sprint

Personnaliser un type d’élément de travail

Vous pouvez personnaliser le bogue et d’autres types d’élément de travail. Vous pouvez également créer des types personnalisés pour suivre les problèmes logiciels ou les commentaires des clients. Pour tous les types d’éléments de travail, vous pouvez personnaliser les éléments suivants :

  • Ajouter ou supprimer des champs personnalisés
  • Ajouter des contrôles personnalisés ou des onglets personnalisés dans le formulaire d’élément de travail
  • Personnaliser les états du workflow
  • Ajouter des règles conditionnelles
  • Choisir le niveau de backlog dans lequel les éléments de travail s’affichent

Avant de personnaliser votre processus, nous vous recommandons de consulter la section À propos de la configuration et de la personnalisation des Azure Boards.

Pour personnaliser votre processus particulier, consultez Personnaliser un processus d’héritage.

Pour personnaliser votre processus particulier, consultez Personnaliser un processus d’héritage ou Personnaliser le modèle de processus XML local.

Ajouter ou capturer des bogues

Vous pouvez définir des bogues à partir de plusieurs outils Azure DevOps différents. Ces outils incluent des backlogs, des tableaux et des outils de test.

Conseil

Par défaut, le champ Titre est le seul champ obligatoire lors de la création d’un bug. Vous pouvez ajouter des bugs de la même manière que vous ajoutez des user stories ou des éléments de backlog produit en utilisant Azure Boards. Vous pouvez rendre certains champs obligatoires en ajoutant des règles conditionnelles basées sur un changement d’état. Pour plus d’informations, veuillez consulter la section Ajouter une règle à un type d’élément de travail.

Ajouter un bogue à partir de votre backlog ou de votre tableau

Si votre équipe a choisi de gérer les bogues avec les exigences, vous pouvez définir des bogues à partir de votre backlog de produit ou tableau. Pour plus d’informations, veuillez consulter la section Créer votre backlog produit ou Utiliser votre tableau.

  • Ajouter un bogue à partir du backlog de produit

    Une capture d’écran montre l’ajout d’un bug depuis le backlog produit.

  • Ajouter un bug depuis le tableau

    Une capture d’écran montre l’ajout d’un bug depuis le tableau.

Conseil

Lorsque vous ajoutez un bogue à partir de votre backlog de produit ou tableau, le bogue se voit automatiquement attribuer le chemin de zone et le chemin d’itération par défaut définis pour l’équipe. Pour plus d’informations, consultez Valeurs par défaut de l’équipe référencées par les backlogs et les tableaux.

Ajouter un bogue à partir de votre backlog de sprint ou de votre tableau des tâches

Si votre équipe a choisi de gérer les bogues avec des tâches, vous pouvez définir des bogues à partir de votre tableau, du backlog de produit, du backlog de sprint ou du tableau des tâches Sprint. Vous ajoutez un bogue en tant qu’enfant à un élément de travail du backlog de produit.

Créer un bogue à partir d’un outil de test

Les deux outils de test que vous pouvez utiliser pour ajouter des bogues lors du test sont l'exécuteur de tests du portail Web et l'extension de test et de retour d'expérience.

  • Exécuteur de tests : lorsque vous exécutez des tests manuels, vous pouvez choisir de Créer un bogue. Pour plus d'informations, consultez Planifier des tests manuels.

    Une capture d’écran montre Test Runner, où vous pouvez ajouter un bug.

  • Extension Test & Feedback : lors de l’exécution de tests exploratoires, vous pouvez choisir de créer un bogue ou de créer une tâche. Pour plus d’informations, veuillez consulter la section Test exploratoire avec l’extension Test & Feedback.

    Une capture d’écran montre l’extension Test & Feedback, où vous pouvez ajouter un bug ou une fonctionnalité de tâche.

Cycle de vie des bogues et états de workflow

Comme pour tous les autres types d’élément de travail, le type d’élément de travail bogue a un workflow bien défini. Chaque workflow se compose de trois États ou plus et d’une Raison. Les raisons spécifient la raison pour laquelle l’élément est passé d’un état à un autre. Les images suivantes illustrent le workflow de bogue par défaut défini pour les processus Agile, Scrum et CMMI.

Agile Scrum CMMI
Un diagramme montre les états du workflow des bugs dans le modèle de processus Agile. Un diagramme montre les états du workflow des bugs dans le modèle de processus Scrum. Un diagramme montre les états du workflow des bugs dans le modèle de processus CMMI.

Pour les bogues Scrum, vous modifiez l’État de Validé (similaire à Actif) à Terminé. Pour Agile et CMMI, vous devez d’abord résoudre le bogue et sélectionner une raison qui indique que le bogue est résolu. En règle générale, la personne qui a créé le bogue vérifie ensuite le correctif et met à jour l’État de Résolu à Fermé. Si vous découvrez plus de travail après avoir résolu ou fermé un bug, réactivez-le en définissant l’État sur Engagé ou Actif.

Remarque

Le type d’élément de travail bogue du processus Agile avait précédemment une règle qui réaffectait le bogue à la personne qui l’a créé. Cette règle a été supprimée du processus système par défaut. Vous pouvez rétablir cette automatisation en ajoutant une règle. Pour un processus Inheritance, veuillez consulter la section Automatiser la réaffectation en fonction du changement d’état.

Vérifier un correctif

Pour vérifier un correctif, un développeur ou un testeur tente de reproduire le bogue et recherche d’autres comportements inattendus. Si nécessaire, ils doivent réactiver le bogue.

Lors de la vérification d’un correctif de bogue, vous pouvez constater que le bogue n’a pas été résolu ou que vous n’êtes pas d’accord avec la résolution. Dans ce cas, discutez du bogue avec la personne qui l’a résolu, trouvez un accord et réactivez éventuellement le bogue. Si vous réactivez un bogue, incluez les raisons de la réactivation dans la description du bogue.

Fermer un bogue

Vous fermez un bug lorsqu’un membre de l’équipe le vérifie comme étant corrigé. Toutefois, vous pouvez également fermer un bogue pour l’une des raisons suivantes. Les raisons disponibles dépendent du processus du projet et des états de transition du bug.

Processus Agile :

  • Différé : reporter la correction du bogue jusqu’à la prochaine version du produit.
  • Résolu : le bogue est vérifié comme étant résolu.
  • Doublon : le bogue suit un autre bogue actuellement défini. Vous pouvez lier chaque bogue avec le type de lien Doublon/Doublon de et fermer l’un des bogues.
  • Correspond aux spécifications : la fonctionnalité fonctionne comme prévu.
  • Reproduction impossible : les tests prouvent que le bogue ne peut pas être reproduit.
  • Obsolète : la fonctionnalité du bogue n’est plus dans le produit.
  • Copié dans backlog : un récit utilisateur a été ouvert pour suivre le bogue.

Processus Scrum :

  • Pas un bogue : il a été vérifié qu’il ne s’agit pas d’un bogue.
  • Doublon : le bogue suit un autre bogue actuellement défini. Vous pouvez lier chaque bogue avec le type de lien Doublon/Doublon de et fermer l’un des bogues.
  • Supprimé du backlog : il a été vérifié qu’il ne s’agit pas d’un bogue. Supprimez le bogue du backlog.
  • Travail terminé : le bogue a été vérifié comme corrigé.

Processus CMMI :

  • Différé : reporter la correction du bogue jusqu’à la prochaine version du produit.
  • Doublon : le bogue suit un autre bogue actuellement défini. Vous pouvez lier chaque bogue avec le type de lien Doublon/Doublon de et fermer l’un des bogues.
  • Rejeté : il a été vérifié qu’il ne s’agit pas d’un bogue.
  • Vérifié : le bogue est vérifié comme corrigé.

Conseil

Après qu’un bug a été fermé et que la correction est activement déployée, la bonne pratique recommandée est de ne jamais le rouvrir en raison d’une régression. Au lieu de cela, vous devez envisager d’ouvrir un nouveau bogue et d’établir un lien vers l’ancien bogue fermé.

Il est toujours judicieux de décrire d’autres détails pour la fermeture d’un bogue dans le champ Discussion afin d’éviter toute confusion future quant à la raison pour laquelle le bogue a été fermé.

Automatiser la fermeture des bogues lors de la fusion des demandes de tirage

Si votre équipe utilise un dépôt Git, vous pouvez définir l’état dans les bogues liés et d’autres éléments de travail pour qu’il se ferme en cas de fusion réussie des demandes de tirage. Pour plus d’informations, consultez Définir l’état de l’élément de travail dans une demande de tirage plus loin dans cet article.

Répertorier et trier les bogues

La plupart des équipes, quelle que soit l’option choisie pour suivre les bogues, définissent une ou plusieurs requêtes de bogues. Avec les requêtes, vous pouvez répertorier les bogues actifs, les bogues non attribués, les bogues obsolètes, les tendances des bogues, etc. Vous pouvez ajouter des requêtes et des graphiques de requêtes à vos tableaux de bord d’équipe pour surveiller le statut et l’avancement des bugs.

Requêtes de bogue

Ouvrez une requête partagée ou utilisez l’éditeur de requête pour créer des requêtes de bogue utiles, comme les options suivantes :

  • Bogues actifs par priorité (State <> Done ou State <> Closed)
  • Bogues en cours (State = Committed ou State = Active)
  • Bogues à corriger pour une version cible (Tags Contains RTM)
  • Des bugs récents, comme des bugs ouverts dans les trois dernières semaines (Created Date > @Today-21).

Lorsque vous avez les requêtes d’intérêt pour votre équipe, vous pouvez créer des graphiques de statut ou de tendance. Vous pouvez également ajouter le graphique que vous créez à un tableau de bord.

Mode de tri dans les résultats de la requête

Après avoir commencé à coder et à tester, tenez des réunions périodiques de triage pour réviser et classer vos bugs. En règle générale, le propriétaire du projet est en charge des réunions de triage des bogues. Les responsables d’équipe, les analystes d’entreprise et d’autres parties prenantes qui peuvent parler des risques spécifiques du projet assistent aux réunions de triage.

Le propriétaire du projet peut définir une requête partagée pour les bogues nouveaux et rouverts afin de répertorier les bogues à trier.

Depuis la page de résultats de requête, vous pouvez naviguer dans la liste des éléments de travail de type bug en utilisant les flèches haut et bas. Lorsque vous passez en revue chaque bogue, vous pouvez l’affecter, lui ajouter des détails ou définir sa priorité.

Capture d’écran du volet droit Résultats de la requête, Bogues actifs et Mode triage.

Organiser et affecter des bogues à un sprint

Si votre équipe effectue le suivi des bogues en tant qu’exigences, affichez la liste des bogues actifs de votre backlog. Avec la fonction de filtre, vous pouvez vous concentrer uniquement sur les bogues. À partir du backlog de produit, vous pouvez également effectuer les tâches suivantes :

Si votre équipe effectue le suivi des bogues en tant que tâches, utilisez des requêtes managées pour répertorier et trier les bogues. Dans chaque sprint, vous voyez les bugs assignés au sprint depuis le backlog de sprint ou le Taskboard.

Éléments du tableau des tâches et éléments de liste de requête

Vous pouvez remarquer et vous demander pourquoi les éléments affichés dans un tableau des tâches de sprint peuvent différer d’une liste de requêtes créée dans un backlog de sprint correspondant.

Il est possible d’assigner des tâches ou des bugs à une itération mais de ne pas les lier à un élément de backlog parental. Ces éléments apparaissent dans la requête créée, mais peuvent ne pas s’afficher dans le tableau des tâches proprement dit. Le système exécute la requête, puis applique quelques processus en arrière-plan avant d’afficher les éléments du tableau de tâches.

Ces raisons peuvent entraîner l’absence des éléments de travail appartenant à la catégorie de tâche dans un backlog des sprints ou un tableau de tâches :

  • La tâche ou le bug n’est pas lié à un élément de backlog parental. Seuls les bugs et les tâches liés à un élément de backlog produit parental (Scrum), une user story (Agile) ou une exigence (CMMI) avec un chemin d’itération défini sur le sprint apparaissent dans la page du backlog de sprint.
  • La tâche ou le bogue est un parent d’une autre tâche ou d’un autre bogue, ou le récit utilisateur est un parent d’un autre récit utilisateur. Si vous créez une hiérarchie de tâches, bugs ou user stories, seuls les tâches de niveau enfant ou les stories de niveau enfant au bas de la hiérarchie apparaissent. Pour plus d’informations, consultez Résoudre les problèmes de réorganisation et d’imbrication.
  • Le parent lié à la tâche ou au bogue correspond à un élément de backlog défini pour une autre équipe, ou le chemin de zone de l’élément parent du backlog de la tâche ou du bogue est différent du chemin de zone de la tâche ou du bogue.

Créer des tests inline liés à des bogues

Lorsque votre équipe effectue le suivi des bogues en tant qu’exigences, vous pouvez utiliser le tableau pour ajouter des tests afin de vérifier les correctifs de bogues.

Capture d’écran d’un tableau, trois colonnes montrant des tests en ligne ajoutés et liés aux bugs.

Mettre à jour l’état du bogue

Vous pouvez mettre à jour l’état du bogue en faisant glisser et en déposant des bogues dans une nouvelle colonne sur une carte.

Personnaliser votre tableau pour suivre les états intermédiaires

Vous pouvez ajouter des colonnes intermédiaires pour suivre l’état de votre bogue sur la carte. Vous pouvez également définir des requêtes qui filtrent en fonction de l’état d’une colonne de tableau. Pour plus d’informations, consultez les articles suivants :

Automatiser la réaffectation des bogues en fonction de l’état du workflow

Pour automatiser les actions de sélection, ajoutez des règles personnalisées à votre type d’élément de travail bogue. Par exemple, ajoutez une règle comme illustré dans l’image suivante. Cette règle spécifie de réaffecter un bug à la personne qui l’a ouvert lorsqu’un membre de l’équipe le résout. En règle générale, cette personne vérifie que le bogue est résolu et ferme le bogue. Pour plus d’informations, consultez Appliquer des règles aux états de flux de travail (processus d’héritage).

Capture d’écran de la règle définie pour réaffecter le bogue en fonction de l’état résolu.

Définir l’état de l’élément de travail dans la demande de tirage

Lorsque vous créez une demande de tirage, vous pouvez définir la valeur d’État des éléments de travail liés dans la description. Suivez la syntaxe : {state value}: #ID.

Lorsque vous fusionnez la demande de tirage, le système lit la description et met à jour l’état de l’élément de travail. L’exemple suivant définit les éléments de travail #300 et #301 comme Résolus, et #323 et #324 comme Fermés.

Capture d’écran de la définition de l’état d’un élément de travail dans une pull request.

Remarque

Cette fonctionnalité nécessite l’installation d’Azure DevOps Server 2020.1. Pour plus d’informations, consultez Notes de publication d’Azure DevOps Server 2020 Update 1 RC1, Tableaux.

Intégration dans Azure DevOps

L’une des méthodes utilisées par Azure DevOps pour prendre en charge l’intégration consiste à lier des objets à d’autres objets. En plus de lier des éléments de travail entre eux, vous pouvez également lier des éléments de travail à d’autres objets. Créez un lien vers des objets, comme les builds, les versions, les branches, les validations et les demandes de tirage, comme illustré dans l’image suivante.

Diagramme montrant les types de liens utilisés pour lier les éléments de travail aux objets de build et de déploiement.

Vous pouvez ajouter un lien à partir de l’élément de travail ou des objets de build et de mise en production.

Le contrôle Développement prend en charge la liaison et l’affichage des liens créés vers les builds, les commits Git et les pull requests. Lorsqu’un référentiel TFVC est utilisé, il prend en charge les liens vers les ensembles de modifications et les éléments versionnés. Choisir le lien ouvre l’élément correspondant dans un nouvel onglet de navigateur. Pour plus d’informations, consultez Diriger le développement Git depuis un élément de travail .

Une capture d’écran montre le contrôle Développement sur le formulaire d’élément de travail avec des exemples de liens vers des builds, pull requests et commits.

Le contrôle Déploiement prend en charge les liens vers et l’affichage des versions qui contiennent des éléments de travail. Par exemple, l’image suivante montre plusieurs versions qui contiennent des liens vers l’élément de travail actuel. Vous pouvez développer chaque version pour afficher des détails sur chaque étape. Vous pouvez choisir le lien pour chaque version et étape pour ouvrir la version ou phase correspondante. Pour plus d’informations, consultez Lier des éléments de travail aux déploiements.

Une capture d’écran montre le contrôle Déploiement sur le formulaire d’élément de travail avec des exemples de versions.

Des pipelines sont souvent définis pour s’exécuter automatiquement lorsqu’une nouvelle validation se produit dans un dépôt Git. Les éléments de travail associés aux pipelines de validation s’affichent dans le cadre de l’exécution du pipeline si vous personnalisez les paramètres de votre pipeline. Pour plus d’informations, consultez Personnaliser votre pipeline.

Capture d’écran des paramètres de Pipeline avec Lier automatiquement les éléments de travail dans cette exécution depuis la branche sélectionnée en surbrillance.

Créer ou modifier un élément de travail en cas d’échec de build

Si vous utilisez des pipelines classiques (non YAML), vous pouvez créer des éléments de travail en cas d’échec de build. Pour plus d’informations, veuillez consulter la section Créer un élément de travail en cas d’échec.

Vous pouvez suivre le statut des bugs, les assignations et les tendances en utilisant des requêtes que vous pouvez afficher sous forme de graphique et ajouter à un tableau de bord. Par exemple, voici deux exemples montrant les tendances des bogues actifs par état et les bogues actifs par priorité au fil du temps.

Capture d’écran de deux graphiques de requêtes de bogues actifs, Tendances des bogues par état et par priorité.

Pour plus d’informations sur les requêtes, graphiques et tableaux de bord, veuillez consulter requêtes gérées, graphiques et tableaux de bord.

Utiliser les vues Analytics et le service Analytics pour créer des rapports de bogues

Le service Analytics est la plateforme de création de rapports pour Azure DevOps. Cela remplace la plateforme précédente basée sur SQL Server Reporting Services.

Les vues analytiques fournissent des filtres prédéfinis pour afficher les éléments de travail. Quatre vues analytiques sont prises en charge pour la création de rapports de bogues. Vous pouvez utiliser ces vues telles qu’elles sont définies, ou les modifier davantage pour créer une vue filtrée personnalisée.

  • Bogues - Ensemble de l’historique par mois
  • Bogues - Dernières 26 semaines
  • Bogues - 30 derniers jours
  • Bogues - Aujourd’hui

Pour plus d’informations sur l’utilisation des vues analytiques, veuillez consulter À propos des vues analytiques et Créer un rapport de bugs actifs dans Power BI basé sur une vue analytique personnalisée.

Vous pouvez utiliser Power BI pour créer des rapports plus complexes qu’une requête. Pour plus d’informations, consultez Se connecter avec Power BI Data Connector.

Rapports de bugs SQL Server prédéfinis

Les rapports suivants sont pris en charge pour les processus Agile et CMMI.

Ces rapports nécessitent que vous ayez SQL Server Analysis Services et SQL Server Reporting Services configurés pour votre projet. Pour savoir comment ajouter des rapports SQL Server pour un projet, consultez Ajouter des rapports à un projet.

Extensions de la Place de marché

Il existe plusieurs extensions de la Place de marché liées aux bogues. Consultez Place de marché pour Azure DevOps.

Pour plus d’informations sur les extensions, consultez Extensions Azure Boards développées par Microsoft.

Étapes suivantes

Utiliser des modèles pour ajouter et mettre à jour des éléments de travail

Backlog de produit et tableau

Board

Backlog de sprint et tableau des tâches

Intégration dans Azure DevOps

Ressources du secteur