01 — Les différences
Erreur, défaut, défaillance : la différence
Erreur
Action humaine qui produit un résultat incorrect. Exemple : une personne qui code 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.
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.
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 de finaliser 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 l'ensemble de la clientèle.
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.Sur mobile, balayez l'écran 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é
L'équipe de développement 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 à l'équipe QA.
Vérifié
La personne chargée du test 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 : l'équipe de développement 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.
À 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.
Une personne qui développe 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é ?
La personne chargée du test rejoue le scénario après correction et lance une régression ciblée. À quel statut du cycle de vie cela correspond-il ?
Rejoignez Le Labo QA gratuitement
Quiz d'entraînement, exercices pratiques et sauvegarde automatique de votre progression sur l'ensemble des parcours.
Bienvenue dans Le Labo QA
Votre session est active. Retrouvez l'ensemble de votre progression, reprenez vos quiz et consultez votre tableau de bord personnel.
À 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