Comment signaler un bogue qui rendra vos développeurs heureux ?

Temps de lecture estimé : 6 minutes

Comment correctement signaler un bogue à un développeur ? Comment vous assurer que ce dernier comprendra le plus rapidement possible le problème ? Dans cet article nous vous livrons toutes les bonnes astuces pour rédiger un rapport de bogue le plus efficacement possible.

01. Pourquoi rendre mon développeur heureux ?
02. Rédiger un titre qui résume un problème spécifique
03. Description du bogue, introduisez le problème avant de le décrire
04. Description du bogue, les autres paragraphes
05. La gravité et la priorité
06. Relisez avant de poster
07. Trucs et astuces
08. Sauvez un développeur, rédigez un bon rapport

01. Pourquoi rendre mon développeur heureux ?

"The point of writing a problem report (bug report) is to get bugs fixed”
Cem Kaner.

Si votre rapport de bogue est efficace, ses chances d'être corrigé rapidement sont plus élevées.

À l’inverse, si votre bogue n’est pas signalé correctement le développeur rejettera très probablement ce bogue en le déclarant comme non reproductible ou incomplet, trop vague, trop dense, multiple, etc. Le voilà donc malheureux comme les blés 🙁.

Cela peut également blesser votre moral de rapporteur et parfois aussi votre ego. "J'ai signalé le bug correctement", "Je peux le reproduire", "Pourquoi a-t-il/elle rejeté le bogue ?", "Ce n'est pas de ma faute" etc.). Et ainsi nuire à notre relation. Mais pourquoi donc nous gâcher la vie ?

Prenons un exemple. Vous venez de dire à votre équipe de développeurs que vous avez trouvé un bogue et obtenez la réponse :

“J'ai besoin de plus d'informations.”

Avant que vous ne vous en rendiez compte, vous avez un fil de discussion d'un million de kilomètres de long, le développeur est furieux et le vilain bogue est toujours là 🙁.

Bon à savoir : les développeurs sont généralement confrontés à deux extrêmes, aussi redoutables que le bogue « himself », dans les rapports qu’ils reçoivent :

• Trop d'informations inutiles.
• Trop peu d'informations importantes.

“Le site Web ne fonctionne pas.”

Ou encore

“J'ai trouvé un bogue sur la page d'accueil et un autre bogue sur la page des produits. Vous pouvez regarder s'il-vous-plaît ?”

Sur la base de ces informations, il n'y a aucun moyen de savoir quel est le problème et le développeur devra passer beaucoup de temps à enquêter.

La façon dont vous documentez le bogue est extrêmement importante. La correction d'un bogue dépend de l'efficacité avec laquelle vous le signalez.

Dans ce guide, nous expliquons comment améliorer vos chances d’obtenir une réponse rapide et efficace.

Nous allons explorer le bon et le mauvais des rapports de bogues. Et nous vous partagerons quelques trucs et astuces sur la façon de rédiger des rapports de bogues exploitables.

Des rapports qui feront que vos développeurs vous aimeront (encore plus) ! Et seront ravis de vous aider 😊 (encore plus vite) et donc heureux. Voilà ! Il faut reconnaître qu’ils ne sont pas faciles à contenter dans cette caste.

02. Rédiger un titre qui résume un problème spécifique

Le titre est la première chose que les développeurs verront et si votre titre n'est pas lisible et précis, ils ne liront pas.

Alors faites en sorte que « le titre le vaut bien » 😊 :

• Soyez bref et précis.
• Votre titre peut être utilisé dans les recherches, alors assurez-vous d'inclure des mots-clés importants.
• Assurez-vous qu'il résume clairement le bogue et mentionne l'emplacement ou la catégorie. Avoir un titre clair sur votre rapport permet au développeur de le retrouver plus facilement et de repérer les éventuels doublons avec d’autres rapports.
• L’orthographe, la grammaire et la ponctuation sont importantes ! Rappelez-vous, le titre est la première partie de votre rapport que les développeurs verront. Et vous voulez faire bonne impression 😉.
• Si vous avez du mal à résumer le problème, écrivez le titre en dernier. Parfois, et même souvent, écrire la description du rapport en premier peut faciliter la rédaction du titre du problème.

