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 garantit que les détails essentiels sont saisis de manière cohérente, ce qui facilite le suivi, la priorisation et la communication des bogues 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 pour la gestion de projets de développement (surtout dans les environnements agiles). Je l’ai utilisé sur de nombreux projets ces dernières années, avec Scrum comme avec Kanban, et je le trouve très polyvalent.
Dans cet article, je vais passer en revue la polyvalence de Jira pour le suivi des bogues, la personnalisation et la gestion des flux de travail, ainsi que l’amélioration du signalement 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 en charge de la configuration des workflows Jira ou que vous signaliez des défauts avec cet outil, cela ne fait jamais de mal de savoir comment il fonctionne. Jira est plus qu’un simple outil de signalement de bogues, mais dans cet article, nous allons nous concentrer avant tout sur le suivi des bogues plutôt que sur la gestion d’autres types de tickets.
Need expert help selecting the right tool?
Configuration d’un nouveau projet avec Jira Software
Si votre projet est nouveau, la première chose à faire est de configurer le projet Jira. Cette tâche revient généralement au scrum master ou au chef de projet, mais si votre rôle QA chevauche l’un de ces postes, elle pourrait vous incomber. Ce n’est pas compliqué, et de toute façon, c’est normalement à faire une seule fois !
L’inscription est gratuite et, pour les petits projets de moins de dix utilisateurs, vous pouvez utiliser le forfait gratuit. Si vous avez une équipe plus nombreuse ou besoin de fonctions avancées, optez pour l’un des abonnements payants. Je ne vais pas rentrer dans les détails, mais vous pouvez consulter la page des tarifs Jira si cela vous intéresse.
J’ai seulement créé de nouveaux projets pour animer un cours, mais le processus est assez intuitif. 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 standards : À faire, En cours et Terminé.
- Scrum – Ce modèle permet à l’équipe de gérer ses sprints et son backlog selon la méthode Scrum.
- Suivi des bogues – Un modèle simple qui permet le suivi des tickets sans utiliser de méthodologie agile.
Tous les projets peuvent être personnalisés pour inclure les étapes, transitions et statuts dont le projet a besoin.
Pour ce tutoriel, j’utiliserai le modèle de projet Scrum, afin que vous puissiez suivre les user stories et les bogues dans le même projet. Mais rassurez-vous : tout ce que je montre s’applique également aux autres types de projets !
Types de tickets
Les types de tickets proposés par défaut par Jira sont :
- Épopée (Epic) : En agile, une épopée est une collection de haut niveau de user stories et de tâches.
- Bogue : C’est le type de ticket utilisé dans Jira pour suivre les bogues et défauts trouvés. Nous nous concentrerons sur ceux-ci pour la suite de l’article.
- User story : Une user story agile (la description de la fonctionnalité à développer et tester).
- Tâche : Utilisé habituellement pour suivre une question ponctuelle ou une action à effectuer, comme par exemple rechercher un nouvel outil d'automatisation des 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 dépend de la "Tâche" mentionnée ci-dessus.
Comme je l’ai déjà évoqué, Jira est très flexible et, si besoin, vous pouvez créer vos propres types de tickets à tout moment dans le projet.
Par exemple, j’ai travaillé sur un projet où nous avions un type de ticket séparé pour les améliorations. Il s’agissait d’éléments similaires aux user stories, mais qui concernaient surtout l’amélioration de fonctionnalités existantes dans l’application.
Ou vous pouvez créer un type de ticket pour les cas de test, mais nous aborderons ce point un peu plus tard, lorsque nous examinerons les plugins disponibles et les outils d’intégration avec Jira.
Suivi des bugs avec Jira
Passons maintenant à ce qui nous intéresse en tant que testeurs : la déclaration 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, QA, l’utiliserons probablement beaucoup pour signaler des anomalies 😁.
Workflow et cycle de vie du bug
Le workflow de bug par défaut (ainsi que pour tous les tickets, en réalité) proposé 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 quel autre statut.
L’équipe de gestion des tests, le Scrum Master ou le chef de projet sont généralement chargés de concevoir les workflows personnalisés.
Le workflow reflète le cycle de vie du bug que vous souhaitez avoir sur le projet. Vous pouvez garder celui par défaut, simple, ou 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 accéder aux paramètres du projet, sélectionner le type de ticket « bug » et cliquer sur « Modifier le workflow ».
Ici, vous pouvez ajouter tout nouveau statut et choisir une transition spécifique si besoin. Voici un exemple :
Dans ce cas, lorsqu’un nouveau ticket est créé, il aura le statut 'À faire', à partir duquel il ne peut être déplacé que vers 'En cours'. Ensuite, avant que le bug puisse être testé, le code doit être relu. L’équipe QA peut le clôturer une fois validé, au statut « En QA ». Bien entendu, la revue de code et les processus 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 nécessaire pour passer du premier workflow au second (ou à tout workflow personnalisé 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 — ils sont répartis en trois catégories : 'À faire', 'En cours' et 'Terminé', chacune associée à une couleur spécifique. Vous pouvez choisir où votre statut s’insère le mieux. J’ai décidé que les statuts 'En relecture de code' 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 les cas où une nouvelle fonctionnalité est ouverte et que le product owner ou l’analyste métier doit encore ajouter des informations à son sujet, ou que l’équipe doit encore la détailler et décider de sa complexité ou de ses points d’effort.
3. Une fois que vous avez ajouté le nouveau statut, vous pouvez y ajouter une transition. Par défaut, celle-ci permet de passer à ce statut depuis n’importe quel autre. Si vous ne souhaitez pas de règles de transition spécifiques, c’est parfait. Cependant, un bon workflow permet de ne faire passer les bugs et tickets vers certains statuts qu’après avoir suivi certaines étapes du processus.
Dans mon exemple ci-dessus, l’équipe QA ne peut pas commencer à vérifier le correctif qu’une fois qu’un autre développeur a relu le code. Pour ajouter cette transition, cliquez sur le bouton 'Transition' et saisissez les détails :
4. Vous pouvez également supprimer les transitions et statuts existants si vous souhaitez tout personnaliser à 100 %.
5. Une fonctionnalité très pratique est celle des attributions automatiques. Cela se fait également depuis le workflow, où vous pouvez définir un utilisateur assigné par défaut lors de la réalisation d’une certaine transition sur le ticket.
Par exemple, après qu’un bug a été « revu » et déplacé vers « En QA », il est automatiquement attribué à un 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 nouveaux problèmes créés peuvent être automatiquement attribués à un chef de projet ou à un Product Owner, qui les priorisera dans le backlog. C’est hautement personnalisable, ce qui vous permet de l’adapter selon le mode de fonctionnement de votre équipe.
Même si vous n’êtes pas chargé de configurer le cycle de vie des tickets, ou si vous n’avez pas accès aux paramètres du projet, vous pouvez visualiser le workflow de chaque ticket Jira en déroulant la liste des statuts :
Afficher les tickets dans Jira
Si le projet n’est pas un projet de suivi de bugs, vous pouvez visualiser les tickets actuels sur les tableaux Kanban ou Scrum :
Ceci est seulement à titre illustratif ; je doute que vous ayez souvent la chance de faire un sprint avec une seule User Story et un seul bug 😅.
En cliquant sur n’importe quel ticket, vous affichez ses détails. Ceux-ci comprennent, entre autres, un identifiant généré automatiquement par Jira, un titre, une description, le déclarant, l’attributaire, et tous les fichiers joints ou commentaires ajoutés par les membres de l’équipe.
Les champs sont aussi personnalisables, et je le montrerai lorsque nous parlerons de ce qu’il faut inclure dans un bon rapport de bug.
Attributaires
Tous les tickets Jira peuvent être attribués à un membre spécifique de l’équipe. Vous pouvez mentionner des personnes dans les commentaires ou la description en utilisant le caractère @ avant le nom de l’utilisateur.
Vous recevrez des notifications si quelqu’un vous mentionne ou lorsqu’un ticket qui vous est attribué ou que vous avez déclaré est mis à jour. Vous pouvez également « surveiller » des tickets. Vous serez notifié de toute modification des tickets surveillés, quelle que soit la personne qui les déclare ou à qui ils sont attribués.
Déclarer un bug dans Jira
Une application avec peu de bugs, c’est ce que tout le monde recherche, mais soyons honnêtes : nous, les testeurs, nous sommes toujours contents lorsqu’on déniche un vrai bug.
Mais un bon bug n’est aussi utile que s’il est bien signalé : un rapport de bug bien fait assurera qu’il sera corrigé avec un minimum d’allers-retours entre l’équipe de test et l’équipe de développement. Jira est un excellent outil de suivi de bugs. Je l’ai déjà dit ? Il permet beaucoup de flexibilité.
Pour créer un nouveau ticket, cliquez sur le gros bouton « Créer ». Une boîte de dialogue s’ouvre. Sélectionnez ici le type de ticket « Bug » :
Un bon rapport de bug doit inclure une bonne description (ou « Résumé » dans Jira). Elle doit être concise mais assez détaillée pour qu’on comprenne bien de quoi il s’agit.
Puis, dans la description, ajoutez tous les détails pertinents. Vous pouvez les structurer d’une manière classique :
- Étapes pour reproduire
- Résultat attendu
- Résultat réel
Puis, ajoutez toute autre information pertinente pour le défaut. Captures d’écran ou vidéos sont toujours utiles, tout comme les journaux ou fichiers spécifiques utilisés lors des tests.
Jira permet d’ajouter des champs personnalisés aux tickets. J’aime bien séparer la « Sévérité » de la « Priorité ». Ainsi, même si « Priorité » est un champ standard de Jira, vous pouvez ajouter votre propre champ pour la « Sévérité ».
D’autres champs personnalisés peuvent porter sur le système d’exploitation : un champ texte ou une liste déroulante avec valeurs prédéfinies, comme les versions Android et iOS utilisées lors des tests, le navigateur, le numéro de build, ou toute information utile pour le suivi des bugs.
Pour ajouter de nouveaux champs, allez dans les paramètres du projet, sélectionnez le type « Bug » et choisissez le type de champ dont vous avez besoin :
Cas de test dans Jira
Le dernier point que je souhaite aborder concerne les cas de test. Le logiciel Jira peut être intégré à divers outils de gestion des tests, ou vous pouvez ajouter des extensions et des modules complémentaires Atlassian, comme Zephyr (qui était mon préféré) ou Xray. Lorsque vous créez un bug à la suite de l'échec d'un cas de test, ce test peut être lié au bug, ce qui peut s’avérer très utile pour gérer les bugs, les tests, et l’exécution des cas de test.
Vous en voulez plus ?
Jira peut être un excellent outil de suivi des défauts et peut améliorer le processus de développement car il permet une grande personnalisation. Pour ce qui est des bugs, il est vraiment utile car vous pouvez personnaliser le workflow en fonction du cycle de vie que vous souhaitez dans votre projet. Vous pouvez lier les bugs aux cas de test et ajouter des champs personnalisés de la manière la plus adaptée à votre projet spécifique.
Pour plus de guides pratiques comme celui-ci, abonnez-vous à la newsletter The QA Lead.
Need expert help selecting the right Testing Software?
We’ve joined up with Crozdesk.com to give all our readers (yes, you!) access to Crozdesk’s software advisors. Just use the form below to share your needs, and they will contact you at no cost or commitment. You will then be matched and connected to a shortlist of vendors that best fit your company, and you can access exclusive software discounts!
