Tous les articles

Rédiger un rapport de bugs, ça n’a pas l’air mais c’est du boulot !

Par Eric Le Bihan

Je sais pas si vous êtes comme moi, mais il y a un truc qui m’énerve au plus haut point c’est de devoir traiter des bugs qui ne sont pas clairement identifiés par le rapporteur. Je m’explique, constater un dysfonctionnement sur un site web et en faire un rapport constitue un travail en soi qui demande à être pris au sérieux pour un traitement rapide et efficace. Malheureusement, la plupart des chefs de projet ou plus généralement les rapporteurs de bugs doivent se dire que la transmission de pensée suffit ou que juste dire qu’il y a un problème sur le site doit suffire. Bon allez petit florilège inspiré de rapports réels ou légèrement modifiés pour garder l’anonymat et la confidentialité des échanges :

Depuis le compte du client, quand tu cliques sur telle partie, une phrase en hollandais se transforme en norvégien.

(NDR : Se transforme ?)

Quand on clique sur tel bouton, un message d’erreur est censé apparaitre, là il n’apparait pas.

(NDR : quel message ?)

Apparemment il y un problème sur telle page, je pense qu’il doit manquer un morceau de JS […]

(NDR : « apparemment », « je pense »)

Telle page est cassée sur tous les navigateurs.

Le montant apparaissant sur telle page pour le produit est complètement bidon, le montant total est ok.

(NDR : bidon, hum… »)

Le site est instable sur Internet Explorer, pouvez-vous regardez ? C’est assez problématique.

(NDR : oui, mais encore ?)

Quand on clique sur le carousel, ça donne le tournis, vous pouvez faire quelque chose ?

Laisse tomber, le temps de faire le screenshot, le bug a disparu.

La palme revenant à une remontée d’un bug critique de fonctionnement d’ajout au panier d’un site non identifié (qui s’avèrera être finalement en phase de développement…)

Qu’est-ce qu’il ressort de tous ces exemples ?

  1. La description du bug est floue et imprécise.
  2. Le rapport a été fait dans la précipitation.
  3. Le demandeur ne s’est pas attardé sur le sujet et la plupart du temps se fait le relais du client sans plus d’analyse.
  4. Les étapes pour reproduire le bug ne sont pas indiquées.
  5. Sur quelle plateforme ? Quel navigateur ? Quelle version ? Où ? Comment ? La plupart du temps on n’en sait rien. Pour le dernier exemple on ne sait pas quel site est concerné.

Les conséquences pour l’intégrateur ou le développeur sont claires : en plus de devoir corriger le bug, il devra la plupart du temps faire un premier travail d’enquête, essayer de comprendre la syntaxe approximative des rédacteurs et s’assurer de la reproductibilité ou de la réalité du bug. Combien d’échanges du type :

  • Non moi j’ai rien, tout fonctionne correctement
  • Bah, chez moi j’ai toujours le problème
  • T’es sur ? c’est quelle version de navigateur ?
  • etc.

Comment éviter tout ça ?

Simplement en suivant quelques règles :

  1. Vider le cache du navigateur avant toute chose.
  2. S’assurer de la réalité du bug.
  3. Prendre 10 à 30 minutes pour faire un raport de bugs correct.
  4. Soigner la rédaction. Inutile d’utiliser du pseudo-langage technique ou marketing qui la plupart du temps n’est compris que du demandeur.
    Mettez vous d’accord sur un glossaire qui facilitera les échanges. Doit on dire select, droplist, dop-down pour une liste déroulante ?
  5. Rester factuel : « j’ai constaté… » action/réaction.
  6. Si vous devez travailler avec des développeurs et/ou intégrateurs, vous devez avoir un minimum de connaissances : html, css, php, ça doit vous
    parler un minimum. Rien ne vous empêche d’être curieux ou de discuter avec le technicien qui se fera un plaisir de vous expliquer.
  7. Reproduire le bug et en décrire toutes les étapes avec précision ainsi que sa fréquence.
  8. Indiquez toutes les informations qui seront utiles pour le constat du bug : version du navigateur, plateforme, lien pour accéder de la page concernée, screenshot si nécessaire.
  9. Indiquer la sévérité du bug, inutile de mettre tout en urgent, ce ne sera pas traité plus rapidement et vous risquez de voir des bugs mineurs,
    résolus avant des bugs bloquant des fonctionnalités plus importantes sur le site.
  10. Relire le rapport avant de l’envoyer (soigner l’orthographe et la rédaction).

Il n’est pas interdit également de se déplacer et de faire une démonstration en direct du problème ce qui peut s’avérer quelques fois plus rapide que des échanges interminables de mails ou de commentaires. Vous pouvez aussi faire une petite vidéo des actions provoquant le bug, certains logiciels comme CamStudio (au hasard) permettent de capturer les mouvements effectués sur votre écran d’ordinateur.

