Modèle et générateur de rapport de bug
Un formulaire structuré pour les champs dont un développeur a besoin, une vérification qualité sur les quatre choses qui font rejeter les bugs, et l'export en Markdown, wiki markup Jira ou texte brut.
Dix champs en entrée, un rapport formaté en sortie — avec renumérotation automatique des étapes et une vérification qualité avant de le déposer.
Ouvrir l'outil — gratuit, sans inscriptionCe que fait cet outil
Vous remplissez dix champs : titre, sévérité, priorité, reproductibilité, environnement, build, étapes de reproduction, résultat attendu, résultat réel, et infos supplémentaires. Il les formate en un rapport, lance quatre vérifications qualité, et exporte en Markdown, wiki markup Jira ou texte brut. Le champ des étapes prend une étape par ligne et renumérote automatiquement, en retirant toute numérotation que vous avez tapée — donc coller depuis une note brouillon ne produit pas « 1. 1. Se connecter ».
Ce que contient un bon rapport de bug
Un titre qui se suffit à lui-même. Un développeur qui parcourt un backlog devrait comprendre le bug depuis le titre sans l'ouvrir. « Le checkout renvoie une erreur 500 quand le panier contient plus de 10 articles » énonce ce qui a cassé, où, et dans quelle condition. « Bug de checkout » n'énonce rien. Le vérificateur signale les titres de moins de 15 caractères.
Des étapes qui partent d'un état connu. Commencez à la connexion ou à une URL précise, pas de là où vous vous trouviez. Chaque étape est une action. Si une étape a besoin de données particulières — un utilisateur précis, un panier précis — dites-le dans l'étape. Les développeurs ferment les bugs qu'ils ne peuvent pas reproduire, et c'est la raison la plus courante pour laquelle un vrai défaut est rejeté.
Attendu et réel, tous deux énoncés. L'écart entre eux est le bug. Avec seulement le résultat réel, vous avez décrit un événement, pas un défaut, et laissé le développeur deviner quel était le comportement correct. C'est là que se règlent les désaccords sur le fait que quelque chose soit un bug ou non.
Environnement. Navigateur, OS, appareil et build. C'est la première chose qu'un développeur demande, et un bug qui ne se reproduit que sur l'un d'eux est un bug différent d'un qui se reproduit partout.
Une sévérité qui correspond à la description. L'outil montre la définition de ce que vous avez sélectionné : critique veut dire inutilisable, perte de données ou faille de sécurité sans contournement ; haute veut dire une fonctionnalité majeure cassée avec un contournement pénible ; moyenne veut dire partiellement cassé avec un contournement raisonnable ; basse veut dire cosmétique. Une sévérité mal ajustée est le moyen le plus rapide de perdre la confiance d'un développeur — quand tout est déposé en critique, rien ne l'est.
Erreurs courantes
Fusionner plusieurs bugs dans un seul ticket. Un défaut par rapport. Les bugs groupés sont partiellement corrigés et fermés.
De l'interprétation à la place de l'observation. « L'API est cassée » est une théorie. « POST /orders renvoie 500 avec ce corps » est une observation. Rapportez ce que vous avez vu ; mettez la théorie dans les infos supplémentaires.
Des étapes qui supposent votre contexte. Feature flags, état du compte, données seedées et réglages de locale sont invisibles au lecteur sauf s'ils sont énoncés.
ID de requête ou horodatage manquant. Pour tout ce qui est côté serveur, c'est ce qui permet à un développeur de trouver votre échec exact dans les logs. Ça transforme souvent une enquête de deux jours en dix minutes.
Tout est généré dans votre navigateur ; rien de ce que vous tapez n'est envoyé où que ce soit.
Questions fréquentes
Comment écrire un bon rapport de bug ?
Donnez-lui un titre qui décrit ce qui a cassé, où et dans quelle condition. Ajoutez des étapes numérotées depuis un état de départ connu, à la fois le résultat attendu et le résultat réel, l'environnement et le build, et tout log ou ID de requête. La sévérité devrait correspondre à l'impact que vous avez décrit.
Quelle est la différence entre sévérité et priorité ?
La sévérité est à quel point le défaut casse le produit ; la priorité est dans combien de temps il devrait être corrigé. Elles sont fixées par des préoccupations différentes — la sévérité par l'impact technique, la priorité par le besoin métier — donc une faute de frappe de faible sévérité sur une page de tarifs peut légitimement être prioritaire.
Puis-je exporter le rapport vers Jira ?
Oui. L'option Jira produit du wiki markup — titres, champs en gras, et étapes numérotées — qui se colle directement dans un champ de description Jira. Markdown et texte brut sont aussi disponibles, avec des boutons copier et télécharger.
Pourquoi les développeurs rejettent-ils des bugs valides ?
Le plus souvent parce qu'ils ne peuvent pas les reproduire. Des étapes manquantes, un état de départ non énoncé, pas d'environnement, ou des données qui n'existent que dans votre session sont les causes habituelles. Un bug intermittent devrait aussi être étiqueté comme tel, pas présenté comme survenant toujours.