Le cycle de vie d'un bug couvre sept états : Nouveau, Assigné, En cours, En revue, Corrigé, Vérifié et Fermé. La plupart des régressions qui atteignent la production ne viennent pas d'oublis de test, mais de passations ratées entre ces états.

Les états standard et qui les possède

Chaque outil de suivi de bugs a ses propres étiquettes, mais les états sous-jacents sont universels. Savoir qui est responsable à chaque étape vous indique quand agir et quand attendre.

Nouveau : c'est le moment où vous soumettez le ticket. Rien n'a encore eu lieu. Le bug existe sur le papier, mais personne ne s'est engagé à le corriger. Votre travail ici est de rendre le rapport irréprochable : titre clair, étapes de reproduction exactes, résultat attendu versus résultat observé, sévérité, pièces jointes. Un bug "Nouveau" mal rédigé va stagner dans le purgatoire du triage parce que la personne qui le prend en charge ne peut pas le reproduire. Assigné signifie qu'un membre de l'équipe de développement possède le ticket. Pas qu'il l'ait regardé. Pas qu'il accepte que c'est un bug. Simplement qu'un nom y est associé. C'est l'état où les bugs vieillissent. On y reviendra. En cours signifie qu'un travail actif est en marche. Un développeur est en train de reproduire, d'investiguer ou d'écrire un correctif. En tant que QA, votre rôle ici est d'être disponible : si le développeur a des questions sur l'environnement de reproduction ou les cas limites, répondez vite. Les délais ici alourdissent le sprint. En revue signifie que le correctif est écrit et attend une revue de code ou une approbation. Certaines équipes combinent cet état avec un état "Prêt pour QA" qui indique que la build est disponible pour vérification. Comprenez quel workflow votre équipe utilise, parce que la distinction compte pour votre planification de sprint. Corrigé (ou "Prêt pour les tests") est la passation qui vous revient. Le développeur pense que le problème est résolu. C'est votre tour. Vérifiez en suivant exactement les étapes de reproduction initiales. N'improvisez pas un nouveau chemin de test. Confirmez d'abord que le scénario spécifique soumis est résolu, puis élargissez aux cas connexes. Vérifié signifie que vous avez confirmé que le correctif fonctionne comme décrit. Le défaut original a disparu. Vous avez vérifié les chemins de régression évidents. Cet état est votre signature. Fermé signifie que le bug vérifié est accepté et terminé. Dans la plupart des équipes, c'est soit le QA lead, soit le scrum master qui le fait, ou cela arrive automatiquement à la clôture du sprint. Un bug ne devrait jamais passer de Corrigé à Fermé sans passer par Vérifié. Sauter cette étape, c'est comment les régressions arrivent en production.

L'état Rejeté signifie que l'équipe a décidé que le comportement signalé est correct. Soit le résultat attendu dans le rapport était incorrect, soit le comportement est intentionnel, soit le reporter a mal compris l'exigence. Rejeté ne signifie pas que vous avez été négligent. C'est un résultat légitime. Documentez pourquoi il a été rejeté pour que les futurs testeurs ne soumettent pas le même ticket.

Différé signifie que le bug est réel et reconnu, mais qu'il ne sera pas corrigé dans ce sprint ou cette release. Il va en backlog. S'il est un jour corrigé dépend de la qualité de votre argumentation. Ne sera pas corrigé est un Différé permanent. L'équipe a décidé que ce défaut ne vaut pas l'effort. Parfois c'est le bon choix. Parfois non. Votre réponse détermine si ça deviendra un problème plus tard.

"Ne sera pas corrigé" et Différé : argumenter sans perdre

Voici un scénario réel. Vous soumettez un bug : "Sur la page de paiement, l'application d'un code de réduction après avoir sélectionné un mode de livraison remet la sélection de livraison à l'option par défaut." Le PM le triage et le marque Différé. Commentaire : "Faible impact, cas limite, pas assez d'utilisateurs concernés."

C'est là que la plupart des ingénieurs QA l'acceptent silencieusement ou argumentent émotionnellement. Ni l'un ni l'autre n'est efficace.

