À propos de cet outil
Toutes les équipes n’utilisent pas Jira. Ce générateur produit un rapport de bug indépendant de l’outil de suivi, pour les issues GitHub, Azure DevOps, Linear, Confluence ou un simple e-mail, et il consigne deux éléments qui déterminent le traitement d’un bug : la fiabilité de sa reproduction et s’il s’agit d’une régression. « Intermittent, 3 tentatives sur 10 » indique au développeur de chercher un problème de timing ou d’état ; « Régression, dernier build correct 2.30.4 » lui permet de comparer deux builds au lieu de déboguer de zéro. Le format GitHub retire le titre du corps (il a son propre champ), transforme les lignes d’environnement « Key: value » en tableau et liste les pièces jointes sous forme de checklist pour que vous pensiez à glisser les fichiers.
Mode d’emploi
- Saisissez un titre précis et une description d’une ligne indiquant qui est affecté.
- Listez les étapes, les résultats attendu et obtenu, et l’environnement sous forme de lignes « Key: value ».
- Indiquez la reproductibilité (toujours, intermittente avec un compte, ou vue une fois) et si cela fonctionnait dans un build précédent.
- Choisissez Markdown, issue GitHub ou texte brut, puis copiez ou téléchargez. Le travail en cours est enregistré dans ce navigateur.
FAQ : Générateur de rapports de bug
Comment signaler un bug que je ne reproduis que parfois ?
Choisissez « Intermittent » et notez combien de fois il s’est produit sur combien de tentatives. Ajoutez dans la description tout ce qui semblait corrélé (première exécution après connexion, réseau lent, un compte particulier). Un ratio est bien plus utile que « parfois ».
Pourquoi demander le dernier build correct ?
Si vous savez que le bug est une régression et connaissez le dernier build où cela fonctionnait, les développeurs peuvent comparer les deux builds ou faire une bissection des commits entre les deux. C’est généralement bien plus rapide que de déboguer le build actuel seul.
Puis-je joindre des captures d’écran ici ?
Non. Les fichiers restent dans votre outil de suivi. Listez les noms de fichiers dans « Attachments » pour que les relecteurs sachent quelles preuves existent, puis importez-les dans GitHub, Jira ou là où va le rapport.