Comment signaler les bugs afin que les développeurs ne vous haissent pas

Personne n’apprécie que ses erreurs soient signalées mais regardons les choses en face : c’est ce que nous faisons en tant que contrôleur qualité, c’est-à-dire des testeurs.

Que nous soyons les propriétaires d’un site web ou un responsable d’une équipe de développeurs, nous devons tous savoir comment mieux communiquer avec les développeurs pour que la collaboration soit la plus optimale possible.

Les développeurs traitent souvent leurs codes et leurs applications de manière très personnelle, de la même manière que les musiciens traitent leurs mélodies ou que les peintres envisagent leurs œuvres d’art.

Cette façon de faire est bénéfique car la communauté des développeurs met l’accent sur l’approche du code propre et croit en l’artisanat du logiciel. C’est formidable car l’équipe et les applications qu’elle développe peuvent s’améliorer. Cependant, comme mentionné précédemment, l’effet secondaire est une forte affection pour leurs propres produits.

Alors, comment les professionnels du contrôle qualité peuvent-ils coopérer avec les développeurs, lorsque nous devons signaler un bug, et comment pouvons-nous éviter d’éventuels conflits ?

1. Toujours être sûr que c’est sans aucun doute un bug

Nous connaissons tous cette sensation agréable lorsqu’après plusieurs heures d’une session d’exploration et de tests, nous retrouvons enfin notre Saint Graal et que nous nous sentons utiles, accomplis et importants. Mais il faut néanmoins nous assurer que nous avons vraiment trouvé un bug.

Personne n’aime les situations où une personne prétend que nous avons mal agi, alors que nous ne l’avons pas fait, et que nous devons maintenant perdre du temps à prouver que nous avons raison et démontrer que rien de mal ne s’est passé.

Nous ne voulons pas être cette personne et nous ne voulons surtout pas nous transformer de façon permanente en cette personne.

Afin d’en être sûr, essayez toujours de reproduire plusieures fois le bug que vous venez de trouver.

Peut-être que c’était juste un incident isolé ou ponctuel ? Peut-être que votre navigateur Web ou que votre système d’exploitation est en cause ? Vérifiez les autres appareils, systèmes d’exploitation, navigateurs Web… tout ce qui peut vous aider à être absolument sûr que ce que vous avez rencontré est effectivement un bug lié au code et non lié à votre environnement de test. 

2. Ne jouez pas le rôle du méchant 

Parfois, nous sommes tellement heureux d’avoir trouvé un bug que nous oublions de vérifier si nous avons tout fait correctement.

Si vous ne pouvez pas vous connecter, alors assurez vous que le mot de passe n’est pas trop court !
Si la géolocalisation ne fonctionne pas, peut être que vous n’avez tout simplement pas permis à l’application d’utiliser votre position ?
Si vous avez signalé un bug il y a une semaine et qu’il est toujours là, il serait judicieux de vérifier si vous n’avez pas tout simplement télécharger l’ancienne version.

Mettez un point d’honneur à toujours vous assurer de ne pas vous retrouver dans de telles situations.

3. Soyez spécifique pour signaler les bugs

Lorsque vous dites à un développeur: « Hey mon pote, ça ne marche pas ! », ça ne fera pas de vous deux les meilleurs amis. Ne soyez pas le parent qui appelle et dit : « Salut chérie, je ne peux pas joindre une photo à mon courrier électronique, je pense que mon ordinateur est en panne, je te laisse intervenir ».  

Dites-leur exactement qu’est ce qui s’est passé et qu’est ce qui s’est passé en étant le plus précis possible. 

Imaginez que c’est un accident et que vous appelez une ambulance ; plus vous donnez d’informations, plus votre ami a de chance d’obtenir une meilleure aide. Signaler l’environnement, la version du système d’exploitation, le navigateur Web, la version de construction et le type de périphérique, c’est essentiel. Donnez un titre unique et intelligent au bug de sorte que même un étranger ou quelqu’un de non connaisseur puisse facilement reconnaître ce qui se passe (tout en restant concis).

4. Soyez un navigateur

Une fois que vous savez reproduire un bug, ne le cachez pas. Ce n’est pas une connaissance hautement secrète. Indiquez aux développeurs comment trouver votre bug et s’il existe plusieurs chemins pour y accéder. Essayez toujours de les inclure car vous ne savez jamais comment ils vont trouver une solution. Soyez leur navigateur.

Il faut également mentionner les conditions préalables à respecter afin de trouver un bug. Si vous devez être connecté, sur quel compte ; premium, standard ou autre ? Si vous avez trouvé un bug dans un module de recherche, avez-vous filtré votre recherche ? Etc. Ceci est une information extrêmement importante, et pourra vous faire économiser un temps précieux.

Vous préférez qu’un expert analyse le bug à votre place ? Faites appel à notre support technique

5. Montrez le bug au lieu de l’expliquer 

C’est ce que j’aime le plus. Je ne suis pas Shakespeare et c’est justement pourquoi j’ai toujours l’impression que mes descriptions peuvent être trop pauvres ou trop complexes. Je ne veux pas qu’un développeur qui lit mes déclarations se sente comme :

Plutôt que d’écrire quelque chose comme « bouton vert sur l’écran de connexion à gauche du menu hamburger, au-dessus du logo », je préfère attacher une capture d’écran avec une énorme flèche rouge disant ICI et un message court. Il y a de nombreux logiciels de captures d’écran qui permettent de faire très rapidement des annotation et partager une image.