La meilleure approche consiste à recadrer la conversation autour des données et des parcours utilisateurs, pas de votre opinion personnelle. Demandez : combien de sessions de paiement par semaine incluent un code de réduction ? Vos analytics montrent-ils des pics d'abandon à cette étape ? La remise à zéro de la livraison cause-t-elle des erreurs d'adresse ?

Si vous n'avez pas ces données, dites-le et demandez qui peut les extraire. "J'aimerais comprendre la fréquence réelle avant de fermer ça. Peut-on extraire les données du tunnel de paiement sur les 30 derniers jours ?" C'est une demande raisonnable, pas un affrontement.

Si le PM veut quand même différer après avoir vu les données, documentez explicitement le risque dans le ticket. Écrivez : "Risque accepté : les utilisateurs appliquant des codes de réduction peuvent choisir par inadvertance un mauvais mode de livraison. Impact : potentielles erreurs de commande." Puis fermez-le. Vous avez fait votre travail. Si le problème s'intensifie après la release, il y a une trace claire que le risque a été soulevé et documenté.

Pour les bugs "Ne sera pas corrigé" qui impliquent l'intégrité des données ou la sécurité des utilisateurs, ajoutez toujours la déclaration de risque avant de fermer. Une note de risque d'une ligne vous protège, vous et l'équipe produit, si le problème ressurgit après une release.

Rouvrir des bugs sans créer de tensions

Un bug revient. Vous l'avez vérifié il y a deux semaines, il est en état Fermé, et maintenant le même symptôme apparaît en production. Vous devez le rouvrir, mais le développeur qui l'a corrigé va le remarquer, et personne n'aime voir son travail remis en question.

La règle est simple : rouvrez uniquement quand vous pouvez démontrer que le scénario original échoue à nouveau. Pas "quelque chose de similaire", pas "pourrait être lié". Les étapes de reproduction originales exactes, même environnement, même résultat.

Quand vous rouvrez, ajoutez un commentaire avant de changer l'état. Incluez : la date de réouverture, une nouvelle capture d'écran ou un enregistrement, et les étapes de reproduction exactes que vous avez exécutées, même si elles sont identiques à l'original. Précisez aussi si vous voyez le même symptôme ou une nouvelle variation. Si c'est une nouvelle variation sur le même composant, c'est un bug différent, pas une réouverture.

Supposons que vous ayez vérifié que le bug remise-réinitialise-livraison était corrigé dans la v2.8.1. Dans la v2.8.3, après la livraison d'une nouvelle fonctionnalité autour du tunnel de paiement, le bug est de retour. Vous le rouvrez, joignez un enregistrement, et notez : "Régression introduite dans la v2.8.3. Correctif présent vérifié dans la build v2.8.1, plus présent dans la build actuelle. Réouverture avec nouvel enregistrement."

Ce cadrage fait deux choses. Il reconnaît que le correctif original était valide. Il pointe vers une nouvelle régression plutôt que de laisser entendre que le développeur n'a pas bien corrigé la première fois. Cette distinction compte pour la relation de travail.

Bugs en doublon : identification et fusion élégante

Sur tout produit actif, plusieurs testeurs peuvent soumettre le même bug indépendamment, surtout autour de fonctionnalités qui viennent de sortir. Identifier les doublons tôt économise du temps de triage et évite une duplication des efforts de développement.

Avant de soumettre un nouveau bug, recherchez le symptôme dans votre outil. Cherchez d'abord par composant (paiement, connexion, upload), puis par mots-clés du message d'erreur ou du comportement. Si vous travaillez dans Jira, utilisez le panneau "Problèmes similaires" : il recherche automatiquement lors de la création d'un ticket.

Si vous trouvez un doublon après avoir soumis votre ticket, marquez le vôtre comme doublon de l'original (pas l'inverse, sauf si le vôtre est clairement plus détaillé). Ajoutez un commentaire : "Marqué comme doublon de PROJ-144. Même chemin de reproduction, même symptôme. J'ajoute mes captures d'écran au ticket original au cas où elles aident."

