Un bogue vite résolu commence par un bogue bien traité

Tous les développeurs ont forcément déjà reçu de mauvais rapports de bogues. Il y a les rapports qui ne disent rien (« Ça ne marche pas! »), d’autres qui n’ont aucun sens ou qui ne donnent pas assez de renseignements, ou même de fausses informations! Les bogues peuvent être dus à la négligence des équipes de développement (même si c’est parfois difficile de l’accepter), à certaines maladresses des utilisateurs, à des interférences logicielles ou à des problèmes matériels…

Nombreux ou pas, les bogues sont lourds, et ceci explique pourquoi on considère souvent le support technique comme une tâche horrible. Toutefois, les communiqués pour signaler les bogues ne sont pas tous désagréables : il y en a des clairs, utiles et informatifs. Avec un peu d’efforts, tout devient plus efficace. Cependant, la question c’est comment constituer un bon rapport de bogues.

Partir sur une bonne base

Le but d’un rapport de bogues n’est pas de transmettre son sentiment de panique ni de faire porter le blâme à quelqu’un, c’est plutôt de permettre au développeur de voir le programme se planter devant lui. Vous pouvez soit lui montrer de visu, soit lui fournir des instructions soignées et détaillées sur la façon d’y arriver. S’il y parvient, alors il utilisera les données recueillies pendant le processus pour découvrir la cause du bogue. S’il n’y parvient pas, il devra vous demander d’obtenir les données pour lui, ce qui constitue une perte de temps.

Dans un rapport de bogues, privilégiez les faits (« J’ai fait ceci, et cela s’est produit. »). Écartez toute spéculation (« Je pense que c’est ça le problème. ») Comme lorsque vous allez voir le médecin, contentez-vous de décrire les symptômes et les antécédents. Laissez le médecin faire son travail! N’allez pas consommer des médicaments à l’aveuglette sans l’avis d’un spécialiste!

Lors de l’échange avec le développeur, ce que vous souhaitez c’est que le bogue soit corrigé, vite et bien. Ne prenez pas le risque de houspiller les développeurs, ou de leur faire perdre leur temps. Bien que la « faute » puisse être la leur, le bogue et, par le fait même, votre mécontentement seront toujours écartés plus rapidement si vous aidez les développeurs en leur fournissant avec tact les renseignements pertinents. De plus, si le programme bogué est mis à votre disposition sans contrepartie, ses développeurs continueront à faire preuve d’obligeance si vos échanges restent cordiaux.

« Ça ne fonctionne toujours pas! »

Les développeurs investis et professionnels ne sont pas inconscients : si le programme ne fonctionnait pas du tout, ils s’en seraient déjà rendu compte. S’ils n’ont rien remarqué, de leur côté, ça doit fonctionner. Ceci implique donc qu’en tant qu’utilisateur, vous faites quelque chose d’une façon imprévue ou que votre environnement est différent du leur. Ils ont besoin de ces renseignements. Par conséquent, faites-leur-en part dans le rapport de bogues, même si vous avez un doute sur la valeur de ceux-ci.

Jusqu’à maintenant, vous devez vous dire que je défends aveuglément les équipes de développement, avec exagération. C’est vrai, car je considère que tout développeur digne de ce nom ne devrait pas laisser passer le moindre bogue dans une application livrée et utilisée. Je parle dans le paragraphe ci-dessus de développeurs investis et professionnels. Quelle que soit l’expérience des développeurs, la profession doit encourager l’excellence technique et humaine et ne jamais faire fi de la qualité. (Et ce sujet est repris dans de nombreux billets de ce blogue.) Si les bogues sont récurrents, il est évident que des obstacles ne sont pas surmontables par l’équipe. Celle-ci doit alors être accompagnée pour revoir ses pratiques et son savoir-être.

La recette pour un bon signalement de bogue

Dans un premier temps, le but de l’exercice est de permettre au développeur de reproduire le bogue. Pour cela, il doit exécuter sa propre copie du programme, effectuer les mêmes manipulations et le faire se planter de la même manière. Une fois qu’il a réussi, il peut passer à la résolution du bogue.

Premièrement, et ce, quel que soit l’outil ou le canal de communication employé, tout bon rapport de bogues doit avoir un titre évocateur et spécifique pour cibler le contexte du bogue. Par exemple, « Les requêtes X dans un contexte Y sont KO », c’est tellement plus précis que « L’application Z ne marche pas! » Assurez-vous aussi que le message soit adressé aux bons interlocuteurs. De plus, donnez quelques renseignements sur votre poste, votre environnement de travail (système d’exploitation, résolution d’écran, etc., si cela s’avère pertinent).

S’en suit la description. Assurez-vous de communiquer le processus et les étapes vous ayant mené à l’apparition du bogue. S’il s’agit d’un programme graphique, dites sur quels boutons vous avez cliqué et dans quel ordre. Si c’est un programme lancé par une commande, indiquez précisément celle que vous avez utilisée. Une transcription complète de la séance indiquant quelles commandes vous avez tapées et quelles réponses l’ordinateur a retournées sont très appréciables pour constater le bogue tel qu’il est. Des pièces jointes pour comparer le bogue aux résultats attendus font aussi très bien l’affaire (captures d’écran, exportation de données…).

Voici ci-dessous un modèle à utiliser :

Scénario

1. Je vais sur la page d’accueil.
2. J’entre mon nom d’utilisateur dans le champ Nom.
3. J’entre mon mot de passe dans le champ Mot de passe (note : celui inscrit dans le dernier courriel de rappel du 2 janvier 2015).
4. Je clique le bouton Connecter.

Résultat observé : Je reçois un message m’informant que l’un des renseignements est erroné et je ne peux pas accéder à mon espace utilisateur.

Résultat attendu : Je devrais pouvoir accéder à mon espace.

En bref, soyez précis et procédural. Ne vous inquiétez pas si, au final, le rapport ressemble à une recette de cuisine. C’est au contraire un très bon indicateur de la qualité de votre signalement de bogue.

Enfin, n’oubliez pas les remerciements d’usage.

À vous de jouer! N’hésitez pas à partager ce billet en vue de vos prochains échanges avec l’équipe de support technique… et voyez les bogues s’envoler! 😉