Idées, tutoriels et nouveautés de notre équipe.
Une notification dont personne ne fait rien apprend à ignorer la suivante. Comment j'ai décidé qui est prévenu d'un changement de tâche dans BugDump : des destinataires déduits de la tâche elle-même, rien sur vos propres modifications, et une rafale de clics de tri envoyée en une seule fois.
Les champs personnalisés, c'est la fonctionnalité que toutes les équipes réclament puis regrettent. Le test qui distingue un champ utile d'un champ qui sera vide dans six semaines, et les quatre qui se rentabilisent.
Tous les bug trackers sont livrés avec basse/moyenne/haute/critique, et toutes les équipes les renomment discrètement dans leur tête. À quoi sert vraiment une échelle de priorité, combien de niveaux il vous faut, et pourquoi les mots doivent être les vôtres.
La plupart des tableaux de bord de bugs comptent des choses. Les plus utiles répondent à une seule question : est-ce qu'on suit le rythme ? Quatre métriques qui y répondent, celles qui induisent en erreur sans qu'on s'en aperçoive, et une revue hebdomadaire de cinq minutes construite dessus.
Un ID de bug n'est pas un numéro de ligne en base de données. C'est un mot que les gens se disent. Pourquoi une numérotation par projet et une courte clé de projet comme BD-42 rendent les bugs plus faciles à citer quand on en parle, et les compromis derrière ce choix.
La plupart des équipes ne sont pas lentes à décider quels bugs comptent. Elles sont lentes sur tout ce qui entoure la décision. Une méthode de tri des bugs qui supprime la navigation au lieu de vous demander de réfléchir plus vite.
La maquette est dans Slack, le log sur un drive, la spec dans la boîte mail de quelqu'un. Pourquoi les pièces jointes des rapports de bug s'éparpillent entre les outils, ce que ça coûte quand le bug revient, et comment garder chaque fichier sur le bug lui-même.
Pourquoi les gros outils de suivi des tickets ne conviennent pas aux petites équipes, ce dont un suivi de bugs léger a besoin, et comment en choisir un que les utilisateurs alimenteront vraiment.
Ce qui sépare un rapport de bug qu'on corrige d'un rapport fermé faute de pouvoir le reproduire — la structure, le contexte et une checklist concrète.
Une organisation concrète pour les retours d'un bêta-test — réduire la friction du signalement, capturer le contexte automatiquement et tenir les testeurs au courant.
Comment une agence remplace les fils d'e-mails de rapports de bug par un widget sur chaque site client — des rapports structurés, un tableau par projet et des passations propres.
Vos utilisateurs ne peuvent pas vous envoyer leur console. Comment fonctionne la capture côté client (buffers glissants, interception du réseau, filtrage) et comment l'obtenir avec une seule balise script.