01 — Les différences
Erreur, défaut, défaillance : la différence
Erreur
Action humaine qui produit un résultat incorrect. Exemple : un•e développeur•se 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, OSOperating System, 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. Cochez-les au fur et à mesure que vous les intégrez à vos rapports.
Rapport complet ! Un ticket avec ces neuf éléments donne toutes les chances à votre équipe de corriger vite.
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•à la client•e 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 d'écran + export console joints.
Traçabilité : US-482 — Paiement par carte.
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 client•es.
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. HotfixCorrectif publié en urgence, en dehors du cycle de livraison habituel 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
Utilisez les flèches pour suivre les 8 étapes.
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 produitListe priorisée de tout ce qui reste à faire sur le produit (fonctionnalités, corrections, dette technique).
Assigné
Un•e développeur•se 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•à la testeur•se.
Vérifié
Le•la testeur•se 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.
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 produitListe priorisée de tout ce qui reste à faire sur le produit (fonctionnalités, corrections, dette technique).
Assigné
Un•e développeur•se 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•à la testeur•se.
Vérifié
Le•la testeur•se 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•la développeur•se 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
Ce qu'il faut retenir
Un rapport reproductible
Un bon rapport d'anomalie permet à une autre personne de reproduire le problème sans interprétation, juste en suivant les étapes.
Reproduire avant de déclarer
Avant de déclarer un bug, il faut reproduire, isoler et rassembler des preuves pour éviter les faux positifs et les tickets flous.
Sévérité et priorité, deux axes
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.
Ce qui fait un bon ticket
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.
La communication avant l'outil
Une gestion d'anomalies saine repose autant sur la qualité de la communication entre QA, dev et produit que sur l'outil utilisé.
Mise en pratique
Testez votre compréhension
Une sélection de questions basées sur ce que vous venez de lire.
Un•e développeur•se se trompe dans une condition et écrit du code incorrect. Comment appelle-t-on cette action humaine ?
Avant de déclarer un bug, combien de fois faut-il au minimum le reproduire pour exclure un flake ?
Quel élément d'un rapport d'anomalie doit citer les messages exacts affichés par le système ?
Un bug empêche tout paiement pour l'ensemble des clients, sans aucun contournement possible. Quelle sévérité lui attribuer ?
Un bug très sévère touche une fonctionnalité utilisée deux fois par an seulement. Que peut-on en déduire sur sa priorité ?
Le•la testeur•se rejoue le scénario après correction et lance une régression ciblée. À quel statut du cycle de vie cela correspond-il ?
À savoir
La Minute QA est une aide à la compréhension, pas une formation professionnelle : certains points ne peuvent pas être couverts ici. Pensez à suivre une formation certifiante et à consulter le syllabus officiel ISTQB pour une préparation complète.
Pour aller plus loin