Trier et router les bugs

Le triage est un travail facile à mal faire et invisible quand il est bien fait. Un rapport arrive, quelqu'un le survole, le classe là où ça semble raisonnable, et lui donne une sévérité fondée surtout sur le ton du rapporteur. Deux semaines plus tard, le même bug a trois tickets ouverts sur deux boards, dont une régression que personne n'a repérée parce qu'elle correspondait à un ticket fermé que personne n'a cherché.

Presque rien de tout cela ne demande de jugement produit. Extraire un symptôme, chercher une correspondance existante, décider d'une bande à partir de l'impact décrit, et faire correspondre une zone à l'équipe qui la possède sont des tâches mécaniques, et les faire de façon constante sur 200 rapports par semaine est exactement le point où les humains cessent d'être constants. Cette constance est l'argument pour faire tourner le triage de bugs avec un agent IA : chaque rapport reçoit les cinq mêmes vérifications dès son arrivée.

Ce que le triage de bugs par IA extrait d'un rapport

Chaque rapport est lu dès son arrivée, et cinq éléments en sont extraits, dans les mots du rapporteur quand c'est possible : le symptôme, les étapes de reproduction, l'environnement (navigateur, appareil, version, compte), la fréquence, et l'impact, c'est-à-dire si le rapporteur est bloqué ou contourne le problème.

Tout ce que le rapport n'a pas fourni est signalé comme manquant. Un rapport sans étapes de reproduction vaut quand même la peine d'être classé, mais il doit le signaler visiblement, car « impossible à reproduire » et « jamais reçu la méthode » mènent à des décisions opposées quand quelqu'un envisage plus tard de fermer le ticket.

Le symptôme va dans le titre, jamais le diagnostic du rapporteur. Les gens fournissent une cause avec leur rapport, et cette cause est souvent fausse : « le cache est cassé donc mon tableau de bord est vide » est une observation et une supposition. Un titre qui affirme la supposition envoie le ticket directement à l'équipe qui possède ce qui est supposé, où il est fermé à juste titre comme n'étant pas un bug, pendant que le vrai problème reste ouvert. La supposition va dans le corps avec le nom du rapporteur attaché, et le ticket atterrit là où pointe le symptôme.

Repérer les doublons et les régressions

Le tracker, Linear ici, est cherché sur le symptôme, en comparant le fond plutôt que la formulation : d'abord les tickets ouverts, puis ceux récemment fermés. Un rapport qui existe déjà devient un commentaire sur le ticket existant, avec les détails et le rapporteur du nouveau rapport, et la réponse indique qu'il a été rattaché.

Chercher dans les tickets fermés est l'étape qui se rentabilise. Un rapport correspondant à un ticket fermé la semaine dernière est une régression : le correctif n'a pas tenu, ou il a tenu et autre chose l'a cassé. Traité comme un nouveau bug, il repart en fin de file sans historique, et la personne qui l'a corrigé la première fois ne l'apprend jamais. Une requête de plus change ce résultat, et la régression est traitée comme plus urgente qu'un nouveau bug.

Fixer la sévérité selon l'impact et classer sur le bon board

La sévérité vient de ce qui a été décrit, jamais du ton du rapporteur. Un rapport furieux sur un défaut d'alignement cosmétique n'est pas urgent, et une note polie sur des exports corrompus l'est. Les bandes suivent l'impact :

• bloqué sans contournement possible, ou données perdues ou affichées de façon erronée — bande la plus haute ;
• un contournement à répéter à chaque fois — bande suivante ;
• cosmétique, ou touchant une configuration inhabituelle — bande la plus basse.

Deux faits font monter la bande : le nombre de comptes ayant signalé la même chose, et le fait qu'il s'agisse ou non d'une régression.

Le ticket est ensuite classé sur le board de l'équipe qui possède la zone concernée. Quand la responsabilité est ambiguë, il va sur le board le plus probable avec le doute signalé sur le ticket lui-même. Un ticket laissé sans affectation dans une file de triage en attente d'une décision de routage est la façon la plus courante pour un vrai bug de s'enliser.

Seule la bande la plus haute est aussi postée sur Slack. Router chaque rapport de routine vers le chat apprend à l'équipe que le canal est du bruit de fond, et l'alerte qui avait vraiment besoin d'une réponse en dix minutes reçoit le même traitement que le bouton mal aligné de mardi.