Intro

Le mot Bug est souvent mal pris par les développeurs car certains le ressentent comme une attaque sur la qualité de leur travail. Pourtant un humain ne peut pas penser à tous les cas d’utilisation et la diplomatie et le dialogue sont alors nécessaires pour que les deux parties soient heureuses à la fin 🙂

La Petite Histoire

Le Bug provient du mot anglais « Bug » : la petite bête qu’on ne veut pas avoir chez soi. Il y souvent une sur utilisation de ce mot et aussi des mauvaises utilisations. Par moment, le mot est utilisé pour des changements que l’on veut avoir dans son application, il peut être utilisé aussi quand l’ensemble ne fonctionne pas alors que l’on serait plus sur un problème d’infrastructure. L’utilisation du mot Bug est souvent faite sur un large domaine alors que c’est un terme qui devrait être très ciblé et précis en terme de contexte.

Création du Bug : Un seul Objectif !

Le seul objectif d’un bug est qu’il soit corrigé à la fin 🙂

Pour faciliter le travail du développeur, le plus important est que le Bug soit facile à reproduire grâce à la description fournie dans la fiche de Bug.

En général le Bug contient les données suivantes :

• Titre : La description du Problème
• Les étapes pour reproduire
• Le résultat Observé
• Le résultat attendu

Titre : Description du Problème

Le titre permet de comprendre en une ligne ce qui ne va pas. Il doit être concis et clair pour toutes les personnes amenées à lire le titre de bug.

Quelques Exemples :

Enregistrement impossible des paramètres utilisateurs

Affichage incorrect des planètes sur l’écran Espace Personnel -> Simulation

Etapes pour reproduire

Les différentes étapes doivent être indiquées pour reproduire le problème. Une vidéo sous forme de gif peut être aussi utilisée.

Exemple :

Si le problème n’est pas reproductible à chaque essai, il faudra le préciser : 1/10, 1/5 etc

Une fois les étapes écrites, il ne faut pas hésiter à vérifier que le problème est bien reproduit avec ce que l’on a écrit dans le Bug.

Il s’agit de la partie la plus importante pour le développeur. Si les étapes sont claires et précises, le développeur passera moins de 5min à reproduire. Sachant que le temps passé pour reproduire un problème représente environ 75% du travail de correction : on peut presque dire que le dicton suivant :

« Bug reproduit : Bug Corrigé ! »

Le résultat observé

Décrivez ici ce qui vous semble incorrect. Tout simplement 🙂

Le résultat attendu

Indiquez dans cette section le résultat que vous attendez. Si vous avez un doute, n’hésitez pas à proposer des idées.

Résultat

Si le développeur corrige le problème directement sans votre aide : c’est gagné !! Vous n’aurez qu’à attendre la prochaine publication pour voir le correctif 😉

Par contre s’il n’arrive pas à le corriger ou s’il manque d’information, il vous laissera un message sur le bug. Faites donc attention à vos mails et à vos notifications GitHub ou autres.

Ensemble vous arriverez à trouver la correction sans aucun doute et à faire profiter à toute la communauté le correctif qui probablement gênait plus de personnes qu’on ne le pense 🙂

Conclusion

Un Bug est parfois difficile à identifier que ce soit du côté de celui qui le signale ou du côté du développeur : il est donc important de travailler ensemble pour réussir à décider de l’avenir du Bug. Parfois il pourra être corrigé immédiatement, il pourra aussi être planifié pour une prochaine version ou bien complétement abandonné car il concernera une partie de code qui sera bientôt supprimée.

Dans tous les cas la fiche de Bug ou le ticket aide le produit à devenir meilleur. Car même si aucune action directe n’est requise il amène la réflexion de ce qu’il faudrait améliorer et dans l’innovation toutes les idées sont à prendre 🙂