Rédiger un rapport de bug exploitable

Objectif

Le rapport contient tout ce dont la partie destinataire — développeuse, exploitant ou agent — a besoin pour reproduire et situer le défaut dès la première tentative, et rien qu'elle doive d'abord écarter.

Prérequis

Le défaut a été observé personnellement au moins une fois ; l'environnement est connu (version, système d'exploitation, navigateur ou environnement d'exécution, paramètres qui s'écartent du standard).

Étapes

1. Chercher au préalable : le rapport existe-t-il déjà ? Si oui, le compléter plutôt que d'en ouvrir un second.
2. Formuler le titre comme une phrase indiquant le symptôme et la condition : « L'export échoue avec UnicodeEncodeError sur les noms de fichiers contenant des trémas », et non « L'export est cassé ».
3. Indiquer l'environnement : version du produit ou commit, système d'exploitation, environnement d'exécution ou navigateur avec sa version, paramètres pertinents. Tout ce qui s'écarte du standard a sa place ici.
4. Lister les étapes de reproduction sous forme de liste numérotée, chacune avec exactement une action, en partant d'un état initial connu (installation neuve, fichier d'exemple en pièce jointe). La ligne directrice de Mozilla (citée) exige précisément cette séparation entre « Steps to Reproduce », « Expected Results » et « Actual Results ».
5. Le résultat attendu et le résultat réel en une phrase chacun ; le message d'erreur littéral et complet (la pile d'appels sous forme de bloc de code, pas de capture d'écran), un extrait de journal avec horodatage.
6. Réduire autant que le temps le permet : retirer des étapes et des données jusqu'à ce que le défaut disparaisse, puis annuler la dernière suppression. Le modèle Stack Overflow « minimal, complete, reproducible » sert de référence ; parfois, la cause devient visible dès la réduction.
7. Fréquence et impact : toujours ou occasionnellement, depuis quand, combien de personnes sont concernées, s'il existe un contournement.
8. Les hypothèses sur la cause dans une section à part « Hypothèse », clairement séparée des observations. Aucun jugement, aucun reproche.
9. Relire avant l'envoi comme si l'on ne connaissait pas le projet : manque-t-il un fichier, une commande, une version ?

Résultat attendu

La personne destinataire reproduit le défaut sans avoir à poser de question, et peut le prioriser ; le rapport devient plus tard un test de non-régression, puisque les étapes et le résultat attendu sont déjà formulés.

Limites et base de vérification

Certains défauts ne peuvent pas être reproduits de manière déterministe (comportement temporel, charge, concurrence) ; dans ce cas, la fréquence, les moments et les conditions d'observation doivent figurer dans le rapport. Les données confidentielles dans les pièces jointes et les journaux doivent être retirées au préalable. La structure suit les lignes directrices citées ; aucune affirmation sur les délais de traitement n'est formulée.