Exemples :

Mauvais : "Je ne vois pas le produit lorsque je l'ajoute, pour une raison quelconque, j'essaie et ça ne marche pas. POURQUOI ? Corrigez-le dès que possible."

• Vague
• Agressif
• Comprend trop de mots
• Demande qu'une solution soit mise en place (c’est déjà le but du rapport en vrai :)

Bon : "PANIER - Les nouveaux articles ajoutés au panier n'apparaissent pas."

• Il aide les développeurs à localiser instantanément le problème (PANIER)
• Il se concentre sur le problème technique réel

Lorsque les développeurs l'examineront, ils pourront évaluer instantanément le problème.

Voici un autre exemple de mauvais et de bons titres mettant en évidence les points soulevés ci-dessus.

Mauvais : "Le texte sur la page de tarification a l'air bizarre."

Bon : "TARIFICATION, la taille de la police du texte du titre est incorrecte."

03. Description du bogue, introduisez le problème avant de le décrire

Dans le corps de votre question, commencez par développer le résumé que vous avez mis dans le titre.

En aussi peu de mots que possibles, indiquez quand et comment vous avez rencontré le problème et les difficultés qui vous ont empêchés de le résoudre vous-même (paramétrage par exemple).

• Soignez la rédaction. Rappelez-vous, l’orthographe, la grammaire et la ponctuation sont importantes.
• Restez factuel : « j’ai constaté… » action/réaction.
• Votre titre et votre description peuvent être utilisés dans les recherches, alors assurez-vous d'inclure des mots-clés importants.
• Le premier paragraphe de votre question est la deuxième chose que la plupart des développeurs verront, alors rendez-le aussi précis et informatif que possible.

Exemples :

Mauvais : "L'autre jour, j'essayais d'ajouter des éléments à tester et rien ne s'est affiché lorsque j'ai fait cela ou cliqué sur le bouton."

Bon : "Le [DATE], j'ai essayé d'ajouter [PRODUIT] au panier, rien ne s'est produit après avoir cliqué sur le bouton "Ajouter" sur la page Web de présentation du produit."

Mauvais : “Le texte sur la page de tarification a l'air super bizarre et ne semble pas correct. Il ne devrait pas avoir l'air si grand et devrait être d'une couleur différente.”

Bon : “la taille et la couleur du texte du titre sur la page de tarification ne correspondent pas aux spécifications originales.”

Mauvais : “Régression ! Avant ce n’était pas pareil.”

Bon : “Le [DATE], j’ai pu ajouter [PRODUIT] dans la commande [REF]. Aujourd’hui, dans les mêmes conditions, cela est impossible.”

Et s’il n’y a pas de “preuve” factuelle que “ça allait mieux avant”, il est préférable de se concentrer sur la description du bogue constaté. Tout le monde gagne du temps 😊

04. Description du bogue, les autres paragraphes

Si votre premier paragraphe ne suffit pas, vous pouvez en ajouter à votre rapport. Bon, ce n’est pas un roman non plus hein ?

1 - La preuve visuelle

Nous savons tous qu'une image vaut mille mots. Donc, c'est aussi la même chose pour les rapports de bogues.

Bien qu'elle ne raconte pas toute l'histoire, une capture d'écran ou une vidéo peut ajouter beaucoup de valeur en permettant aux développeurs de voir et de comprendre le problème plus rapidement.

Mais attention, ne publiez pas d’images de code, de données, de messages d’erreur, etc. Copiez ou tapez le texte dans la description. Veuillez réserver l’utilisation d’images pour des diagrammes ou la démonstration de bogues de rendu, des choses impossibles à décrire avec précision via du texte.

2 - Les résultats attendus par rapport aux résultats réels

Prenez maintenant le temps d'expliquer au développeur ce à quoi vous vous attendiez et ce qui s'est réellement passé.