Quelques articles sur le sujet :

Apprendre à rapporter un bogue
Les bugs mystiques
Comment signaler efficacement un bug

Article rédigé par , publié le dans la catégorie Organisation. Vous pouvez suivre les commentaires de cet article en utilisant le flux RSS dédié. Les commentaires sont fermés sur cet article.

19 commentaires

Flux RSS des commentaires de cet article

Régle 11: Quant vous envoyez une capture d’écran d’une page web, prenez une capture de toute la fenêtre du navigateur. En effet, l’interface, la barre d’adresse, les icônes de vos extensions (pourrites) peuvent également apporter des informations utiles.
Règle 12: Non, n’envoyez pas vos captures en les collant dans un fichier excel. Coller les plutôt dans paint et enregistrez les en png ou jpeg.
Règle 13: N’appelez plus un formulaire bordereau, personne ne sait de quelle papier vous parler.

Mon humble contribution. Bon, les 12 et 13 sont là pour le fun mais inspirées de faits réels

Le 19 Oct. 2011 à 22h15 par p_tony

Je suis fan !

Je me permets quand même quelques remarques :

3. Pas de limite de temps. Il est possible de faire un rapport complet en 3 minutes. Mais parfois, cela peut prendre 2 jours.

3bis. il faut permettre de modifier un signalement de bugs, afin d’apporter des précisions avant même qu’elles soient demandées.

4. Appelons cela une « liste déroulante »

7. Je l’aurais mis plus haut dans le classement, mais il y a déjà la 2.

11, 12 : YES :)

Quand je vois certains cas signalés pour moi, j’en pleurerais presque d’envie de cette liste :)

Le 20 Oct. 2011 à 09h32 par Fabrice31

Ah mais quel bon article, qui débouche sur des recos qu’on aimerait crier au monde entier !

Quand on clique sur le carousel, ça donne le tournis, vous pouvez faire quelque chose ?

Ça c’est la perle ^_^

Ce qui est triste, c’est de se dire que les personnes à qui cette liste pourrait servir ne liront probablement jamais ton article.

Si on compilait ce genre de bonnes pratiques à l’adresse des chefs de projet marketing et qu’on le présentait en conf à Paris Web, c’est pareil, je pense qu’on ne s’adresserait pas aux bonnes personnes.

Comme solution, je ne vois que la formation en interne, en fait. Un peu lourd, mais au moins, tu es sûr que le message ne sera pas déformé.

Le 20 Oct. 2011 à 12h36 par Marie

Merci de le fixer au plus vite.

(Tu n’aimes pas mes rapports de bugs ? Évidemment, il n’y a aucun problème :)).

Le 20 Oct. 2011 à 12h46 par Thomas

@Marie : Il y a toujours la possibilité de s’en faire le relais et de formuler des attentes fermes auprès des demandeurs. Théoriquement la question qu’on devrait tous poser aux personnes avec qui nous travaillons directement est  » De quoi avez-vous besoin pour faire le travail que je demande ? ».

Le 20 Oct. 2011 à 13h55 par Eric Le Bihan

Si je rejoins la grosse majorité des remarques/conseils, pour être passé des deux côtés de la barrière, je pense qu’il ne faut pas non plus oublier les contraintes de la personne qui remonte les bugs:
– c’est très dépendant du contexte, mais en règle générale (chargé de communication unique en PME, fondateur de startup,…), il est impossible de passer 30 minutes sur un rapport de bug. Ce n’est pas rentable. Après, c’est le jeu du contrat qui lie le développeur au client (régie ou forfait), et le jeu de la négociation.
– les « je pense » ne sont pas forcément négatif. Le rapporteur n’a souvent pas les compétences techniques, mais peut parfois « sentir », par sa connaissance du produit et de son usage d’où pourrait venir le problème. Pour le développeur, au mieux ça l’aiguille sur la bonne piste, au pire il ignore l’idée.

Sinon pour tout le reste, c’est à imprimer et à donner au client par les développeurs :)

Le 21 Oct. 2011 à 09h17 par Jean

J’aurai presque envie que tous ces mauvais bugs report soient simplement clôturés sans autre forme de procès. Un bug décrié en tant que tel doit pouvoir se reproduire ou au moins être décrit convenablement afin que quelqu’un de plus technique puisse comprendre le problème rapporté.

Les c’est cassé, les liens xxx.ccccc.com/order/payment.html et autre ça donne le tournis ne sont pas du tout l’expression d’un bug.
D’ailleurs le lien vers le processus de commande ou n’importe quelle page d’un espace privé ne fonctionnent jamais sans un certain nombres de manipulations préalables de l’utilisateur. Il faut au moins un produit commandé (pour un process commande), un compte pour se connecter, etc et ça n’est pas plus long de les inclure dans le rapport de bug, particulièrement si ce compte possède un historique permettant de constater le bug.

