Comment créer un modèle de suivi des bugs dans Jira
Un modèle de suivi des bogues est un format prédéfini pour documenter et signaler les bogues dans le développement logiciel. Disposer d’un modèle permet de consigner systématiquement les détails essentiels, ce qui facilite le suivi des bogues, leur priorisation et la communication au sein d’une équipe.
Jira est un outil de suivi des tickets d’Atlassian, et c’est probablement l’un des outils de suivi des bogues les plus populaires utilisés pour la gestion de projets de développement (notamment dans les environnements agiles). Je l’ai utilisé sur de nombreux projets ces dernières années, en Scrum comme en Kanban, et je le trouve très polyvalent.
Dans cet article, je vais passer en revue la polyvalence de Jira dans le suivi des bogues, la personnalisation et la gestion des workflows, ainsi que l'amélioration de la remontée des bogues avec Jira.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Que vous soyez responsable de la configuration des workflows sur Jira ou que vous signaliez simplement les anomalies, il est utile de savoir comment cela fonctionne. Jira ne se limite pas à la gestion des bogues, mais ici, nous allons principalement nous focaliser sur le suivi des bogues plutôt que sur la gestion d’autres types de tickets.
Mise en place d’un nouveau projet avec Jira Software
Si votre projet est nouveau, la première chose à faire est de configurer le projet sur Jira. Cette tâche est généralement attribuée au scrum master ou au chef de projet, mais si votre poste de QA recouvre également l’un de ces rôles, cette tâche pourrait vous revenir. Ce n’est pas compliqué et, de toute façon, ça devrait être à faire une seule fois !
L’inscription est gratuite, et pour les petits projets de moins de dix utilisateurs, vous pouvez utiliser la formule gratuite. Si vous avez une équipe plus grande ou besoin de fonctionnalités avancées, optez pour l’une des offres payantes. Je ne rentrerai pas dans les détails, mais vous pouvez consulter la page des tarifs Jira si cela vous intéresse.
Je n’ai créé de nouveaux projets que pour donner des cours, mais la procédure est assez intuitive. Vous aurez la possibilité de choisir entre différents types de projets pour le développement logiciel :
Types de projets
- Un projet Kanban vous permet de créer des tableaux Kanban. Vous pouvez utiliser le modèle classique avec les étapes traditionnelles : À faire, En cours et Terminé.
- Scrum – Ce modèle permet à l’équipe de gérer ses sprints et le backlog selon la méthodologie Scrum.
- Suivi des bogues – Un modèle simple qui permet le suivi des tickets sans appliquer de méthodologie agile.
Tous les projets peuvent être personnalisés pour inclure les étapes, transitions et statuts exigés par le projet.
Pour ce tutoriel, j’utiliserai le modèle de projet Scrum afin que vous puissiez suivre à la fois les histoires et les bogues dans un seul projet, mais rassurez-vous — tout ce que je présente ici peut s’appliquer aussi aux autres types de projets !
Types de tickets
Les types de tickets proposés par défaut dans Jira sont :
- Epic : En agile, une epic est une collection de haut niveau d’histoires d’utilisateur et de tâches.
- Bogue : Le type de ticket que nous utilisons dans Jira pour suivre les bogues et les anomalies détectés. Nous allons nous concentrer sur ceux-ci dans la suite de l’article.
- Histoire : Une histoire d’utilisateur agile (la description d’une fonctionnalité ou d’un besoin à développer et tester).
- Tâche : Généralement utilisée pour suivre des points spécifiques ou des choses à faire, par exemple, rechercher un nouvel outil d’automatisation de tests ou mettre à jour la documentation.
- Sous-tâche : Il s’agit d’une tâche individuelle assignée à un membre de l’équipe et qui est un sous-élément du ticket « Tâche » mentionné ci-dessus.
Comme je l’ai déjà indiqué, Jira est très polyvalent et, si besoin, vous pouvez créer à tout instant votre propre type de ticket dans le projet.
Par exemple, j’ai déjà travaillé sur un projet dans lequel nous avions créé un type de ticket à part pour les améliorations. Celles-ci étaient similaires aux histoires d’utilisateur, mais concernaient principalement des évolutions de fonctionnalités déjà existantes dans l’application.
Ou vous pouvez créer un type de ticket pour les cas de test, mais nous aborderons cela un peu plus tard, lorsque nous couvrirons les plugins disponibles et les outils d'intégration Jira.
Suivi des bugs avec Jira
Passons à ce qui nous intéresse en tant que testeurs : le signalement et le suivi des bugs. Bien que Jira soit un outil de gestion de projet, et non spécifiquement un outil de suivi des bugs, nous, les QA, allons probablement l'utiliser pour beaucoup de signalement de bugs 😁.
Workflow et cycle de vie des bugs
Le workflow de bug par défaut (et pour tous les tickets, en fait) fourni par Jira ressemble à ceci :
Lorsqu’un ticket est ouvert, il est créé avec le statut 'À faire'. Ensuite, le ticket, ou bug, peut être déplacé vers n'importe lequel des autres statuts.
L’équipe de gestion des tests, le scrum master ou le chef de projet est généralement en charge de concevoir tout autre workflow personnalisé.
Le workflow reflète le cycle de vie du bug que vous souhaitez avoir dans le projet. Vous pouvez conserver celui par défaut, qui est simple, ou bien le rendre aussi complexe que nécessaire. Honnêtement, je n’ai jamais travaillé sur un projet qui n’avait pas ses propres statuts et transitions personnalisés.
Pour personnaliser le cycle de vie, vous devez aller dans les paramètres du projet, sélectionner le type de ticket bug, puis cliquer sur 'Modifier le workflow'.
Ici, vous pouvez ajouter de nouveaux statuts et choisir une transition spécifique si nécessaire. Voici un exemple :
Dans ce cas, lorsqu’un nouveau ticket est créé, il aura le statut 'À faire', d’où il pourra uniquement passer à 'En cours'. Ensuite, avant que le bug ne puisse être testé, le code doit être relu. L’équipe QA peut le clôturer une fois qu’il est validé dans le statut 'En QA'. Bien sûr, la relecture de code et la validation QA peuvent échouer, et dans ce cas, le bug sera renvoyé à 'En cours'.
Création d’un workflow étape par étape
Je vais passer en revue chaque étape à suivre pour passer du premier workflow au deuxième (ou à tout workflow personnalisé que vous jugerez adapté à votre projet) :
1. Commencez par cliquer sur le bouton 'Modifier le workflow'
2. Pour ajouter un nouveau statut, cliquez sur l’un des statuts—les statuts sont répartis en trois catégories : 'À faire', 'En cours' et 'Terminé', chacune ayant une couleur spécifique. Vous pouvez choisir là où votre statut sera le plus pertinent. J’ai décidé que les statuts 'En code review' et 'En QA' signifient que le ticket est toujours en cours :
Vous pouvez également avoir d'autres statuts 'À faire'; par exemple, un statut 'En revue' pour lorsqu’une nouvelle fonctionnalité est créée et que le Product Owner ou le Business Analyst doit encore ajouter des informations à son sujet, ou lorsque l’équipe doit encore la détailler et en évaluer la complexité ou les points d’histoire.
3. Une fois que vous avez ajouté le nouveau statut, vous pouvez y ajouter une transition. Par défaut, le statut pourra être mis à jour depuis n’importe quel autre statut. Si vous ne souhaitez pas de règles de transition spécifiques, cela convient. Cependant, un bon workflow permettrait de déplacer les bugs et tickets vers certains statuts uniquement après avoir suivi certaines étapes du processus.
Dans mon exemple ci-dessus, l’équipe QA ne peut pas commencer à vérifier la correction avant qu’un autre développeur n’ait relu le code. Pour ajouter cette transition, cliquez sur le bouton 'Transition' et entrez les détails :
4. Vous pouvez également supprimer toutes les transitions ou statuts existants si vous souhaitez que tout soit 100% personnalisé.
5. Une fonctionnalité vraiment intéressante est la désignation automatique. Cela se fait aussi depuis le workflow, où vous pouvez définir un utilisateur assigné par défaut lorsqu’une certaine transition est effectuée sur le ticket (c’est aussi un avantage clé des logiciels de suivi des tickets).
Par exemple, après qu’un bug a été « Revu » et déplacé vers « En QA », il est automatiquement assigné à un certain testeur ou au responsable des tests qui décidera qui s’en occupe. Il en va de même pour « En cours » et l’équipe de développement. Les problèmes nouvellement créés peuvent être automatiquement assignés à un chef de projet ou un product owner, qui les priorisera dans le backlog. C’est hautement personnalisable, vous pouvez donc l’adapter comme vous le souhaitez pour votre équipe.
Même si vous n’êtes pas responsable de la configuration du cycle de vie des tickets, ou si vous n’avez pas accès aux paramètres du projet, vous pouvez voir le workflow de chaque ticket Jira en développant la liste déroulante des statuts :
Visualiser les tickets dans Jira
Si le projet n’est pas dédié au suivi des bugs, vous pouvez visualiser les tickets en cours sur les tableaux Kanban ou Scrum :
Ceci n’est qu’une démonstration ; je doute que vous ayez jamais la chance d’avoir un sprint avec seulement une user story et un bug 😅.
En cliquant sur n’importe quel ticket, vous verrez ses détails. Ceux-ci comprennent, sans s’y limiter, un ID (créé automatiquement par Jira), un titre, une description, le rapporteur, l’assigné, ainsi que toute pièce jointe ou commentaire ajouté par les membres de l’équipe.
Les champs sont personnalisables également, et je vais le montrer quand nous verrons ce qu’il faut inclure dans un bon rapport de bug.
Assignés
Tous les tickets Jira peuvent être assignés à un membre spécifique de l’équipe. Vous pouvez mentionner quelqu’un dans les commentaires ou la description en utilisant le caractère @ avant le nom de l’utilisateur.
Vous recevrez des notifications lorsque quelqu’un vous mentionne et lorsqu’un ticket qui vous est assigné, ou que vous avez reporté, est mis à jour. Vous pouvez également « regarder » des tickets. Vous serez notifié de toute mise à jour sur les tickets suivis, quel que soit le rapporteur ou l’assigné.
Signalement de bugs dans Jira
Une application avec peu de bugs est le but de tous, mais soyons honnêtes : les testeurs sont toujours ravis lorsqu’on découvre un bon bug.
Mais un bon bug ne vaut que par la qualité de son signalement – un bon rapport de bug garantit qu’il sera corrigé avec un minimum d’allers-retours entre les équipes test et développement. Jira est un excellent outil de suivi de bugs. Je l’ai déjà mentionné ? Il offre beaucoup de flexibilité.
Pour créer un nouveau ticket, cliquez sur le gros bouton « Créer », et une fenêtre de dialogue s’ouvrira. Ici, sélectionnez le type de ticket « Bug » :
Un bon rapport de bug doit contenir une bonne description (ou « Résumé » dans Jira). Elle doit être concise, mais donner assez d’informations pour bien cerner le problème.
Ensuite, dans la description, ajoutez tous les détails pertinents. Vous pouvez les structurer de manière classique :
- Étapes pour reproduire
- Résultat attendu
- Résultat obtenu
Ensuite, incluez tout autre détail utile à propos du défaut. Des captures d’écran ou des enregistrements sont toujours une bonne idée, tout comme les logs ou des fichiers précis utilisés pendant l’exécution.
Jira permet d’ajouter des champs personnalisés aux tickets. J’aime séparer la « Sévérité » de la « Priorité ». Ainsi, même si « Priorité » est un champ proposé par défaut dans Jira, vous pouvez en ajouter un personnalisé pour la « Sévérité ».
D’autres champs personnalisés intéressants à ajouter peuvent concerner le système d’exploitation : un champ texte ou une liste déroulante avec des valeurs pré-définies, telles que les versions Android et iOS utilisées pour tester, le navigateur, le numéro de build ou toute autre information utile pour le suivi des bugs.
Pour ajouter de nouveaux champs, vous pouvez accéder aux paramètres du projet, sélectionner le type « Bug » et choisir le type de champ dont vous avez besoin :
Cas de test dans Jira
Le dernier point dont je souhaite parler concerne les cas de test. Le logiciel Jira peut être intégré à différents outils de gestion des tests, ou vous pouvez ajouter des extensions et modules Atlassian, tels que Zephyr (qui était mon préféré) ou Xray. Lorsque vous créez un bug à la suite d’un échec de cas de test, le test peut être lié au bug, ce qui s’avère très utile pour la gestion des bugs, des tests et de l’exécution des cas de test.
Vous voulez aller plus loin ?
Jira peut être un excellent outil de suivi des défauts et améliorer le processus de développement grâce à ses multiples possibilités de personnalisation. Lorsqu’il s’agit de bugs, il est vraiment utile car vous pouvez adapter le workflow en fonction du cycle de vie que vous souhaitez pour votre projet. Vous pouvez lier les bugs aux cas de test et ajouter des champs personnalisés de la façon la plus pertinente selon les besoins spécifiques de votre projet.
Pour plus de guides pratiques comme celui-ci, abonnez-vous à la newsletter The QA Lead.
