Comment rédiger un rapport de bug (+ modèle gratuit à télécharger)
Savoir comment créer un rapport de bug efficace est une grande partie du travail d’un testeur logiciel pour assurer la qualité, et nous passons donc beaucoup de temps à consigner des bugs dans nos outils de suivi des bugs. Découvrir un bug peut être excitant, surtout s'il s'agit d'un scénario intéressant. Mais la façon dont nous le signalons peut être aussi importante que son impact sur le système.
Un rapport de bug mal rédigé peut provoquer beaucoup de tensions entre les membres de l'équipe, notamment entre les testeurs et les développeurs, ce qui peut créer des obstacles à la correction des bugs et, au final, nuire à l'expérience utilisateur.
Dans cet article, je vais partager les éléments essentiels, comme :
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
- Maîtriser les rapports de bug : Apprenez les éléments clés qu’un rapport de bug efficace doit inclure pour faciliter la communication et accélérer les corrections.
- Favoriser l’harmonie dans l’équipe : Découvrez comment des rapports de bug bien rédigés évitent les frictions entre testeurs et développeurs, conduisant à des processus plus fluides.
- Modèle téléchargeable gratuit : Obtenez un modèle gratuit de suivi des bugs à télécharger pour démarrer efficacement votre processus de signalement.
Éléments clés d’un rapport de bug
Quel que soit le type d’application que vous testez, qu’il s’agisse d’un logiciel de bureau, d’une application web, mobile ou d’un projet d’API, il existe des éléments essentiels que chaque bon rapport de bug doit comporter. La plupart des logiciels de suivi des bugs proposent des champs pour ces éléments, notamment :
- ID : Si vous utilisez un outil de gestion de projet, comme Jira, un identifiant sera automatiquement attribué à chaque nouvel incident ouvert. Il existe également des outils de gestion de tests pour Jira pour le suivi des bugs.
- Titre/Description : Il s’agit d’une courte description du problème. Elle doit être suffisamment concise pour être facile à lire, mais assez descriptive pour que les autres comprennent où réside le problème. Par exemple, « le tri des articles par prix ne fonctionne pas lorsqu’un filtre est appliqué. »
- Étapes pour reproduire : Indiquez ici autant de détails pertinents que possible. Assurez-vous que toute personne souhaitant reproduire le problème ou vérifier la correction puisse le faire simplement en suivant les étapes. Ne sautez aucune étape en partant du principe que tout le monde saura implicitement quoi faire, même si ce n’est pas mentionné ; incluez-les dans le rapport de bug.
- Résultats attendus : Là encore, n’assumez pas que les utilisateurs connaissent déjà le fonctionnement attendu de l’application. Bien sûr, si vous obtenez une exception dans l’interface lorsque vous appuyez sur un bouton, vous savez que ce n’est pas normal. Cependant, je ne dirais pas que le résultat attendu est « aucune exception n’est levée », mais plutôt l’action que le bouton doit effectuer, c’est-à-dire « la boîte de dialogue des paramètres s’ouvre ».
- Résultats réels : C’est explicite : vous devez décrire ce qui se passe réellement dans l’application une fois toutes les étapes de reproduction réalisées.
- Gravité : Cela représente l’impact du bug sur le produit testé (AUT).
- Priorité : À quelle vitesse le bug doit-il être corrigé. Une priorité plus élevée signifie que le bug doit être placé en haut du backlog et corrigé plus rapidement.
Autres informations importantes à inclure
En plus des éléments mentionnés ci-dessus, d’autres informations peuvent être utiles, notamment lors de la saisie des données dans un outil de reporting des bugs. Elles peuvent dépendre du type de projet, des exigences du projet ou même du bug lui-même :
- Version du logiciel : Le numéro de version sur lequel le bug a été identifié. Cela peut aider à isoler la version dans laquelle le problème a potentiellement été introduit et à identifier le code en cause.
- Pièces jointes : Elles ne sont pas toujours nécessaires ni disponibles, mais elles apportent généralement beaucoup de valeur. Pensez à fournir des captures d’écran ou des enregistrements du problème rencontré, des fichiers logs, des traces de pile, des requêtes et réponses réseau, etc.
- Données de test : Parfois, les bugs que nous trouvons ne se produisent qu’avec certains jeux de données. Si c’est le cas, veillez à les inclure, que ce soit parmi les étapes de reproduction (par exemple, « se connecter avec l’utilisateur andreea@theqalead.com ») ou dans un champ spécifique de l’outil de suivi des bugs.
- Détails de l’environnement : Si le bug se produit uniquement sur un système d’exploitation, un navigateur ou un environnement de développement spécifique, mentionnez-le.
Conseils pour rédiger un bon rapport de bug
- Limitez-vous à un seul bug par signalement. Si vous découvrez d'autres bugs dans les mêmes zones, vous pouvez les lier dans votre système de suivi des incidents. Inclure plus d'un défaut peut entraîner de la confusion et retarder la correction potentielle des bugs.
- Vérifiez dans votre système de suivi que le bug n’a pas déjà été signalé. S’il est déjà ouvert, ajoutez les détails pertinents que vous avez découverts et qui n’apparaissaient pas dans le rapport initial.
- Essayez de reproduire le bug plusieurs fois. Vous pouvez tenter de trouver le moyen le plus court de le reproduire (en utilisant le moins d'étapes possible).
- Ne vous perdez pas dans les détails inutiles. Le rapport de bug et les étapes doivent être simples à lire et à suivre.
- N’émettez pas d’hypothèses sur la cause du bug (sauf si vous êtes certain à 100% de la cause).
Modèle de Rapport de Bug
Je souhaite maintenant partager avec vous quelques modèles pour les rapports de bugs. Vous pouvez les copier ou les adapter selon les besoins de votre projet.
Modèle de Suivi des Bugs avec Jira
Jira est un outil de suivi des incidents très répandu développé par Atlassian. Si votre équipe l’utilise, le type d’incident « bug » est probablement déjà configuré. En tant que testeur ou responsable d’équipe de développement logiciel, vous pouvez mettre en place un workflow de suivi des bugs pour le cycle de vie des anomalies (cette fonctionnalité fait partie des nombreuses avantages des logiciels de suivi des incidents).
Vous pouvez également ajouter des champs personnalisés dans Jira, par exemple pour l’environnement ou un champ spécifique où indiquer la fonctionnalité testée. Ou vous pouvez ajouter une description par défaut contenant toutes les informations que vous souhaitez inclure dans chaque rapport de bug. Voici un exemple que j’ai créé :
Ainsi, lorsque je souhaite créer un nouveau bug, ces informations seront préremplies. Voici mon modèle de bug dans Jira, utilisant des champs personnalisés et une description par défaut :
Il contient les informations essentielles que le bug doit inclure :
- Un titre (« Exemple de bug »)
- Dans la description : les préconditions, les étapes de reproduction et les résultats attendus vs réels
- Un champ personnalisé pour l’environnement
- Une sévérité et une priorité, sélectionnées dans des menus déroulants prédéfinis
- J’ai laissé l’attributaire vide. Selon les conventions de votre projet, les nouveaux bugs peuvent être attribués automatiquement à un membre spécifique de l’équipe, ou la personne qui commence à les traiter peut se l’attribuer.
- Une étiquette—cela peut être utile si vous souhaitez suivre quelle fonctionnalité est impactée, par exemple
- Une date d’échéance—elle peut rester vide tant que le backlog n’a pas été priorisé
- Le rapporteur (dans ce cas auto-rempli avec l’utilisateur Jira qui a créé le bug)
En option, Jira propose de nombreuses intégrations et le bug peut être lié à des cas de test, des branches Git ou même des pull requests.
Vous pouvez également utiliser leur modèle de suivi des bugs comme modèle de projet si vous n'utilisez Jira que pour le suivi des anomalies et que vous ne travaillez pas en mode agile.
Modèle de Suivi des Bugs sur Excel
Certaines équipes peuvent utiliser des feuilles de calcul pour leur système de suivi des bugs. Je les trouve utiles pour de tout petits projets où la mise en place d’un outil dédié ne se justifie pas, ou pour le signalement de bugs sur de nouvelles fonctionnalités encore en développement.
Vous pouvez utiliser Google Sheets/Docs, ou Microsoft Excel/Word – dans tous les cas, un modèle de rapport de bug peut ressembler à ceci :
Les colonnes reflètent les informations que le rapport doit contenir :
- L’ID (Excel saura automatiquement augmenter la valeur à chaque fois qu’une nouvelle ligne est ajoutée)
- Un titre
- Les étapes pour reproduire
- Résultats attendus et réels
- Le nom du rapporteur
- La sévérité et la priorité du bug—ici, j’ai utilisé des menus déroulants parce que les valeurs doivent être prédéfinies
- Environnement
- Informations supplémentaires : Ceci concerne tout ce qui mérite d’être mentionné mais qui ne rentre pas dans les autres colonnes
Conclusion
Rédiger un bon rapport de bug logiciel est une compétence essentielle pour les testeurs, alors prêtez une attention particulière aux bonnes pratiques expliquées plus haut. Vous pouvez également vous appuyer sur les exemples de modèles de suivi des bugs que j’ai fournis. Ils peuvent être adaptés à différents outils que vous utilisez, tels que Trello ou Asana.
Si ce contenu vous a plu, abonnez-vous à la newsletter The QA Lead pour rester informé des actualités et des tendances autour des processus de test logiciel !
