Qu'est-ce que la gestion des défauts ? Gravité, priorité et les états intermédiaires

La gestion des défauts, c’est ce qui arrive à un bogue entre le moment où quelqu’un le remarque et celui où quelqu’un confirme qu’il a disparu. C’est un processus, pas un outil : les états que traverse un défaut, qui le fait avancer, et comment l’équipe décide lesquels sont corrigés en premier.

La plupart des équipes en ont un, qu’elles l’aient écrit ou non. La version non documentée est en général « mets-le dans le tracker et espère », ce qui marche jusqu’à ce qu’il y ait plus de défauts que quiconque peut garder en tête - typiquement une trentaine.

Le cycle de vie

Les états portent des noms différents selon les trackers, et la forme en dessous est la même.

• Nouveau. Signalé, personne ne l’a encore regardé.
• Trié. Quelqu’un l’a lu, a confirmé qu’il est réel et a décidé de son urgence.
• Assigné. Il a un responsable.
• Corrigé. Le responsable pense que c’est fait. Personne d’autre ne pense encore quoi que ce soit.
• Vérifié. Quelqu’un qui n’est pas le responsable l’a confirmé face au rapport d’origine.
• Fermé. Terminé.

Deux autres fins sont légitimes et souvent mal gérées. Rejeté signifie que ce n’est pas un défaut : le comportement est voulu, ou le rapport décrivait un malentendu. Reporté signifie qu’il est réel et qu’il n’est pas corrigé maintenant. Les deux demandent une raison écrite dans le ticket, car l’alternative est que le même défaut soit signalé à nouveau dans six semaines par quelqu’un qui n’a aucun moyen de savoir qu’il avait déjà été examiné.

L’étape que les équipes sautent discrètement est la vérification. Un défaut fermé par la personne qui l’a corrigé est un défaut fermé sur l’avis d’une seule personne, et la correction qui ne couvrait pas réellement le cas signalé est une expérience assez courante pour avoir son propre problème de reproduction.

Gravité et priorité ne sont pas la même chose

C’est la confusion qui mérite d’être levée, parce qu’elle provoque des disputes qui ressemblent à des désaccords sur le défaut mais qui sont en fait deux personnes employant un mot pour deux idées.

La gravité dit à quel point le comportement est mauvais. Une perte de données est grave. Une icône mal alignée non. C’est une propriété du défaut lui-même et elle ne change pas parce que le calendrier a changé.

La priorité dit à quel point la correction est proche. C’est une décision d’entreprise, et elle dépend de qui est touché, de combien de personnes, de l’existence d’un contournement et de ce qui se dispute la même semaine.

Les deux se séparent dans les deux sens, et c’est ce qui rend la distinction utile :

Gravité élevée, priorité faible

Un plantage sur un écran d'administration utilisé deux fois par an par une personne qui connaît le contournement

Gravité faible, priorité élevée

Le nom de l'entreprise mal orthographié sur la page des tarifs, vu par tout le monde, corrigé ce matin

Les trackers qui n’offrent qu’un seul champ obligent à faire la moyenne des deux en un nombre qui ne signifie ni l’un ni l’autre. Si c’est le cas du vôtre, dites lequel des deux il désigne et écrivez-le, sinon la moitié de l’équipe classe par dommage et l’autre moitié par urgence.

Qui trie, et à quelle fréquence

Le tri est une décision, il lui faut donc quelqu’un qui a le droit de la prendre. Dans une petite équipe c’est une personne qui parcourt la file des nouveaux chaque matin. Dans une plus grande c’est une courte réunion récurrente avec un développeur, un testeur et quelqu’un qui parle au nom du produit.

Ce qui compte plus que le format, c’est la régularité. Une file triée quand quelqu’un y pense développe une traîne de défauts que personne n’a lus, et ce que cela coûte n’est pas la traîne intouchée : c’est que plus personne ne fait confiance à la file, si bien que les vrais défauts sont signalés dans la messagerie à la place.

Le tri demande trois réponses par défaut, et pas davantage : est-il réel, à quel point est-il grave, qui en est responsable. Tout ce qui dure plus longtemps est du travail de conception qui se déroule dans la mauvaise réunion.

Les rapports décident de la vitesse du processus

Chaque état après « nouveau » dépend de la qualité du rapport.

Le tri ne peut pas juger la gravité sans savoir ce qui s’est réellement passé. Le responsable ne peut pas corriger ce qu’il ne peut pas reproduire. La vérification ne peut rien confirmer si les étapes d’origine ne sont plus écrites. Un rapport vague ne coûte pas simplement les cinq minutes de celui qui le signale : il coûte un aller-retour à chaque étape, et chaque aller-retour est une journée.

C’est là que passe le plus clair du temps. Pas dans la correction, dans le fait de redemander.

Notre guide du rapport de bogue donne la forme qui survit au tri : ce qui s’est passé, ce qui était attendu, les étapes et l’environnement. Demandez ces quatre éléments et la plupart des allers-retours cessent.

Des métriques qui trompent

Trois chiffres sont comptés parce qu’ils sont faciles à compter, et chacun mérite d’être lu attentivement.

• Nombre de défauts ouverts. Il monte quand les tests s’améliorent, ce qui est l’inverse de ce qu’il semble dire. Qu’il tombe à zéro veut plus souvent dire que les gens ont cessé de signaler que le logiciel s’est amélioré.
• Défauts par développeur. Récompense celui qui touche le moins de code. Ne le faites pas.
• Délai de fermeture. Utile, mais il mesure autant le processus que le travail : une semaine passée à attendre la réponse de celui qui a signalé compte comme une semaine de débogage.

Celle qui mérite d’être suivie à la place est le taux de réouverture : les défauts marqués corrigés qui sont revenus. C’est une mesure directe de ce que « corrigé » veut dire dans votre équipe et, contrairement aux autres, elle est difficile à truquer.

La version courte

Six états, une raison écrite pour tout ce qui est rejeté ou reporté, et une vérification faite par quelqu’un d’autre que celui qui a corrigé. La gravité dit à quel point c’est mauvais, la priorité à quel point c’est proche, et ce sont deux champs différents. Un tri à intervalles fixes plutôt que quand quelqu’un y pense. Et l’essentiel du temps gagné se gagne au début, dans le rapport : un défaut qui arrive complet traverse tout le processus sans que personne ait à poser une question.