Rapporter un bug efficace
Le gain du jour : écrire un rapport de bug qu’un développeur peut reproduire et corriger sans avoir besoin de revenir vers toi pour clarifier — et savoir attribuer correctement sévérité et priorité.
Pourquoi la plupart des bugs mal rapportés ne sont jamais corrigés
« L’app plante parfois quand j’ajoute un article » est un rapport quasiment inutile : aucune étape reproductible, aucun contexte, aucune preuve. Un développeur qui reçoit ça doit soit deviner, soit revenir vers le testeur — ce qui ralentit tout le cycle et, en pratique, fait souvent classer le bug en « non reproductible » et l’abandonner.
L’anatomie d’un bug report exploitable
- Titre — court, spécifique, actionnable : pas « bug sur le panier » mais « le panier affiche une quantité négative après suppression rapide d’un article ».
- Étapes de reproduction — numérotées, exhaustives, sans supposer de contexte implicite.
- Résultat observé — ce qui se passe réellement.
- Résultat attendu — ce qui devrait se passer (référence au cas de test ou à la spec si possible).
- Sévérité — l’impact technique/fonctionnel du bug.
- Priorité — l’urgence de le corriger, du point de vue métier.
- Environnement — appareil, OS, version d’app, langue, état réseau.
- Preuves — capture d’écran, enregistrement vidéo, logs. Sur mobile, un enregistrement d’écran (natif iOS/Android, ou un outil comme BrowserStack en test à distance) vaut souvent mille mots pour un bug visuel ou intermittent.
Deux axes trop souvent confondus. La sévérité mesure l’impact technique : un crash au démarrage est sévère, qu’un seul utilisateur en soit affecté ou un million. La priorité mesure l’urgence business : un défaut cosmétique mineur sur l’écran d’accueil (peu sévère) peut devenir prioritaire s’il est visible par 100 % des utilisateurs juste avant une campagne marketing majeure. Un bug peut être sévère et peu prioritaire (crash sur une fonctionnalité obsolète peu utilisée), ou peu sévère et très prioritaire.
Exemple concret
Titre : Le panier affiche une quantité négative après suppression rapide d'un article
Étapes de reproduction :
1. Ajouter un article au panier (quantité = 1)
2. Taper rapidement 3 fois sur le bouton « - » (diminuer quantité)
3. Observer le champ quantité
Résultat observé : la quantité affichée passe à -2
Résultat attendu : la quantité reste à 0 minimum, ou l'article est retiré du panier
au passage à 0
Sévérité : Haute (état incohérent visible, impact sur le calcul du total)
Priorité : Haute (parcours d'achat, fonctionnalité critique)
Environnement : iPhone 13, iOS 17.4, app v3.2.1, WiFi
Preuve : capture vidéo jointe (12 secondes)Un outil concret : le tracker de bugs
En pratique, ce rapport est saisi dans un outil comme JIRA, qui centralise le
cycle de vie du bug (Ouvert → En cours → À vérifier → Fermé), le relie au cas de test
d’origine (TC-042), et notifie automatiquement les personnes concernées. Pour une
équipe qui démarre avec un simple Google Sheet de suivi des cas de test (leçon 7),
la colonne « Bug lié » y renvoie l’ID JIRA correspondant — les deux outils
communiquent par référence croisée plutôt que par duplication d’information.
Vérifie ta compréhension
Un bug cosmétique mineur (une icône légèrement décalée) apparaît sur l'écran d'accueil juste avant le lancement d'une grande campagne publicitaire. Comment le qualifier ?
Pourquoi « l'app plante parfois quand j'ajoute un article » est-il un mauvais rapport de bug ?
À toi de jouer
Trouve un bug réel dans une app que tu utilises et rédige un rapport complet selon la structure de cette leçon, avec sévérité et priorité justifiées séparément.
Enregistre une courte vidéo (via l’enregistreur d’écran natif de ton téléphone) montrant les étapes de reproduction de ce bug.
🗂 Fiche de référence associée : Glossaire QA mobile — antisèche.