Le modèle de rapport de bug qu'aucun relecteur ne rejette

Qu'est-ce qu'un modèle de rapport de bug ?

Un modèle de rapport de bug nomme chaque champ dont un ticket a besoin avant qu'un ingénieur puisse agir dessus, du titre jusqu'à la ligne d'environnement, si bien que rien n'a besoin d'être réclamé après le dépôt du ticket. Chaque champ répond à une question qu'un relecteur devrait sinon poser dans un fil de commentaires. Remplis chaque champ avant de soumettre, et traite un champ vide comme une raison pour laquelle le ticket revient.

Pourquoi le champ de titre existe-t-il et qu'est-ce qui rend un titre utile ?

Le champ de titre existe pour qu'un relecteur puisse dire ce qui est cassé sans ouvrir le ticket, ce qui décide s'il est repris lors du prochain passage de triage ou enterré sous cinquante autres. Un titre utile nomme l'action et l'échec ensemble, comme "Appliquer une carte cadeau au checkout affiche une page vide au lieu d'une erreur", pas une humeur comme "le checkout est cassé". Écris le titre en dernier, après que les étapes et le résultat réel sont clairs, pour qu'il nomme le véritable échec plutôt qu'une supposition.

Pourquoi le champ des étapes de reproduction existe-t-il ?

Le champ des étapes de reproduction existe pour qu'une deuxième personne puisse déclencher le même échec sans rien demander d'autre à la personne qui a signalé le bug, transformant une observation isolée en cas de test reproductible. Des actions numérotées depuis un point de départ énoncé sont ce qui sépare un rapport avec lequel un ingénieur peut travailler d'un rapport qui nécessite une réunion de suivi. Étapes de reproduction détaille à quoi ressemble un ensemble complet d'étapes et pourquoi une précondition manquante est la raison la plus courante de leur échec.

Pourquoi la gravité a-t-elle besoin de son propre champ, séparé de la priorité ?

La gravité a besoin de son propre champ parce qu'elle mesure les dégâts techniques, tandis que la priorité mesure à quelle vitesse quelqu'un doit corriger le bug, et les deux réponses correspondent rarement. Un bug de paiement qui touche un seul compte un week-end est grave mais pas urgent ce soir ; une coquille sur la page d'accueil est mineure mais urgente avant un lancement. Gravité vs. priorité détaille comment une personne en triage note chacune sans qu'un chiffre ne déteigne sur l'autre.

Que doit contenir le champ d'environnement ?

Le champ d'environnement nomme le navigateur et sa version, le système d'exploitation, la taille d'écran et si l'échec s'est produit en production, en staging ou sur un build local, parce que la même séquence de clics peut se comporter différemment selon chacun de ces cas. Un relecteur sans ce champ ne peut pas dire si un bug est universel ou lié à une seule configuration, ce qui signifie qu'il ne peut même pas estimer combien d'utilisateurs il touche. Copie la chaîne de version exacte depuis la page about du navigateur plutôt qu'une supposition comme "dernier Chrome".

Que doivent contenir les champs de résultat attendu et de résultat réel ?

Le champ de résultat attendu indique ce que l'interface était censée afficher, et le champ de résultat réel indique exactement ce qui est apparu à la place, chacun sous forme d'une ligne concrète, pas d'un paragraphe partagé sur le ressenti du bug. "On attendait le message 'Code invalide', une page blanche vide sans sortie console est apparue" donne à un ingénieur quelque chose à comparer ; "le checkout ne fonctionne pas" non. Écris les deux lignes avant d'écrire le titre, puisque l'écart entre elles est ce que le titre doit nommer.

Qu'est-ce qui pousse un relecteur à rejeter une soumission d'emblée ?

Un relecteur rejette une soumission d'emblée quand l'un des huit champs ci-dessus est vide, vague ou répond à la mauvaise question, car la personne qui fait le triage ne peut pas noter la gravité et la priorité d'un rapport qu'elle n'arrive pas à visualiser. La cause la plus fréquente est une précondition manquante : les étapes semblent complètes, mais personne n'indique l'état du compte ou les données existantes que les étapes supposent. La deuxième cause la plus fréquente est de combiner le résultat attendu et le résultat réel en une seule phrase, ce qui cache l'écart exact qu'un correctif doit combler.

Comment le session replay remplit-il automatiquement un modèle de rapport de bug ?

Le session replay remplit automatiquement un modèle de rapport de bug parce que l'enregistrement contient déjà les préconditions, les actions numérotées et l'environnement qu'un rapport manuel devrait sinon décrire à la main. Flowsery joint l'enregistrement, les étapes de reproduction et les détails d'environnement à chaque issue dès qu'il arrive dans Slack, Linear ou Jira, si bien que la personne qui signale n'a plus qu'à confirmer la gravité au lieu de retaper des champs que l'enregistrement remplit déjà. Le même rapport de bug par session replay montre à un ingénieur le clic exact qui a déclenché l'échec, ce qui remplit le champ de résultat réel sans que personne n'ait à en écrire une description.