Puis allez sur le ticket original et ajoutez réellement la valeur de votre doublon. Peut-être que votre version a une vidéo plus propre ou une version de navigateur différente qui le reproduit. Cette information est utile même si votre ticket est fermé comme doublon.

Une chose à éviter : fusionner des bugs qui semblent identiques mais ne le sont pas. Si deux tickets ont le même message d'erreur mais des déclencheurs différents, ce peuvent être deux défauts distincts. Vérifiez la cause racine avant de fusionner. Un développeur qui corrige un bug sur la base d'un rapport fusionné et rate le second déclencheur ne sera pas content de le découvrir en production.

Vieillissement des bugs : que faire quand "Assigné" ne veut rien dire

Vous avez soumis un bug. Il est trié, assigné à un développeur, puis rien ne se passe pendant trois sprints. La revue de sprint arrive et passe, sans mention. Le ticket reste en "Assigné" comme un fossile.

C'est l'une des frustrations QA les plus courantes, et la bonne réponse est la visibilité, pas le harcèlement.

D'abord, regardez le bug vous-même. La priorité est-elle exacte ? Bloque-t-il encore quelque chose ? Si le contexte a changé et que le bug est moins pertinent, ajustez la priorité et ajoutez un commentaire. Un bug basse priorité qui stagne trois sprints est moins alarmant qu'un bug priorité moyenne.

Si la priorité est exacte et que le bug compte encore, soulevez-le explicitement lors de la revue de sprint. Pas comme une plainte, mais comme un point de risque. "Nous avons PROJ-188 en Assigné depuis trois sprints. Il affecte la fonctionnalité d'export CSV que nos utilisateurs entreprise signalent fréquemment. Je veux le mentionner pour le prochain sprint avant que ça devienne une escalade client."

La plupart des bugs vieillissants meurent parce que personne ne les a soulevés à nouveau. Vos réunions de revue de sprint et d'affinage du backlog existent précisément pour ça.

N'allez jamais directement voir un développeur pour demander pourquoi un bug n'a pas été corrigé. Ça crée des frictions et contourne le processus d'équipe. Soulevez les bugs vieillissants au niveau de l'équipe lors des cérémonies de sprint.

Si le bug ne devrait vraiment pas être corrigé dans la feuille de route actuelle, demandez qu'il soit formellement Différé avec une raison documentée. Un Différé honnête vaut mieux qu'un ticket Assigné zombifié : il donne à l'équipe un signal clair et évite les fausses impressions sur le nombre de bugs ouverts.

Jira vs Linear vs GitHub Issues

La logique de workflow décrite s'applique partout, mais les outils dans lesquels vous travaillez ont des différences significatives dans la façon dont ils gèrent les transitions d'état.

Jira reste la norme dans les équipes mid-size et enterprise. Les états de bugs dans Jira sont entièrement personnalisables, ce qui signifie que chaque équipe utilise un sous-ensemble différent des états décrits. Votre première semaine dans une nouvelle équipe utilisant Jira devrait inclure la compréhension exacte de ce que leurs états de workflow signifient. Ne supposez pas qu'"En cours" signifie qu'un développeur travaille activement. Dans certains setups Jira, ça signifie "reconnu mais pas encore commencé". Consultez la documentation du workflow ou demandez directement. Linear est devenu standard dans la plupart des startups early-stage et growth-stage. Il utilise un modèle d'états plus simple : Pas de statut, Backlog, À faire, En cours, En revue, Terminé, Annulé. L'état "Vérifié" dédié n'existe pas par défaut ; la vérification QA se fait soit dans "En revue", soit les équipes ajoutent un état personnalisé. Si vous rejoignez une équipe Linear, vérifiez si elle a une étape de vérification QA dans le workflow. Si ce n'est pas le cas, proposez-en une. Un ticket passant de "En revue" à "Terminé" sans qu'un testeur valide est un pattern qui finit par livrer des correctifs non vérifiés. GitHub Issues est courant sur les produits open-source et les outils pour développeurs. Son modèle d'états natif est simplement Ouvert et Fermé, avec des labels pour tout le reste. La plupart des équipes qui font un QA structuré sur GitHub Issues utilisent des labels comme status: ready for QA ou status: verified. Des milestones servent à suivre le périmètre des releases. Le problème ici : GitHub Issues n'a pas de workflow imposé ; la discipline est entièrement manuelle. Dans une équipe qui manque de cette discipline, les bugs passent d'Ouvert à Fermé sans aucune étape de vérification.

