Reportez les anomalies aux développeurs avec Jira
Lorsque vous identifiez une anomalie pendant une campagne de test, votre travail ne s'arrête pas à sa détection. Vous devez la documenter suffisamment précisément pour permettre à l'équipe de développement de la reproduire, de l'analyser et de la corriger.
Pour cela, les équipes de développement utilisent fréquemment des outils de suivi comme Jira. Dans ce chapitre, vous allez découvrir comment créer votre environnement Jira, déclarer une anomalie, la qualifier puis suivre son traitement.
Découvrez Jira
Jira est un logiciel de gestion du travail développé par Atlassian et largement utilisé par les équipes qui développent des logiciels. Il permet notamment de planifier le travail, de créer des tickets et de suivre leur progression.
En tant que testeur, vous pouvez l'utiliser pour créer, documenter, suivre et gérer les anomalies rencontrées pendant vos tests. C'est déjà l'usage présenté dans la version initiale de ce chapitre.
Imaginez par exemple que vous testiez un formulaire d'inscription. Vous renseignez correctement tous les champs, mais le bouton de validation ne fonctionne pas.
Vous pourriez simplement prévenir un développeur :
Le formulaire d'inscription ne marche pas.
Mais cette information ne lui permet pas forcément de reproduire le problème. Sur quelle page ? Avec quelles données ? Sur quel navigateur ? Quel comportement avez-vous observé ?
Un ticket Jira permet justement de centraliser ces informations et de conserver une trace de l'anomalie jusqu'à sa résolution.
Créez votre environnement
Suivez les étapes avec moi : vous aurez besoin de Jira pour la suite du cours.
Commencez par vous rendre sur le site d'Atlassian et créez un compte permettant d'utiliser Jira Cloud, si vous n'en possédez pas déjà un.
Une fois connecté à Jira, créez l'espace dans lequel vous allez suivre vos anomalies :
1- Accédez à la section Espaces (Spaces) ;
2- Sélectionnez l'option permettant de créer un espace (ou cliquez sur le "+" à droite) ;
3- Parcourez les modèles proposés ;
4 - Sélectionnez la catégorie "Développement logiciel" puis, dans les modèles proposés choisissez "Suivi de bug" et enfin validez en cliquant sur "Utilisez un modèle" ;
5- Donnez un nom explicite à votre espace, par exempleProjet de test logiciel;
6 - Si Jira vous demande de choisir un mode de gestion de l'espace, conservez l'option proposée pour cet exercice ;
7- Validez la création (ignorez l’étape d’ajout de membre)
Votre environnement est prêt !
Prenez quelques minutes pour parcourir l'interface.
Repérez notamment :
la navigation, qui permet d'accéder aux différentes vues ;
le tableau (board), qui permet de visualiser les tickets ;
le bouton Créer (+), qui permet d'ajouter un nouveau ticket.
Créez votre premier ticket
Il est maintenant temps de déclarer votre première anomalie !
Dans Jira, chaque élément de travail est enregistré sous la forme d'un ticket — vous pourrez également rencontrer le terme anglais work item dans les versions récentes de Jira.
Selon la configuration de l'espace, différents types de tickets peuvent être proposés. Vous pourrez notamment rencontrer :
des tâches, correspondant à un travail à réaliser ;
des bugs, correspondant aux anomalies détectées ;
des éléments représentant des fonctionnalités ou des ensembles de travaux plus importants.
Dans ce chapitre, nous allons nous concentrer sur le type Bug, puisque notre objectif est de reporter les anomalies découvertes pendant les tests. La version précédente du chapitre distinguait déjà les bugs des tâches et des fonctionnalités.
Déclarez votre anomalie
Pour créer votre premier bug :
Cliquez sur Créer (+) ;
Vérifiez que le bon espace est sélectionné ;
Choisissez Bug comme type de ticket ;
Renseignez un titre dans le champ Résumé ou Titre, selon votre interface ;
Décrivez précisément l'anomalie ;
Ajoutez les autres informations pertinentes proposées par votre environnement ;
Créez le ticket.
Le titre doit permettre de comprendre rapidement le problème. Évitez donc un résumé trop vague comme :
Problème formulaire
Préférez une formulation décrivant le comportement observé :
Impossible de valider le formulaire d'inscription avec une adresse e-mail valide
Documentez précisément votre anomalie
La Description est l'une des parties les plus importantes du ticket.
Un développeur qui n'a pas effectué votre test doit pouvoir comprendre le problème et, si possible, le reproduire.
Vous pouvez notamment préciser :
Contexte : Indiquez où et dans quelles conditions le problème apparaît.
Préconditions : Précisez les conditions qui doivent être réunies avant de commencer le test.
Étapes de reproduction
Ouvrir la page d'inscription.
Renseigner une adresse e-mail valide.
Compléter les champs obligatoires.
Cliquer sur « Créer mon compte ».
Résultat obtenu : Un message d'erreur apparaît et le compte n'est pas créé.
Résultat attendu : Le compte doit être créé et l'utilisateur doit accéder à l'étape suivante.
Ajoutez également, lorsque cela est pertinent, l'environnement utilisé : navigateur, système d'exploitation, version de l'application, appareil, etc.
Enfin, joignez les preuves utiles à la compréhension du problème : capture d'écran, vidéo courte, message d'erreur ou autre élément pertinent.
Qualifiez votre anomalie
Toutes les anomalies n'ont pas le même impact.
Une faute d'affichage sur une page secondaire et l'impossibilité de finaliser un paiement ne doivent évidemment pas être considérées de la même manière.
Vous devez donc apprendre à qualifier l'importance d'une anomalie.
Distinguez criticité et priorité
Deux notions proches peuvent être utilisées par les équipes : criticité et priorité.
La criticité représente l'importance ou l'impact de l'anomalie sur le produit et ses utilisateurs.
Vous pouvez par exemple rencontrer cette classification :
Mineure : le problème est peu gênant et peut facilement être contourné.
Majeure : le problème détériore significativement l'utilisation de l'application sans la bloquer complètement.
Critique : le problème bloque l'application ou une fonctionnalité essentielle.
Ces trois niveaux correspondent à la classification introduite dans la version initiale du chapitre.
La priorité, elle, indique dans quel ordre les tickets doivent être traités. La distinction était déjà posée dans le chapitre initial : criticité = importance de l'anomalie ; priorité = ordre de traitement.
Les deux notions sont liées, mais elles ne sont pas synonymes.
Imaginez par exemple une anomalie critique touchant une fonctionnalité qui n'est pas encore disponible pour les utilisateurs. Elle peut être très grave techniquement sans nécessiter exactement le même niveau d'urgence qu'un problème bloquant actuellement tous les clients en production.
Pour pouvoir modifier ce champ et également le retrouver dans le formulaire de création de nouveau ticket vous devez l’ajouter
1- Ouvrez votre premier ticket
2- Cliquez sur l’engrenage à droite, puis “Gérer les champs”
3- Dans les champs disponibles à droite, cliquez sur “Priorité”
4- Validez avec le bouton en bas “Enregistrez les modifications”
5- Revenez à votre espace et maintenant lors de l’édition d’un ticket ou de sa création vous avez la possibilité de définir la priorité
Utilisez les champs disponibles dans votre environnement
Jira étant configurable, votre environnement peut comporter un champ Priorité, un champ spécifique consacré à la criticité, ou les deux. C'était d'ailleurs déjà signalé dans la version initiale du cours.
Dans l'environnement utilisé pour cet exercice, renseignez le champ disponible pour traduire le niveau de traitement attendu.
Ne cherchez donc pas nécessairement une liste précise de valeurs : la nomenclature peut varier selon la
À vous de jouer
Maintenant que votre environnement Jira est prêt et que vous savez créer un bug, saisissez les anomalies découvertes lors des précédents « À vous de jouer ».
Pour chaque anomalie :
créez un ticket de type Bug ;
rédigez un titre court et explicite ;
décrivez le contexte ;
indiquez les étapes permettant de reproduire le problème ;
précisez le résultat obtenu et le résultat attendu ;
ajoutez les éléments de preuve utiles ;
renseignez la priorité ou la criticité selon les champs disponibles.
Vous avez terminé ?
Avant de considérer votre ticket comme terminé, posez-vous cette question :
Un développeur qui n'a pas effectué mon test dispose-t-il de suffisamment d'informations pour reproduire l'anomalie ?
Si la réponse est oui, votre ticket est prêt à être partagé avec l'équipe.
Suivez la vie des tickets avec Jira
Créer un ticket n'est que le début de son cycle de vie.
Une fois l'anomalie transmise, elle peut être analysée par l'équipe, prise en charge par un développeur, corrigée puis vérifiée.
Les tableaux et les workflows de Jira permettent de suivre cette évolution. Ils constituent deux fonctionnalités centrales pour visualiser l'avancement des problèmes.
Utilisez votre tableau
Un tableau, ou board, offre une représentation visuelle des tickets et de leur état d'avancement.
Vous pouvez par exemple avoir trois colonnes :
À faire → En cours → Terminé
Un ticket nouvellement créé apparaît dans la première colonne. Lorsqu'un développeur commence à travailler sur l'anomalie, il passe dans En cours. Une fois son traitement terminé, il peut rejoindre la dernière colonne.
Les noms et le nombre de colonnes dépendent de l'organisation de l'équipe.
Pour suivre vos tickets :
accédez au tableau de votre espace ;
repérez l'anomalie qui vous intéresse ;
consultez son état actuel ;
lorsque votre configuration vous le permet, déplacez le ticket vers la colonne correspondant à son nouvel état.
Vous pouvez également utiliser les filtres disponibles pour vous concentrer sur certains tickets : par exemple ceux qui vous sont attribués ou ceux correspondant à une priorité particulière.
L'objectif du tableau est de vous donner une vue d'ensemble du travail en cours. Dans la version initiale, le board servait déjà à suivre l'avancement, attribuer les problèmes et identifier ceux nécessitant une attention particulière.
Comprenez le fonctionnement d'un workflow
Mais comment Jira sait-il quels états peut prendre un ticket ?
C'est le rôle du workflow.
Prenons un exemple légèrement plus proche du travail d'une équipe de test :
Bug signalé → À faire → En cours → À vérifier → Terminé
Lorsqu'un développeur termine sa correction, le ticket peut ainsi passer à l'état À vérifier.
Le testeur vérifie alors que l'anomalie a effectivement disparu.
Deux situations sont possibles :
la correction fonctionne : le ticket peut poursuivre son parcours vers Terminé ;
l'anomalie est toujours présente : le ticket peut retourner vers En cours, accompagné des nouvelles informations utiles.
Ce fonctionnement évite de considérer une anomalie comme définitivement corrigée uniquement parce qu'une modification du code a été effectuée.
Adaptez le workflow aux besoins de l'équipe
Les workflows Jira peuvent être personnalisés. Certaines équipes utilisent seulement quelques états ; d'autres ont besoin d'un processus plus détaillé.
Vous pourriez par exemple rencontrer :
À faire → En cours → Revue → À tester → Terminé
ou simplement :
À faire → En cours → Terminé
Le workflow doit avant tout refléter la manière dont l'équipe organise réellement son travail.
En tant que testeur, vous n'avez pas nécessairement à configurer vous-même les workflows. Vous devez surtout comprendre leur fonctionnement afin de suivre correctement le cycle de vie des anomalies et intervenir au bon moment.
En résumé
Vous savez créer un environnement Jira consacré au suivi de vos anomalies.
Vous savez créer et documenter un ticket de bug afin qu'un développeur puisse reproduire le problème.
Vous savez distinguer la criticité d'une anomalie de sa priorité de traitement.
Vous savez utiliser un tableau Jira pour suivre l'avancement des tickets.
Vous comprenez comment un workflow organise le cycle de vie d'une anomalie, de sa détection à la vérification de sa correction.
Vous savez désormais non seulement détecter une anomalie, mais aussi la transmettre aux développeurs de manière exploitable et suivre sa résolution. Dans le quiz qui suit, vous allez vérifier que vous maîtrisez ces bonnes pratiques avant de passer à la campagne de test.
