Gestion des anomalies
Un bug bien documenté est à moitié corrigé. La qualité d'un rapport d'anomalie est l'indicateur le plus visible du sérieux d'une équipe QA - et le levier le plus rapide pour améliorer la collaboration avec les développeurs.
01 - Les différences
Erreur, défaut, défaillance : la différence
Erreur
Action humaine qui produit un résultat incorrect. Exemple : un développeur se trompe dans une condition.
Défaut (bug/anomalie)
Imperfection dans le code, la documentation ou les données. C'est la conséquence d'une erreur.
Défaillance
Manifestation observable du défaut à l'exécution. Tous les défauts ne provoquent pas une défaillance.
02 - Reproduire
Avant de rapporter : reproduire & isoler
Avant de déclarer une anomalie, il faut s'assurer de sa présence dans des conditions précises et reproductibles.
01
Reproduire au moins 2 fois pour exclure un faux positif ou un flake (test qui donne parfois un résultat différent sans qu’il y ait eu de modification du code).
02
Tester sur un autre environnement (navigateur, OS, compte) pour cerner le périmètre.​
03
Réduire au scénario minimal qui déclenche le défaut.
04
Vérifier qu'aucun ticket similaire n'existe déjà.
05
Collecter les preuves au moment où le bug se produit (capture, logs, requêtes).
03 - Rédiger correctement un rapport
Comment rédiger un bon rapport
Une trame de rapport de test réussie :
-
Comment structurer un rapport de test efficace
-
Les éléments clés d’un rapport de test
Titre
Synthétique : composant + action + symptôme.
Ex : "Panier : le total reste à 0€ après ajout d'un article en promo".
Environnement
OS, navigateur, version, build, device, résolution, langue...
Pré-requis
Compte utilisé, rôle, données nécessaires, état initial (panier vide, session connectée…).
Étapes
Numérotées, sans ambiguïté.
Une action = une étape.
Résultat attendu
Ce que disent les spécifications, la maquette, ou le bon sens utilisateur.
Résultat obtenu
Ce que fait réellement le système. Citer les messages exacts.
Preuves
Capture annotée pour aider la reproduction : vidéo courte, logs, requête réseau, ID de session.
Traçabilité
Lien vers la user story, l'exigence ou le ticket parent.
04 - Exemple rapport d'anomalie
Avant / après : un même bug, deux rapports
A éviter
Bouton qui marche pas
​
Quand je clique sur le bouton ça fait rien, c'est urgent. Je ne peux pas passer mes cas de test.
​
Environnement : iPhone
​
​
A viser
[Checkout] Le bouton "Payer" reste inactif après saisie d'une CB valide. ​
​
Environnement : Chrome 124 / macOS 14.4 / build prod 2026.05.18
Pré-requis :
-
Compte client standard connecté
-
Un article dans le panier (nom article)
Étapes :
-
Se connecter à un compte client
-
Ajouter un produit au panier
-
Valider les écrans jusqu'au paiement
-
Sur la page de paiement, saisir une CB avec des données valides
-
Cliquer sur « Payer »
Résultat attendu : Le bouton "Payer" est actif et permet au client d'effectuer le paiement.
Résultat obtenu : Le bouton "Payer" reste inactif malgré l'ensemble des champs obligatoires correctement renseignés.
Sévérité : S1 — Bloquant (paiements impossibles)
Priorité : P1 — Immédiat (bloque les paiements).
Preuves : capture annotée. Traçabilité : numUS.
P1 - Immédiat
À corriger dans l'heure / la journée. Hotfix en production.
P2 - Élevé
À embarquer dans la prochaine release.
P3 - Normal
À planifier dans les prochains sprints.
P4 - Basse
À traiter quand l'équipe a de la marge.
A retenir :
-
sévérité = testeur (factuel), priorité = produit (arbitrage). Les deux peuvent diverger.
Échelle de sévérité
Échelle de priorité
05 - Sévérité vs priorité
Sévérité vs priorité
La sévérité mesure l'impact technique ; la priorité mesure l'urgence métier. Un crash sur une fonctionnalité utilisée 2 fois par an peut être très sévère mais peu prioritaire.
S1 - Bloquant
Empêche toute utilisation du système ou d'une fonction critique. Pas de contournement
​
Impossible de se connecter à son compte , paiement KO pour tous les clients (perte de chiffre d'affaires).
S2 - Majeur
Fonctionnalité importante dégradée. Contournement complexe ou pénible.
​
Le filtre produit ignore la catégorie "Viandes".
S3 - Mineur
Comportement incorrect mais sans impact métier majeur.
​
Un libellé est mal traduit et affiche la langue d'origine.
S4 - Cosmétique
Défaut visuel ou rédactionnel, n'empêche pas les actions.
​
Pixel mal aligné, faute de frappe dans une infobulle...
06 - La vie d'une anomalie
Cycle de vie d'une anomalie
01
Nouveau
L'anomalie est créée avec toutes les informations de reproduction. État par défaut à la déclaration.
02
Triage
Sévérité, priorité, composant et version sont validés. L'anomalie entre dans le backlog produit.​
03
Assigné
Un développeur prend en charge l'investigation.​
04
En cours
Analyse, reproduction côté dev, recherche de cause racine, correction.
05
Résolu
Le correctif est livré sur un environnement testable. Le ticket revient ensuite au testeur.​
06
Vérifié
Le testeur rejoue le scénario (test de confirmation) et lance une régression ciblée.
07
Fermé
L'anomalie est clôturée. Si elle réapparaît : réouverture + analyse de la régression.​
08
Rejeté
« Pas un bug », « Fonctionnalité prévue », « Impossible à reproduire »… La décision est tracée, pas perdue.
« Ça marche pas » : titre sans contexte, le ticket sera rejeté.​
Plusieurs bugs dans un seul ticket : ingérable à suivre, doit être découper.​
Pas de version / build : impossible de savoir si le bug est encore d'actualité.​
Captures sans annotation : le développeur ne sait pas où regarder.
Pré-requis implicites (" l faut être admin et avoir 2 commandes ") non précisés.​
Sévérité gonflée pour faire passer en priorité : casse la confiance dans les niveaux.​
Pas de test de confirmation : le ticket est fermé alors que le bug persiste.
07 - Les pièges
Les pièges classiques
08 - A retenir
En bref :
-
Un bon rapport d’anomalie permet à une autre personne de reproduire le problème sans interprétation, juste en suivant les étapes.
-
Avant de déclarer un bug, il faut reproduire, isoler et rassembler des preuves (captures, logs, requêtes…) pour éviter les faux positifs et les tickets flous.
-
La sévérité mesure l’impact technique ou métier du défaut, la priorité mesure l’urgence de traitement ; les deux axes peuvent diverger.
-
Un même bug peut donner un mauvais ticket ou un excellent ticket : la différence se joue dans le titre, les prérequis, les étapes, le résultat attendu/obtenu et les preuves.
-
Une gestion d’anomalies saine repose autant sur la qualité de la communication entre QA, dev et produit que sur l’outil utilisé.