Qu'est-ce qu'un bon rapport de bug, et quelle est la différence entre gravité et priorité ?

Un bon rapport permet à quelqu'un d'autre de reproduire le problème sans rien vous demander : un titre précis, des étapes exactes depuis un état de départ connu, résultat attendu contre résultat obtenu, environnement et build, et des preuves comme une vidéo, des logs ou une trace réseau. La gravité est l'impact technique du défaut ; la priorité est le délai dans lequel il sera corrigé. Un bug cosmétique peut être de faible gravité et de haute priorité.

Mon test pour un rapport de bug, c'est de savoir si un développeur qui ne m'a jamais parlé peut le reproduire à partir du seul rapport. Le titre dit donc ce qui casse et où, précisément, pas quelque chose comme commande cassée. Puis les préconditions, c'est-à-dire l'état de départ exact et le type de compte, des étapes numérotées qu'on peut suivre au pied de la lettre, le résultat attendu, le résultat obtenu, et l'environnement avec le numéro de build, parce qu'un bug déposé contre la build de la semaine dernière gâche l'après-midi de tout le monde. Les preuves y sont à chaque fois : enregistrement d'écran, la requête et la réponse réseau, et les lignes de log pertinentes avec les horodatages. Sur gravité contre priorité, la gravité dit à quel point le système est cassé et la priorité dit dans quel délai on corrige, et elles sont fixées par des personnes différentes pour des raisons différentes. Un bug de corruption de données dans une fonctionnalité utilisée par deux personnes est de haute gravité et de basse priorité. Une faute qui écorche le nom de l'entreprise sur la page d'accueil est d'une gravité dérisoire et se corrige ce matin. Je m'assure de décrire l'impact avec justesse, combien d'utilisateurs, s'il existe un contournement, si de l'argent ou des données sont en jeu, puis je laisse le responsable produit fixer la priorité, parce que c'est sa décision.