Un rapport de bug est un outil de communication ainsi qu'un enregistrement de défauts. Un bon rapport permet de gagner du temps : les développeurs peuvent reproduire le problème, les responsables comprennent son impact et QA peut suivre le correctif et les risques associés.
Ce que contient habituellement un rapport
- →Un titre clair identifiant le problème.
- →Environnement et conditions préalables pertinentes.
- →Étapes de reproduction.
- →Résultats réels et attendus.
- →Preuve : captures d'écran, vidéo, journaux, traces réseau, charges utiles ou traces de pile.
Qu'est-ce qui fait un rapport solide
- →Le problème est facile à comprendre et à reproduire.
- →Les faits se distinguent des interprétations.
- →L’impact sur l’utilisateur, l’entreprise ou le système est expliqué.
- →Les détails non pertinents n’obscurcissent pas les décisions.
Erreurs courantes
- →Un titre vague tel que « le bouton ne fonctionne pas ».
- →Résultats attendus manquants ou trop abstraits.
- →Étapes qui omettent des conditions essentielles et ne peuvent pas reproduire le défaut.
- →Priorité et gravité basées sur l’émotion plutôt que sur le risque.
Conseils pratiques
Écrivez pour quelqu'un qui ne connaît pas votre contexte de test. Plus vite ils pourront déterminer ce qui a échoué, comment le reproduire et pourquoi c’est important, meilleur sera le rapport.
Exemple concret : un rapport de défaut reproductible
Cet exemple pédagogique est fictif : il ne décrit pas un défaut observé dans un produit réel. Supposons que l’exigence REG-04 autorise un pseudonyme de 3 à 12 lettres ASCII, bornes incluses. Le build de démonstration refuse à tort les pseudonymes de exactement 3 lettres. Un vrai rapport doit toujours s’appuyer sur une exigence approuvée et une observation réelle.
ID : DEMO-17
Titre : L’inscription refuse un pseudonyme de 3 lettres autorisé par REG-04
Environnement : build fictif de formation 1.0 ; navigateur et système : relever les versions réelles
Préconditions : formulaire d’inscription ouvert ; tous les autres champs contiennent des données valides
Étapes :
1. Saisir abc dans le champ Nickname.
2. Déplacer le focus vers le champ suivant.
3. Envoyer le formulaire.
Résultat attendu : aucune erreur de longueur du pseudonyme ; l’inscription peut continuer.
Résultat observé dans ce scénario fictif : "Minimum 4 characters" ; l’envoi est bloqué.
Reproductibilité : 3 tentatives sur 3 après réinitialisation du formulaire.
Impact : un pseudonyme autorisé ne peut pas être enregistré.
Preuves à recueillir : capture d’écran, ID du build, horodatage et requête/réponse sans données sensibles.
Exigence : REG-04.
Sévérité / priorité : à convenir selon les définitions de l’équipe et le contexte de livraison.Le titre précise l’action, l’entrée et l’écart observé, sans supposer que le backend est responsable. Si seule l’UI a été observée, indiquez-le ; inspectez la requête avant d’affirmer une cause côté serveur. Les captures et journaux ci-dessus sont des preuves à recueillir, pas des pièces jointes fournies par ce guide.
Modèle de rapport copiable
Titre :
Build / environnement :
Exigence ou source du comportement attendu :
Préconditions et données de test :
Étapes :
Résultat attendu :
Résultat observé :
Reproductibilité :
Impact utilisateur :
Preuves sans données sensibles :
Ticket / cas de test associé :Avant d'envoyer, demandez à un coéquipier de suivre uniquement les étapes enregistrées. Supprimez les informations d’identification et les données personnelles des preuves. Un rapport qui ne peut pas encore être reproduit peut quand même être utile : indiquer ce qui est connu, à quelle fréquence cela s’est produit et quelles informations manquent.