Écrire un rapport de bug que les développeurs adorent

« Ça ne marche pas. » Trois mots, envoyés à 23 h avec une capture floue. Le lendemain, le développeur cherche une heure : quel téléphone ? Quel écran ? Quel compte ? Il ne voit rien, classe le ticket « impossible à reproduire »… et le bug part chez les utilisateurs.

Un bug que personne ne sait reproduire est un bug qui reste. Votre rapport est le seul pont entre ce que vous avez vu et ce que l’équipe peut corriger. Solide, il fait gagner des heures. Bancal, il fait perdre votre découverte.

À la fin de cet article, vous saurez écrire un rapport qu’un développeur reproduit en quelques minutes sans vous rappeler, signaler un problème d’utilisabilité, et vous aurez un modèle prêt à copier.

Qu’est-ce qu’un bon rapport de bug ?

Un rapport de bug, ou bug report, décrit un comportement observé qui ne correspond pas à ce qui était attendu. Le syllabus de l’ISTQB, la référence internationale de la formation des testeurs, lui fixe trois buts : donner à l’équipe de quoi corriger, suivre la qualité du produit, et améliorer la façon de travailler.

Un bon rapport passe un test simple : une personne qui n’a jamais vu le problème peut le reproduire avec votre texte seul, sans vous poser une question. Il respecte aussi trois règles :

• Un rapport, un problème. Deux bugs dans le même ticket, et l’un des deux sera oublié.
• Des faits, pas des hypothèses. « Le total reste à 3 500 FCFA » est un fait ; « la base de données ne se met pas à jour » est une supposition.
• Vérifier avant d’écrire. Reproduisez le problème une deuxième fois, et cherchez s’il n’a pas déjà été signalé.

Quels éléments doit contenir un rapport complet ?

Le tableau ci-dessous liste les éléments qu’un développeur attend, d’après le contenu type décrit par l’ISTQB. Votre outil (Jira, GitHub, formulaire de mission) remplit parfois seul l’identifiant et la date.

Le titre : où, quoi, dans quelle condition

Le titre est souvent lu seul, dans une longue liste. Une formule marche presque toujours : [écran ou fonction] + [ce qui se passe] + [condition qui le déclenche].

• Mauvais : « Bug paiement !!! »
• Bon : « Paiement : le montant reste l’ancien total après suppression d’un article du panier »

L’environnement : ce qui change tout

Un bug peut exister sur un téléphone à 2 Go de mémoire et disparaître sur un modèle récent. Notez le modèle, la version du système, la version de l’application (dans « À propos » ou dans les réglages du téléphone), le navigateur pour le web, le réseau, la langue et le type de compte. Ajoutez l’heure exacte : elle aide les développeurs à retrouver la requête dans les journaux du serveur.

Les étapes, l’attendu et l’obtenu

Partez d’un état connu (« application fermée puis relancée ») et numérotez une action par étape, avec les données utilisées : montant, produit, format du numéro. Ne sautez aucune action « évidente » : elle l’est pour vous, pas pour le lecteur.

Le résultat attendu ne vient pas de votre goût : il s’appuie sur la consigne de la mission, la spécification, un autre écran de la même app, ou le bon sens (« le total égale la somme des articles »). Citez cette source.

Comment apporter des preuves vraiment utiles ?

Une preuve bien choisie vaut dix lignes d’explication.

La capture d’écran. Prenez l’écran entier, avec la barre d’état (heure, réseau, batterie), et entourez la zone concernée avec l’éditeur photo du téléphone. Une capture recadrée sur trois mots ne dit plus où l’on se trouve.

La vidéo. Elle montre l’enchaînement, donc la cause. Lancez l’enregistrement avant la première étape et gardez-le sous une minute. Sur iPhone, l’enregistrement de l’écran se lance depuis le centre de contrôle. Sur Android, l’option « Afficher les appuis » (Show taps, le nom varie selon les marques) des options pour les développeurs dessine un point à chaque contact du doigt.

Les journaux. Sur Android, la commande de rapport de bug des options pour les développeurs (Take bug report) produit une archive avec les journaux du système et des applications. Sur un site web, ouvrez les outils de développement du navigateur (F12, ou Cmd + Option + I sur Mac) : les erreurs en rouge de l’onglet Console et les requêtes en échec de l’onglet Réseau sont de l’or pour un développeur.

Gravité ou priorité : quelle différence ?

Voici une échelle de gravité courante. Les noms et le nombre de niveaux changent d’une équipe à l’autre : utilisez toujours l’échelle de l’outil ou de la mission.

Gravité et priorité ne vont pas toujours ensemble. Le nom de l’entreprise mal orthographié sur l’écran d’accueil est peu grave, mais prioritaire : tout le monde le voit. Un plantage dans un export que presque personne n’utilise est grave, mais peut attendre la version suivante.

Mauvais rapport, bon rapport : un exemple réécrit

Voici un rapport tel qu’on en reçoit trop souvent, pour une application de livraison de repas :

Tout y est vrai, mais rien n’est utilisable : quel article, quel écran, quel prix, quel téléphone ? Le même problème, réécrit :

TITRE : Paiement - le montant reste l'ancien total après suppression
d'un article du panier

ENVIRONNEMENT
- Samsung Galaxy A03 Core, Android 11
- Application 2.4.1 (Play Store), compte de test de la mission
- Réseau 4G, reproduit aussi en Wi-Fi
- Le 14 octobre à 10 h 42 (heure de Douala)

PRÉCONDITIONS
- Connecté, panier vide