Si je trouve un bug dont le chemin est complexe, je préfère l’enregistrer étape par étape plutôt que d’écrire 16 points avec des instructions. comme dit le proverbe : “un schéma vaut mille mots”…

D’habitude, j’utilise les deux méthodes juste pour m’assurer que mon explication est claire afin que personne ne soit obligé de me rendre visite à mon bureau et me demander ce que j’avais réellement en tête lorsque j’ai signalé ce bug.

6. Expliquez comment vous envisagez la correction du bug 

Une fois que nous avons vérifié à deux reprises et que nous avons trouvé et décrit un bug, il serait bien de dire comment il devrait être corrigé (si vous avez cette connaissance bien sûr).

Si vous signalez que la couleur d’arrière-plan est incorrecte sur l’écran des paramètres, ne demandez pas au développeur de rechercher celle qui convient dans les spécifications envoyées par le client il y a trois mois.

Ils pourront résoudre les bugs plus rapidement si vous leur donnez directement toutes les informations utiles et l’anomalie sera résolue bien plus rapidement.

7. Etre bienveillant 

Comme je l’ai mentionné au début, personne n’aime avoir ses erreurs signalées, vous devez donc éviter d’être inutilement critique, voir pas du tout critique, et user de plus de psychologie et d’influence.

N’oubliez pas que nous ne sommes pas juges, ni enseignants et nous n’évaluons pas les performances. Notre tâche est de garantir la qualité et à aider les développeurs à donner le meilleurs d’eux mêmes.

Développer une application est un processus complexe qui nécessite beaucoup d’attention et de planification. Il est impossible d’éviter les accidents et les erreurs. Ne signalez pas les bugs d’une manière prétentieuse et évitez les expressions telles que « encore » ou « sans surprise » lorsque vous dites aux gens que quelque chose ne fonctionne pas correctement.

Après tout, l’erreur est la meilleure façon d’apprendre, et ceux qui ne font pas d’erreurs sont ceux qui ne font rien et qui ne progressent pas.

La chose la plus importante est de vous rappeler que vous êtes une équipe et que vous avez le même objectif. Il n’y a pas de place pour mépriser quiconque dans votre équipe, plus tôt vous vous en rendrez compte, plus vous aurez du plaisir à travailler ensemble.

Conclusion

Je pense que toutes ces étapes vous aideront à devenir un meilleur professionnel du contrôle qualité. Ces règles de spécificité, de brièveté et de bienveillance restent simples et vont améliorer considérablement le travail de tous les membres de votre équipe, vous permettant ainsi de produire de meilleurs logiciels et applications.

N’oubliez pas que votre équipe et vous même reflétez ensemble le résultat final de votre projet.

Questions fréquentes sur le signalement de bugs

Comment rédiger un bon rapport de bug ?

Un bon rapport de bug comporte un titre court et précis, les étapes exactes pour reproduire le problème, le résultat attendu, le résultat obtenu, ainsi que l’environnement concerné : appareil, système d’exploitation, navigateur et sa version, URL de la page. Il s’accompagne d’une capture d’écran ou d’une vidéo et, si possible, des messages d’erreur de la console. Un rapport factuel et reproductible permet au développeur de corriger beaucoup plus vite.

Quels outils utiliser pour signaler des bugs sur un site web ?

Pour signaler des bugs sur un site web, on utilise un outil de gestion des tickets comme Jira, GitHub Issues, GitLab, Linear, Trello ou Azure DevOps afin de centraliser et suivre chaque anomalie. Des extensions de capture visuelle comme Marker.io, BugHerd ou Jam enregistrent automatiquement la capture d’écran, l’URL, le navigateur et les journaux de la console, ce qui facilite grandement le travail des développeurs et des clients non techniques.

Quelle différence entre un bug et une demande d’évolution ?

Un bug est un comportement du logiciel ou du site qui ne correspond pas à ce qui a été spécifié ou à un fonctionnement normal attendu, comme un bouton inactif ou un calcul erroné. Une demande d’évolution porte sur une fonctionnalité nouvelle ou modifiée qui n’était pas prévue au départ. Bien distinguer les deux évite les tensions avec l’équipe de développement et clarifie ce qui relève de la garantie, de la maintenance ou d’un nouveau devis.

Comment prioriser les bugs à corriger ?

Pour prioriser les bugs à corriger, on croise leur gravité, c’est-à-dire l’impact sur l’utilisateur ou le chiffre d’affaires, et leur fréquence ou le nombre de personnes touchées. Un bug bloquant le paiement ou une faille de sécurité passe avant un défaut d’affichage mineur. La plupart des équipes utilisent des niveaux comme critique, majeur, mineur et cosmétique, souvent liés aux délais d’intervention prévus dans un contrat de maintenance.

Faut-il joindre une vidéo à un signalement de bug ?

Joindre une vidéo à un signalement de bug est très utile lorsque le problème dépend d’une séquence d’actions, d’une animation ou d’un comportement intermittent difficile à décrire par écrit. Un enregistrement d’écran de quelques secondes, réalisé avec Loom, l’outil de capture du système ou une extension de signalement, montre exactement ce que voit l’utilisateur. Il faut veiller à ne pas y laisser apparaître de mots de passe ou de données personnelles.

Comment communiquer efficacement avec un développeur ?

Communiquer efficacement avec un développeur repose sur des messages factuels, précis et bienveillants, qui décrivent le problème observé plutôt que de proposer une solution technique imposée. Il est utile de regrouper les retours dans un outil de suivi commun, de traiter un sujet par ticket et de répondre rapidement aux questions de clarification. Cette méthode, issue des pratiques agiles, réduit les allers-retours et accélère la livraison.