Les métriques QA se répartissent en deux catégories. Les premières mesurent de vrais résultats qualité (taux d'échappement des défauts, densité de défauts, couverture de tests). Les secondes mesurent l'activité sans signification (cas de test rédigés par sprint, bugs trouvés par cycle).

Les métriques qui comptent

Taux d'échappement des défauts

Définition : Pourcentage de bugs qui ont atteint la production par rapport aux bugs trouvés en test. 

Taux d'échappement = (Bugs trouvés en production / Total des bugs trouvés) × 100 %

Exemple : 20 bugs trouvés en test + 5 bugs trouvés en production = 25 au total. Taux d'échappement = 5/25 = 20 %. Pourquoi ça compte : C'est la métrique la plus proche de "à quel point interceptons-nous les bugs ?" Un taux d'échappement élevé signifie que le QA ne détecte pas les problèmes avant les utilisateurs. Objectif : En dessous de 10 %, c'est raisonnable. En dessous de 5 %, c'est solide.

Temps moyen de détection (MTTD)

Définition : Temps moyen entre l'introduction d'un bug et son signalement.

Un bug introduit dans un commit le lundi mais non trouvé avant l'exécution de régression du vendredi a un MTTD de 4 jours. Un bug trouvé par un test automatisé 5 minutes après le commit a un MTTD de 5 minutes.

Pourquoi ça compte : Un temps de détection plus court signifie une correction moins coûteuse. Un bug trouvé en CI coûte 10 fois moins cher à corriger qu'un trouvé en QA, 100 fois moins qu'un trouvé en production. Comment l'améliorer : Shift left. Plus de tests unitaires, des tests d'intégration automatisés et des tests à chaque commit déplacent tous la détection plus tôt.

Taux d'automatisation des tests

Définition : Pourcentage de cas de test qui sont automatisés. 

Taux d'automatisation = (Tests automatisés / Total des cas de test) × 100 %

Pourquoi ça compte : Les tests automatisés s'exécutent à chaque commit, trouvent les régressions immédiatement, et libèrent du temps QA pour les tests exploratoires. Mise en garde : Le taux brut d'automatisation peut induire en erreur. 90 % d'automatisation de tests triviaux est pire que 50 % d'automatisation des flux à fort risque. Mesurez l'automatisation des chemins critiques, pas seulement de tous les cas de test.

Couverture de tests

Trois types méritent d'être suivis. La couverture des exigences mesure quel pourcentage des exigences ont des tests correspondants. La couverture de code (principalement une métrique développeur, mais que le QA doit comprendre) suit le code exécuté par les tests. La couverture des risques vérifie si les zones à fort risque sont testées. Les lacunes de couverture sont là où les bugs se cachent sans être détectés. Une couverture à 100 % des exigences ne signifie pas que les cas limites sont couverts. Utilisez-la avec une évaluation des risques.

Densité de défauts

Définition : Nombre de bugs par unité de taille du logiciel. 

Densité de défauts = Total des défauts / Taille (kloc, story points, fonctionnalité)

Comparez la densité de défauts entre fonctionnalités, équipes ou sprints pour identifier où les problèmes de qualité sont concentrés. Si la fonctionnalité X a systématiquement 3 fois la densité de défauts des autres fonctionnalités, cherchez pourquoi : exigences floues, développement bâclé, code complexe ?

Taux d'exécution des tests

Définition : Cas de test planifiés exécutés par rapport au total planifié. 

Taux d'exécution = (Cas de test exécutés / Cas de test planifiés) × 100 %

Pourquoi ça compte : Un faible taux d'exécution avant une release est un signal de risque. Vous n'avez pas terminé votre test planifié.

Taux de tests flaky

Définition : Pourcentage de tests qui passent parfois et échouent parfois sans modification du code. 

Taux flaky = (Tests avec des résultats intermittents / Total des tests) × 100 %

Pourquoi ça compte : Les tests flaky détruisent la confiance de l'équipe dans la suite de tests. Quand la CI échoue, personne ne sait si c'est un vrai bug ou un test flaky. Les équipes commencent à ignorer les échecs. Puis les vrais bugs sont ignorés aussi. Objectif : En dessous de 2 %. Au-dessus, c'est une priorité à corriger.

Les métriques qui semblent bonnes mais induisent en erreur

Nombre de bugs par sprint

Le piège : Trouver plus de bugs ne signifie pas que le QA travaille plus dur. Le nombre de bugs dépend du nombre de fonctionnalités développées, de leur complexité et du risque pris. Un sprint avec de simples corrections de bugs aura toujours moins de bugs qu'un sprint avec de nouvelles fonctionnalités complexes. Mieux : Suivez le nombre de bugs avec la vélocité de développement et l'évaluation des risques.

Cas de test rédigés

Le piège : Rédiger 100 cas de test par sprint n'est pas intrinsèquement meilleur qu'en rédiger 50. 100 cas de test évidents qui testent ce qui fonctionne manifestement apporte moins de valeur que 50 cas limites soigneusement choisis qui trouvent vraiment des bugs. Mieux : Suivez la couverture des cas de test par rapport aux exigences, pas leur nombre brut.

Taux de réussite

Le piège : "95 % des tests passent" semble excellent. Mais ça peut signifier que vos tests sont trivialement faciles à passer, que vous avez supprimé les tests difficiles qui continuaient à échouer, ou que les échecs connus sont ignorés. Mieux : Suivez la tendance du taux de réussite dans le temps et investiguez pourquoi les tests en échec existent.

Suivre les métriques dans le temps

Les métriques ne deviennent utiles que quand vous les suivez dans le temps. Un instantané unique ne dit rien. Les tendances vous indiquent si les choses s'améliorent ou empirent.

Bons outils : tableaux de bord Jira pour les métriques de défauts, TestRail pour le suivi de l'exécution des cas de test, GitHub Actions ou Jenkins pour les métriques d'automatisation, Grafana pour des tableaux de bord personnalisés à partir des données CI.

Approche simple : suivi hebdomadaire dans un tableur.

| Semaine | Bugs trouvés | Bugs échappés | Taux automation | Taux flaky |

|---|---|---|---|---|

| S1 | 15 | 2 | 60 % | 8 % |

| S2 | 12 | 1 | 63 % | 6 % |

| S3 | 18 | 0 | 65 % | 5 % |

| S4 | 10 | 2 | 68 % | 4 % |

Tendances : automatisation en hausse, taux flaky en baisse, taux d'échappement faible.

Rapporter les métriques aux parties prenantes

Équipe technique (rétrospective de sprint) : nombre de tests flaky et tendance, progression du taux d'automatisation, amélioration du MTTD grâce aux ajouts de tests. Direction (mensuel) : taux d'échappement des défauts, bugs P1/P2 en production par rapport à la période précédente, couverture de tests des fonctionnalités critiques, temps économisé par l'automatisation par rapport au test manuel. Parties prenantes non techniques (trimestriel) : traduisez les chiffres en impact métier. "Nous avons évité X problèmes visibles par les clients ce trimestre." "Notre suite automatisée s'exécute en 15 minutes et détecte les régressions avant leur livraison." "Le taux d'échappement des défauts est passé de 25 % à 8 % en un an."

Démarrer un programme de métriques

N'essayez pas de tout suivre à la fois. Commencez avec deux ou trois.

Mois 1 : Suivre le taux d'échappement des défauts et le taux flaky. Établir une base de référence. Mois 2 à 3 : Ajouter le taux d'automatisation des tests. Commencer à viser la réduction des tests flaky. Mois 4+ : Ajouter le MTTD et la couverture des exigences. Revoir les tendances et fixer des objectifs d'amélioration.

L'objectif est l'amélioration, pas la perfection. Les métriques qui exposent les problèmes font leur travail.

Récapitulatif

| Métrique | Ce qu'elle mesure | Pourquoi elle compte |

|---|---|---|

| Taux d'échappement des défauts | Bugs atteignant la production | Efficacité qualité principale |

| MTTD | Vitesse de détection des bugs | Coût de correction des bugs |

| Taux d'automatisation | Maturité de la suite de tests | Vitesse et couverture de régression |

| Taux flaky | Fiabilité des tests | Confiance dans la suite |

| Densité de défauts | Concentration des bugs | Où concentrer l'effort qualité |

| Couverture de tests | Exigences testées | Identification des lacunes |

Les bonnes métriques répondent à : "progressons-nous ?" Si vos métriques ne montrent pas d'amélioration dans le temps, ce sont soit les mauvaises métriques, soit vous avez des problèmes de processus à adresser.

→ See also: Métriques QA qui Comptent Vraiment: Taux d'Échappement des Défauts, MTTD et Plus | Rapports de Tests en CI: Formats, Outils et Intégration | Devenir QA Lead: Responsabilités, Compétences et la Transition