Questions fréquentes

Quels champs un modèle minimal viable de rapport de bug doit-il avoir ?

Un modèle minimal viable a besoin d'un titre, de préconditions, d'étapes de reproduction numérotées, d'un résultat attendu, d'un résultat réel, d'une gravité, d'une priorité et d'un environnement. Omets l'un de ces huit champs et un relecteur doit poser une question de suivi avant de trier le ticket, exactement le délai qu'un modèle existe pour supprimer.

La gravité et la priorité peuvent-elles partager un seul champ dans un modèle de rapport de bug ?

La gravité et la priorité ne devraient pas partager un seul champ, car un bug peut être grave sans être urgent, comme un bug de paiement touchant un seul compte un week-end, ou urgent sans être grave, comme une coquille sur la page d'accueil avant un lancement. Les regrouper en un seul champ force la personne qui signale à deviner quelle réponse le chiffre représente.

Pourquoi les relecteurs rejettent-ils des rapports qui ont des étapes mais pas de préconditions ?

Les relecteurs rejettent les rapports qui ont des étapes mais pas de préconditions parce que la même séquence de clics produit des résultats différents selon l'état du compte, les données existantes ou les actions antérieures effectuées avant l'étape un. Sans point de départ énoncé, un ingénieur doit reconstruire la précondition avant même de tenter les étapes listées.

Quelle est la différence entre le champ d'environnement et le champ de résultat réel ?

Le champ d'environnement nomme où le bug s'est produit, comme le navigateur, le système d'exploitation et l'étape de build, tandis que le champ de résultat réel nomme ce qui s'est passé, comme un message d'erreur ou un écran vide. Un rapport peut indiquer exactement ce qui a mal tourné et rester tout de même irreproductible s'il ne dit jamais quel navigateur ou quel environnement l'a déclenché.

La création automatique de tickets de bug supprime-t-elle le besoin d'un modèle de rapport de bug ?

La création automatique de tickets de bug supprime le besoin de saisir les champs à la main, pas le besoin des champs eux-mêmes. Flowsery joint l'enregistrement, les étapes de reproduction et l'environnement à chaque issue automatiquement, si bien que la personne qui signale relit et confirme les champs au lieu de les retaper de mémoire.

Combien de temps un modèle de rapport de bug devrait-il prendre à remplir ?

Un modèle de rapport de bug devrait prendre le temps qu'il faut pour énoncer huit faits dont un relecteur a besoin : titre, préconditions, étapes, résultat attendu, résultat réel, gravité, priorité et environnement. Un rapport qui prend beaucoup plus longtemps comble avec de la description à la place de l'un de ces faits ; un rapport qui prend moins de temps en a carrément sauté un.

Qui remplit un modèle de rapport de bug, le rapporteur ou le relecteur ?

Le rapporteur remplit chaque champ à la création du ticket, en nommant le titre, les préconditions, les étapes, le résultat attendu et le résultat réel, la gravité, la priorité et l'environnement. Le relecteur lit ce même modèle pour vérifier que rien ne manque avant que le ticket n'arrive à un ingénieur, et le renvoie plutôt que de le corriger lui-même si un champ est vide. Quand le session replay joint automatiquement les étapes et l'environnement, la part du rapporteur se réduit à confirmer la gravité.

Que se passe-t-il après qu'un relecteur rejette un rapport de bug ?

Le ticket revient au rapporteur au lieu d'avancer vers un ingénieur. Le rapporteur doit compléter ce que le relecteur a signalé, le plus souvent une précondition manquante ou un résultat attendu et réel réunis dans une seule phrase, avant que le ticket ne repasse en triage. Personne ne note la gravité ni la priorité sur un rapport renvoyé, puisqu'un trieur ne peut pas évaluer un bug qu'il n'arrive pas à se représenter.

Pourquoi le résultat attendu et le résultat réel ne devraient-ils pas partager une seule phrase ?

Les réunir dans une seule phrase masque justement l'écart qu'un correctif doit combler, ce qui est la deuxième cause la plus fréquente de rejet par un relecteur. Écrits en deux lignes séparées, comme un message attendu "Code invalide" face à un écran blanc réel, un ingénieur peut repérer l'écart directement au lieu de lire un paragraphe sur le ressenti du bug. Le champ de titre ne fonctionne qu'une fois cet écart énoncé clairement, puisque le titre doit nommer l'échec que ces deux lignes décrivent.

L'ordre des champs dans un modèle de rapport de bug a-t-il de l'importance ?

L'ordre compte parce que chaque champ dépend du précédent : les préconditions doivent exister avant les étapes qui les supposent, et la gravité se note avant la priorité pour que l'urgence ait un dommage auquel se rattacher. Le résultat attendu et le résultat réel s'écrivent avant le titre, puisque l'écart entre ces deux lignes est ce que le titre doit nommer. Respecter cet ordre fait que le titre, dernier champ, s'écrit presque de lui-même.