Livrez quelque chose à quelques milliers d'utilisateurs, et la première chose que vous apprendrez, c'est que les rapports de bug n'arrivent pas à raison d'un par bug.
Un seul paiement cassé produit quarante rapports en un après-midi. Si on les traite naïvement, cela fait quarante éléments à lire, quarante à catégoriser et trente-neuf à fermer comme doublons. Le jour le plus chargé de votre outil de suivi de bugs est celui qui produit le moins d'information.
Les rapports et les tâches sont deux choses différentes
BugDump les garde séparés, et c'est la décision de structure sur laquelle repose tout le reste.
Un rapport, c'est un envoi d'un utilisateur à un moment donné : sa description, plus tout ce que le SDK a capturé. Les rapports sont des preuves immuables. On ne les modifie jamais, on ne les fusionne jamais, on ne les dédoublonne jamais.
Une tâche, c'est ce que vous corrigez. Elle a un identifiant public, une colonne sur le tableau, des commentaires et un historique d'activité.
Plusieurs rapports se rattachent à une même tâche. Quarante rapports sur le paiement deviennent une tâche avec quarante éléments de preuve.
Cette distinction n'a rien d'administratif. Elle reflète quelque chose de vrai : les preuves et le travail sont des objets différents, avec des cycles de vie différents. Les preuves s'accumulent et ne changent jamais. Le travail passe par plusieurs états, puis prend fin. Les systèmes qui confondent les deux vous obligent à choisir : soit vous perdez des preuves en fusionnant les doublons, soit vous vous noyez sous les éléments, parce que chaque preuve est aussi une tâche.
Les doublons sont un atout
Dès que les rapports se rattachent à des tâches, les doublons cessent d'être du bruit. Ils deviennent votre meilleur signal de débogage.
Quarante rapports sur une tâche vous donnent ce qu'aucun rapport isolé ne peut donner : l'intersection.
Si les quarante viennent de Safari, c'est un bug Safari, et vous le savez avant d'ouvrir un débogueur. S'ils couvrent tous les navigateurs mais partagent un viewport de moins de 768 px, c'est un problème de responsive. S'ils se concentrent sur une fenêtre de quinze minutes puis s'arrêtent, c'était un déploiement, et c'est ce qui a été livré qu'il faut regarder, pas votre code.
Cette analyse prend quelques secondes quand les rapports sont regroupés, et elle est presque impossible quand ce sont quarante éléments séparés dans une liste. La forme la plus courante d'un vrai incident, beaucoup de gens qui tombent sur la même chose, est justement celle qu'une boîte de réception à plat gère le plus mal.
C'est aussi là que le serveur MCP mérite sa place. « Lis les rapports de la tâche #17 et dis-moi quels navigateurs sont touchés » est une question à laquelle un agent répond en quelques secondes en lisant les quarante. Comparer les rapports entre eux est assez fastidieux pour que les humains s'en dispensent, et c'est pour ça que ça vaut la peine de l'automatiser.
Le tableau
Les tâches vivent sur un tableau kanban dont vous définissez les colonnes. Chaque colonne correspond à l'un des deux états : ouvert ou fermé.
C'est cette correspondance qui compte, pas le libellé. Vous pourriez avoir :
Tri → Confirmé → En cours → Terminé → Ne sera pas corrigé
où les trois premières colonnes sont open et les deux dernières closed. Ou quelque chose de complètement différent : avec le modèle à deux états, le système sait ce qui reste à faire, quel que soit le nom de vos colonnes.
Deux états, pas cinq. Toutes les taxonomies « Reporté / Bloqué / Infos manquantes / En attente du client » que j'ai vues finissent de la même façon : une colonne qui se remplit de tâches que personne ne regarde plus. Si une tâche n'est pas terminée, elle est ouverte, et le travail ouvert doit rester visible.
C'est voulu aussi : Ne sera pas corrigé correspond à closed. Décider de ne pas corriger quelque chose est une vraie résolution. La tâche doit sortir de votre file de tâches ouvertes.
Une boucle de tri qui fonctionne
Lisez les nouveaux rapports, regroupez-les. La plupart sont des doublons. Rattachez-les aux tâches existantes. Ce sont les dix minutes les plus rentables du processus : quarante éléments en deviennent six.
Créez des tâches pour ce qui est vraiment nouveau. Une par bug distinct.
Servez-vous de l'intersection. Pour toute tâche qui a plusieurs rapports, regardez ce qu'ils ont en commun avant de regarder le code.
Déplacez la tâche, ne l'annotez pas. La position sur le tableau, c'est le statut. Une tâche dans En cours avec un commentaire « en fait, c'est bloqué » est une tâche dans la mauvaise colonne.
Fermez. Y compris ce que vous ne corrigerez pas.
Boucler la boucle
Chaque projet peut publier un portail public sur your-project.bugdump.com, où les personnes qui ont signalé un bug suivent les tâches qu'elles ont ouvertes.
C'est la partie que la plupart des outils oublient, et c'est elle qui décide si vous continuez à recevoir des rapports.
Un utilisateur qui signale un bug et n'en entend plus jamais parler en conclut que signaler ne sert à rien. C'est une déduction rationnelle à partir des éléments dont il dispose. La prochaine fois que quelque chose casse, il le contourne sans rien dire, et vous perdez le signal.
Un utilisateur qui voit sa tâche passer de Confirmé à Terminé a appris la leçon inverse. Il signale le bug suivant, et celui d'après.
Vous pouvez aussi laisser les personnes qui signalent rattacher elles-mêmes leur rapport à une tâche. Avec allowTaskAttach activé, quelqu'un qui connaît l'identifiant public d'une tâche envoie son rapport directement sur cette tâche. Pour une équipe QA interne ou un groupe de bêta-testeurs qui suivent déjà vos identifiants de tâches, l'étape de tri disparaît complètement : ils regroupent eux-mêmes leurs doublons.
En bref
Les rapports sont des preuves. Les tâches sont du travail. Gardez-les séparés, laissez les doublons s'accumuler comme des preuves au lieu de les combattre, limitez le tableau à deux vrais états, et montrez aux personnes qui signalent ce qui s'est passé.
Quarante rapports deviennent six bugs, et ces six arrivent avec de meilleures preuves qu'aucun rapport isolé ne pourrait en apporter.
Pour aller plus loin
Trier les bugs plus vite avec un workflow au clavier — supprimer la navigation autour du tri, au lieu de vous demander de décider plus vite.
Les métriques de suivi des bugs qui comptent vraiment — quatre indicateurs qui disent si vous suivez le rythme, et une revue hebdomadaire de cinq minutes.
Un modèle de rapport de bug qui marche vraiment (et comment l'automatiser) — les champs que seul un humain peut remplir, et ceux qu'une machine remplit mieux.