Idées, tutoriels et nouveautés de notre équipe.
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.
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 campagne de recette produit un tableur de soixante lignes, dont la moitié inexploitables. Le problème vient rarement des testeurs. Il vient du canal de signalement, qui jette les preuves au moment précis où elles existent.
« Impossible à reproduire » n'est pas une propriété du bug. C'est un constat sur la différence entre deux machines. Il n'existe qu'environ huit différences de ce genre, et chacune laisse une empreinte bien à elle.
Chaque équipe écrit un modèle de rapport de bug. La plupart sont ignorés au bout d'un mois, parce qu'ils demandent aux gens un travail qu'un navigateur pourrait faire à leur place. Voici un modèle qui mérite d'être gardé, et pourquoi supprimer les trois quarts de ses champs.
Séparer les rapports des tâches, c'est la petite décision de structure qui empêche une boîte de réception de bugs de devenir un cimetière, et qui fait des rapports en double votre meilleur atout pour déboguer.