ÉTAPES POUR REPRODUIRE
1. Ajouter « Ndolé + plantain » (2 500 FCFA) au panier.
2. Ajouter « Jus de foléré » (1 000 FCFA) au panier.
3. Toucher « Commander » : l'écran Paiement affiche 3 500 FCFA.
4. Toucher la flèche Retour pour revenir au panier.
5. Supprimer « Jus de foléré » : le panier affiche 2 500 FCFA.
6. Toucher de nouveau « Commander ».

RÉSULTAT ATTENDU
L'écran Paiement affiche 2 500 FCFA, comme le panier.

RÉSULTAT OBTENU
L'écran Paiement affiche toujours 3 500 FCFA.
Après fermeture et relance de l'application, le bon montant revient.

FRÉQUENCE : 5 essais sur 5
GRAVITÉ PROPOSÉE : majeure (le client risque de payer un montant faux)
PREUVES : video-panier.mp4 (40 s), capture-paiement.png

Le développeur sait où regarder : l’écran Paiement garde une ancienne valeur après un retour arrière, et le contournement noté l’aide à cerner la cause.

Le modèle prêt à copier

Gardez ce modèle dans les notes de votre téléphone et remplissez-le pendant que le bug est sous vos yeux.

TITRE : [Écran ou fonction] - [ce qui se passe] - [condition]

ENVIRONNEMENT
- Appareil, système, navigateur (web) :
- Version de l'application ou adresse du site :
- Réseau (Wi-Fi, 4G, 3G), compte, langue :
- Date et heure exactes :

PRÉCONDITIONS
-

ÉTAPES POUR REPRODUIRE
1.
2.
3.

RÉSULTAT ATTENDU (et sa source)
-

RÉSULTAT OBTENU
-

FRÉQUENCE : toujours / X essais sur Y / une fois
GRAVITÉ PROPOSÉE :
PREUVES :
NOTES (contournement, autres essais) :

Sur GeekTest, chaque bug part dans un retour « Bug » séparé, avec sa gravité, et chaque idée d’amélioration dans un retour « Suggestion » : ce modèle s’y glisse tel quel.

Comment signaler un problème d’utilisabilité, et pas seulement un bug ?

Parfois, l’application fait exactement ce qui était prévu… et les gens n’y arrivent pas. C’est un problème d’utilisabilité : la facilité avec laquelle des utilisateurs donnés atteignent leur but, dans leur contexte réel. Pas un défaut au sens strict, mais souvent ce qui fait fuir les clients.

Un signalement d’utilisabilité suit sa propre structure :

1. Le but : ce que vous essayiez de faire, comme un vrai utilisateur.
2. L’observation : les faits (hésitation, erreur, retour en arrière, temps perdu).
3. L’impact : qui est gêné, à quelle fréquence, avec quel risque d’abandon.
4. Le repère : la règle de conception non respectée, par exemple une des heuristiques de Nielsen.
5. La preuve : capture ou vidéo.
6. Une piste, présentée comme une suggestion, jamais comme un ordre.

Pour juger la gravité d’un tel problème, le Nielsen Norman Group croise trois questions : combien de personnes le rencontrent, à quel point il les bloque, et s’il revient à chaque visite. Séparez aussi votre goût de l’observation : « je n’aime pas ce vert » n’est pas un signalement ; « le texte gris clair sur fond blanc se lit mal en plein soleil » en est un, qui touche à l’accessibilité.

Quelles erreurs font rejeter un rapport, et quel ton adopter ?

Les mêmes erreurs reviennent dans les rapports refusés ou laissés de côté :

• plusieurs problèmes dans un seul ticket, ou un doublon d’un bug déjà signalé ;
• ni version de l’application ni modèle de téléphone ;
• des étapes qui commencent au milieu du parcours ;
• une interprétation technique à la place de l’observation ;
• une vidéo de cinq minutes sans indication du moment utile.

Le ton compte autant que le fond. Le syllabus de l’ISTQB le rappelle : le testeur apporte souvent de mauvaises nouvelles, qu’il doit communiquer de façon constructive. Votre rapport décrit le produit, jamais la personne qui l’a construit. Le tableau ci-dessous montre comment transformer une phrase blessante en phrase utile.

Après l’envoi, restez disponible : répondez vite aux questions et, si l’équipe juge le comportement voulu, acceptez-le, quitte à le reformuler en suggestion. Quand la correction arrive, refaites les mêmes étapes : c’est le test de confirmation, que notre guide du smoke test, de la régression et de la recette remet en contexte.

Votre exercice pour aujourd’hui : rédigez avec le modèle un comportement qui vous agace dans une application du quotidien, puis donnez le texte à un ami, sans rien expliquer. S’il reproduit le problème du premier coup, votre rapport est prêt. Pour trouver ces comportements plus vite, lisez notre guide du test exploratoire.

Pour aller plus loin

• Syllabus ISTQB Niveau Fondation v4.0, en français (CFTL) (nouvel onglet) : la section 5.5 détaille la gestion des défauts et le contenu type d’un rapport de défaut.
• Glossaire ISTQB : la définition de la sévérité (nouvel onglet) : les définitions officielles de sévérité, priorité, défaut et défaillance, en français.
• Bug Writing Guidelines de Mozilla (nouvel onglet) (en anglais) : les conseils de rédaction du suivi de bugs public de Firefox, valables pour tout projet.
• Android Developers : capturer et lire un rapport de bug (nouvel onglet) (en anglais) : créer l’archive de journaux depuis le téléphone ou avec adb, et ce qu’elle contient.
• Assistance Apple : enregistrer l’écran de l’iPhone ou de l’iPad (nouvel onglet) : la marche à suivre pour filmer un bug sur iOS.
• Nielsen Norman Group : évaluer la gravité des problèmes d’utilisabilité (nouvel onglet) (en anglais) : l’échelle de 0 à 4 et les critères de fréquence, d’impact et de persistance.