Enfin, ce qui est triste c’est que ce message n’arrivera probablement jamais aux bonnes oreilles. Intégrateurs : poussez, propagez, luttez !

Le 21 Oct. 2011 à 09h44 par bertrand

Même constat de mon côté. Combien de bugs incompréhensibles, corrigés par une vidange du cache, dans un navigateur même pas dans les specs, etc.

Pester c’est bien, fermer les bugs qui n’en sont pas aussi. Par contre le problème est bien plus profond que cela. Je vois trois causes majeures :

– la plupart du temps les personnes qui remontent les bugs ne sont pas formées pour. Alors oui, il y a peut être un certain manque de curiosité (aller voir les développeurs pour explication) mais quand un chef de projet n’est même pas capable de me dire sur quel navigateur il se trouvait précisément quand il a remonté le bug, cela relève pour moi d’un problème plus grave.
– les outils de gestion de bugs ne sont pas adaptés. 99% de ces outils ont l’air de venir tout droit du néolithique (Bugzilla, Trac, Mantis…). L’utilisateur se préoccupe plus de comment remonter un bug plutôt que de ce qu’il doit écrire j’ai eu le cas d’une chef de projet qui me demandait à quoi servait toutes les boîtes de texte de Bugzilla et à chaque validation de son bug, l’outil lui renvoyait une erreur parce qu’un champ obligatoire n’était pas renseigné. Pas étonnant qu’ils le fassent mal !)
– ajoutez à ça le manque de temps auquel font généralement face les chefs de projet et on a la combinaison gagnante (ou perdante en ce qui nous concerne).

Pour moi, tant que de nouveaux outils ne verront pas le jour, ça continuera à être comme aujourd’hui.

Le 22 Oct. 2011 à 23h17 par Sébastien

@sebastien
Quand je lis ton commentaire je ne peux m’empêcher de me référer à 37 Signals et leur excellent livre Rework.
Je te cite le passage Répondez à votre propre besoin:
Le moyen le plus simple et le plus direct d’inventer un bon produit ou un bon service est d’en concevoir un dont vous avez besoin, que vous aimeriez utiliser. Ainsi, vous travaillerez à résoudre un problème que vous connaissez et vous saurez tout de suite s’il y a du bon dans ce que vous faites. A 37 Signals, nous concevons des produits dont nous avons besoin pour notre entreprise. Par exemple, nous voulions un outil pour retracer facilement à qui nous avions parlé, ce que nous avions dit et quel suivi donner […]
A titre d’exemple, j’avais besoin de pouvoir quantifier le temps passé sur chacune des parties de chacun des projet sur lesquels nous travaillions et que chacun puisse saisir ses informations. Nous avons donc travaillé sur un outil qui me permettrait de suivre le travail de mon équipe et de fournir des informations. Cet outil, mon équipe et moi l’utilisons au quotidien, il répond à nos besoins et n’a pas fini d’évoluer.

Le 23 Oct. 2011 à 00h35 par Eric Le Bihan

C’est l’article à insérer en rouge sur fond noir avec typo 400%, sur la page de création de tickets de bugs.
Histoire que les CdP n’oublient jamais.

Le 28 Oct. 2011 à 08h50 par Julien DIDIER

14. Décrire le comportement attendu, lorsqu’il y en a un. La ressource de test à probablement déjà les spécifications entre les mains et connait la réponse, pas besoin de forcer quelqu’un d’autre à fouiller la documentation.

Et s’il n’y a pas de comportement attendu, ou si le problème correspond aux spécifications, c’est qu’il faut revoir celle-ci. Du coup le développeur seul ne peut rien faire, autant assigner le bug aussi au chargé de projet et au concepteur.

Le 28 Oct. 2011 à 19h32 par Frédéric Hewitt

15. Utiliser un vrai outil de gestion de bugs, comme JIRA

16. Faire la formation client AVANT de lui donner un accès à l’outil de gestion de bugs, sinon il utilisera JIRA comme une messagerie alternative à l’e-mail de l’Internet

17. Ne pas prendre en photo l’écran (et transférer l’image de la carte SD à l’ordinateur, puis créer un email et mettre l’image dedans), mais utiliser une capture d’écran

18. Ne pas se contredire :

Est-ce que vous pouvez réduire et agrandir ce bouton s’il vous plaît ?

C’est sans fin.

Le 06 Jan. 2012 à 17h40 par Frédéric Martinez

… et lorsque vous travaillez avec des webdesigners confirmés, la liste des bugs diminue de 90%… je peux le prouver^^

Le 22 Fév. 2012 à 21h39 par Jacques

Les commentaires sont fermés sur cet article.