Exemple :

Résultat attendu : L'article doit être ajouté au panier lorsque je clique sur "ajouter".

Résultat réel : L'article n'apparaît pas dans le panier.

3 - Les étapes pour reproduire

Reproduire le bogue est un besoin essentiel du rapport d’erreur.

« On ne peut bien corriger une erreur que si on arrive à la reproduire », les développeurs, Hello World, 1984

Supposez toujours que le développeur n'a aucune idée du bogue que vous avez trouvé.

Alors, comment le reproduit-il ? Essayez de reproduire le problème vous-même et assurez-vous de le faire en utilisant uniquement les informations incluses dans votre rapport.

Les étapes à suivre doivent être complètes, faciles à comprendre et courtes.

L'objectif le plus important de cette étape est que le développeur atteigne le bogue rapidement.

Exemple :

1. Rechercher le produit A
2. Cliquez sur le produit A dans les résultats de recherche
3. Cliquez sur le bouton "Ajouter au panier"
4. Accéder au panier

Conseil de pros 😊 :

• Utilisez une liste numérotée pour expliquer les étapes
• Si vous avez déjà réussi à recréer le problème plusieurs fois, vous pouvez inclure le taux de reproductibilité (exemple : bogue reproduit 10 fois sur 10).

4 - L’URL source

Un élément primordial, mais facile à oublier, est l'URL source.

Cela aidera les développeurs à naviguer plus rapidement, ce qui accélérera la détection du problème et fera gagner beaucoup de temps à tout le monde !

05. La gravité et la priorité

En définissant la gravité ou la priorité du problème, le développeur comprend à quelle vitesse un bogue doit être corrigé.

La gravité de votre bogue peut être définie par le niveau d'impact qu'il a sur votre site Web ou votre produit. Une fois que cela a été déterminé, vous pouvez l'étiqueter comme suit :

• Critique
• Majeur
• Mineure

La priorité aide le développeur à déterminer quel bogue il doit étudier et corriger en premier. Ici, vous pouvez choisir entre :

• Haute
• Moyen
• Bas

En tant que rapporteur de bogue, vous serez normalement chargé d'identifier la gravité et la priorité.

Cependant, comme le travail d'équipe permet à la magie de fonctionner, n'oubliez pas de confirmer la décision avec le développeur.

06. Relisez avant de poster

Maintenant que vous êtes prêt à poster votre rapport, respirez profondément et lisez-le du début à la fin (on vérifiera de toute façon).

• Ajoutez tous les détails importants que vous avez manqués et lisez à nouveau.
• Supprimer les détails inutiles que vous relevez et lisez à nouveau.
• C’est le bon moment pour vous assurer que votre titre décrit toujours le problème😊.

07. Trucs et astuces

Il est toujours bon de garder à l'esprit ces directives de base.

• Signalez le problème immédiatement.
• Évitez les doublons : Essayez toujours de rechercher les rapports existants.
• Reproduisez le bogue avant de créer le rapport : Cela rend plus probable que le développeur puisse reproduire le problème et identifier d'où il provient.

• Restez simple et stupide : Restez tout aussi simple que possible. L'utilisation de listes à puces ou numérotées peut aider.
• Soyez gentil : Les développeurs sont aussi des personnes (certes un peu curieuses) et des bogues se produisent (pas à leur connaissance, mais bon). Ils font partie du processus de création des sites Web de qualité. Personne n’aime les bogues.

08. Sauvez un développeur, rédigez un bon rapport :)

Il va sans dire que si vous pouvez maîtriser l'art d'un bon rapport de bogue, vous économiserez plus que du temps et de l'argent, vous sauverez la santé mentale du développeur 😊.

Maintenant que nous vous avons donné les bonnes astuces, il est temps de les utiliser. Fini la tornade des fils de conversation hurlants embarrassants qui vous font crier la nuit au sommet des montagnes :)

Nul doute que vous ferez monter en flèche le bonheur de votre développeur.

Apprenez-en davantage, en consultant dès maintenant notre page dédiée.