Gestion des anomalies
Une anomalie bien documentée est à moitié corrigée. 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.
Reproduire deux fois
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).
Changer d'environnement
Tester sur un autre environnement (navigateur, OS, compte) pour cerner le périmètre.
Réduire au minimal
Réduire au scénario minimal qui déclenche le défaut.
Vérifier les doublons
Vérifier qu'aucun ticket similaire n'existe déjà.
Collecter les preuves
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 tient en neuf éléments.
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.
Sévérité & priorité
Deux axes distincts. Justifier brièvement.
Traçabilité
Lien vers la user story, l'exigence ou le ticket parent.
04 — Exemple
Avant / après : un même bug, deux rapports
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
[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
É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)
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 deux fois par an peut être très sévère mais peu prioritaire.
Échelle de sévérité
S1 — Bloquant
Empêche toute utilisation du système ou d'une fonction critique. Pas de contournement. Ex : impossible de se connecter, paiement KO pour tous les clients.
S2 — Majeur
Fonctionnalité importante dégradée. Contournement complexe ou pénible. Ex : le filtre produit ignore la catégorie "Viandes".
S3 — Mineur
Comportement incorrect mais sans impact métier majeur. Ex : un libellé est mal traduit.
S4 — Cosmétique
Défaut visuel ou rédactionnel, n'empêche pas les actions. Ex : pixel mal aligné, faute de frappe.
Échelle de priorité
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.
06 — La vie d'une anomalie
Cycle de vie d'une anomalie
Nouveau
L'anomalie est créée avec toutes les informations de reproduction. État par défaut à la déclaration.
Triage
Sévérité, priorité, composant et version sont validés. Entre dans le backlog produit.
Assigné
Un développeur prend en charge l'investigation.
En cours
Analyse, reproduction côté dev, recherche de cause racine, correction.
Résolu
Le correctif est livré sur un environnement testable. Retour au testeur.
Vérifié
Le testeur rejoue le scénario (test de confirmation) et lance une régression ciblée.
Fermé
L'anomalie est au statut terminé. Si elle réapparaît : réouverture + analyse de régression.
Rejeté
"Pas un bug", "Fonctionnalité prévue", "Impossible à reproduire"… La décision est tracée, pas perdue.
07 — Les pièges
Les pièges classiques
"Ça marche pas" : titre sans contexte, le ticket sera rejeté.
Plusieurs bugs dans un seul ticket : ingérable à suivre, doit être découpé.
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 ("Il 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.
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 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é.
Pour aller plus loin