Qu'est-ce que le suivi des bugs ? La différence entre une trace et un message

Le suivi des bugs consiste à garder chaque défaut connu au même endroit, sous une forme qui survit au départ en vacances de la personne qui l’a trouvé. C’est toute l’idée. Le logiciel auquel les gens pensent quand ils disent « bug tracker » n’est que le classeur qui rend cela possible.

La distinction qui compte est celle entre une trace et un message. Un message, c’est ce que vous envoyez quand vous remarquez quelque chose : une ligne de chat, un courriel, une remarque en passant devant le bureau de quelqu’un. Il s’adresse à une personne, il est lu une fois, et il disparaît. Une trace ne s’adresse à personne en particulier et se lit chaque fois que quelqu’un pose la bonne question. Le suivi des bugs est la pratique qui transforme le premier en la seconde.

Ce qu’un outil de suivi doit faire

Quatre choses. Tout le reste est du confort.

• Tenir une entrée par problème, pour que deux personnes qui trouvent la même chose se trouvent l’une l’autre au lieu de signaler deux fois.
• Dire où chacune en est - ouverte, en cours, corrigée, vérifiée, fermée - d’une manière qui soit vraie plutôt que souhaitée.
• Nommer un responsable, parce qu’un défaut qui appartient à l’équipe n’appartient à personne.
• Rester consultable plus tard, ce que l’on néglige au moment de choisir et que l’on regrette au quatrième mois.

Un tableur fait mal les trois premières et pas du tout la quatrième. Un canal de discussion n’en fait aucune, ce qui n’est pas un reproche adressé au chat : c’est un support de messages qui fait exactement ce pour quoi il est fait.

Ce qui va dans une entrée

Moins que ce que demandent la plupart des modèles, et plus que ce que portent la plupart des rapports.

Les éléments qui méritent leur place sont ceux dont quelqu’un d’autre a besoin pour agir : ce qui s’est passé, ce qui était attendu à la place, comment y revenir, et où cela s’est produit - navigateur, version, compte, URL. Notre guide pour écrire un rapport de bug est la version longue de cette liste, et il contient un modèle que vous pouvez coller dans un formulaire.

Tout le reste d’un formulaire type relève des métadonnées du processus plutôt que du problème : gravité, priorité, composant, jalon, la personne qui en a la charge. Utile, mais cela appartient à qui pilote la gestion des défauts, pas à la personne qui a remarqué que le bouton était cassé. Le demander à celui qui signale, au moment où il signale, est la façon la plus courante de rendre le signalement assez coûteux pour que les gens cessent de le faire.

Trois façons d’échouer

Presque tous les outils de suivi auxquels on cesse de faire confiance y sont arrivés par l’une de ces trois voies.

Le cimetière. Rien n’est jamais fermé, donc le compte ne fait que monter, donc personne ne lit la liste, donc de vrais défauts arrivent et ne sont jamais vus. Un arriéré de huit cents tickets que personne n’a ouverts cette année n’est la trace de rien ; c’est un endroit où les choses vont.

Des statuts qui mentent. Chaque entrée dit « ouvert » parce que les faire avancer est le travail de quelqu’un et que personne ne l’a. À ce stade le champ de statut est décoratif, et la seule façon de savoir où en est quoi que ce soit est de demander à une personne, c’est-à-dire ce que l’outil était censé remplacer.

La pile de doublons. Le même défaut signalé six fois parce que chercher coûte plus cher que taper. On en accuse d’habitude ceux qui signalent, et c’est d’habitude un problème de recherche : si une recherche sur les mots qu’emploierait une personne normale ne trouve pas l’entrée existante, l’outil lui a appris à signaler de nouveau.

D’où viennent les entrées compte plus que l’outil qui les garde

Les équipes passent longtemps à choisir entre des outils de suivi et presque pas de temps sur l’étape d’avant : comment un défaut passe de la personne qui l’a vu à l’outil, tout simplement.

C’est sur ce trajet que meurent les rapports. Quelqu’un remarque un problème, et entre le remarquer et avoir écrit une entrée utile il y a un fossé : quel navigateur était-ce, que disait la console, quelle était l’URL, sur quoi ai-je cliqué en premier. La plupart des gens, la plupart du temps, écriront deux phrases et passeront à autre chose, parce que l’alternative est un quart d’heure d’enquête pour un bug qui n’est pas le leur.

Tout ce qui raccourcit ce fossé élève la qualité de tout ce qui suit. Un formulaire sur la page où le bug s’est produit vaut mieux qu’un lien vers l’outil de suivi. Une capture qui recueille la moitié technique toute seule vaut mieux que demander à un agent du support d’ouvrir les outils de développement. Capturer le rapport là où est le bug est le même problème vu de l’autre bout.

En choisir un

Le conseil honnête est que le choix compte moins que l’habitude. Jira, Linear, GitHub Issues, Bugzilla, Trello avec une colonne appelée Bugs : les quatre choses ci-dessus sont atteignables dans n’importe lequel d’entre eux, et aucun ne les fera à votre place.

Deux questions valent la peine d’être posées à un candidat, et ce ne sont pas celles des pages comparatives :

Question faible

Lequel a le plus d'intégrations et les meilleurs tableaux de bord de reporting ?

Meilleure question

Quelqu'un qui n'est pas dans l'équipe technique peut-il y déposer un rapport sans aide, et quelqu'un peut-il retrouver une entrée vieille de deux ans avec les mots dont il se souvient ?

Si signaler exige un compte, un projet, un composant et un type de ticket, les personnes les plus proches de vos clients - support, commerce, QA, le client lui-même - ne signaleront pas. Leurs bugs arriveront sous forme de messages, et la différence entre une trace et un message était justement ce que vous cherchiez à acheter.

Suivi, tests et tout le reste

Le suivi des bugs se trouve en aval de tout ce qui trouve des bugs, et c’est pourquoi il ramasse le vocabulaire de tout le reste. Un plan de test dit comment les défauts sont signalés et qui décide si l’un d’eux bloque une livraison. Les tests de régression existent parce qu’un outil plein d’entrées fermées est une liste de choses qui marchaient avant. Les tests instables sont ce qui arrive quand la chose suivie n’arrive pas à décider si elle est un défaut.

Un outil de suivi n’améliore pas le logiciel. Il empêche de dépenser deux fois le même après-midi.