Quelle que soit la situation : comprenez le workflow réel de votre équipe, pas ce que l'outil supporte par défaut. Les états du cycle de vie existent indépendamment des étiquettes que votre outil utilise.

Métriques : les chiffres qui indiquent si le processus fonctionne

Suivre les états des bugs individuellement est utile. Suivre les patterns sur l'ensemble des bugs vous dit si votre processus qualité est sain.

Le taux d'échappement des défauts mesure le pourcentage de bugs trouvés en production par rapport aux bugs trouvés avant la release. Si votre équipe trouve 30% des bugs après la release, le processus de test ne détecte pas assez avant que le logiciel soit livré. La formule : (bugs trouvés après release) / (total des bugs trouvés) × 100. Un taux sain pour la plupart des équipes est inférieur à 15%. S'il est supérieur, regardez où dans le cycle de développement les bugs sont introduits et où s'arrête la couverture de tests. Le temps moyen de résolution (MTTR) mesure le temps moyen entre la soumission d'un bug et sa clôture. Un MTTR en hausse signale l'un de ces trois problèmes. L'équipe est sous-staffée par rapport au volume, les bugs sont soumis avec une qualité insuffisante (triage plus long), ou des composants spécifiques génèrent une densité de défauts disproportionnée. Suivez le MTTR par composant pour trouver les points chauds. Le rapport de vieillissement des bugs ouverts est exactement ce que son nom indique : une vue de tous les bugs ouverts triés par ancienneté, regroupés par état. La version utile segmente par état. Un entassement dans "Nouveau" signifie que le triage est en retard. Un entassement dans "Assigné" signifie que les développeurs ne prennent pas les bugs en charge. Un entassement dans "Corrigé" signifie que le QA ne vérifie pas assez vite. Chaque état raconte une histoire différente sur où se trouve le goulot d'étranglement.

Ces trois métriques ensemble donnent une image raisonnablement complète de la santé du cycle de vie des bugs. Calculez-les mensuellement, pas seulement en fin de cycle de release.

Comment appliquer ça dès maintenant

Ouvrez votre outil de suivi et listez tous les tickets qui vous sont assignés ou que vous avez soumis qui ne sont pas en Fermé ou Ne sera pas corrigé. Pour chacun : est-il dans le bon état ? La priorité est-elle encore exacte compte tenu de ce que vous savez du sprint en cours ? Y a-t-il des tickets qui stagnent dans le même état depuis plus de deux sprints sans commentaire ?

Pour chaque ticket vieillissant, ajoutez un commentaire d'une ligne aujourd'hui. Soit une vérification de statut si vous en avez besoin ("Toujours pertinent : la fonctionnalité d'export est toujours dans le périmètre, à soulever lors de la prochaine revue de sprint"), soit une demande explicite de Différer si ce n'est plus pertinent ("Le contexte a changé depuis la soumission : cet écran a été supprimé dans la v2.9. Recommandation de fermeture.").

Ce seul passage sur vos bugs ouverts fait trois choses : il libère votre charge mentale, il donne à l'équipe des informations précises sur ce qui est réellement ouvert. Et il montre que vous gérez activement la qualité, pas que vous soumettez des tickets et passez à autre chose.

Le cycle de vie d'un bug n'est pas de la bureaucratie. C'est le mécanisme par lequel un constat devient un correctif. Chaque transition d'état est une passation, et chaque passation a besoin de quelqu'un qui y prête attention. C'est le travail.

→ See also: L'Anatomie d'un Rapport de Bug que les Développeurs Corrigent Vraiment | Severity vs Priority: La Compétence de Triage qui Fait Progresser les Junior QA | Comment Écrire un Cas de Test: Format, Exemples et Erreurs Courantes