Calculateur de métriques QA : DRE, fuite, taux de réussite et densité de défauts
Entrez vos comptes de défauts et de tests et obtenez les cinq métriques qu'un lead QA est censé connaître sur le bout des doigts — chacune avec une interprétation plutôt qu'un chiffre nu.
Six entrées, cinq métriques, gradées par couleur avec une interprétation chacune. Remplissez ce que vous avez ; le reste est sauté.
Ouvrir l'outil — gratuit, sans inscriptionCe que fait cet outil
Six entrées, cinq sorties. Vous entrez les défauts trouvés pendant les tests, les défauts trouvés en production, les tests exécutés, les tests réussis, et optionnellement un chiffre de taille avec une unité (KLOC, points de fonction, modules ou story points). Il calcule l'efficacité d'élimination des défauts, la fuite de défauts, le taux de réussite, le nombre d'échecs, et la densité de défauts. Tout ce que vous laissez vide est sauté, et chaque résultat est gradé par couleur avec une phrase expliquant ce que le chiffre vous dit.
Ce que chaque métrique signifie vraiment
L'efficacité d'élimination des défauts (DRE) est la part de tous les défauts connus que votre process a attrapés avant les utilisateurs. 85 internes et 7 échappés donnent 92,4 pour cent. À 90 ou plus, votre process attrape la grande majorité avant la release — c'est le chiffre à citer en entretien. Entre 75 et 90, environ un défaut sur quatre ou cinq atteint la production, et la question utile est quelle couche les rate. Sous 75, la cause habituelle est une couverture mince aux couches API et intégration, pas un manque de tests UI.
La fuite de défauts est le miroir du DRE — la part que vos utilisateurs ont trouvée à la place de vos tests. Dix pour cent ou moins est sain. La valeur seule compte bien moins que la tendance sur les releases.
Le taux de réussite est la métrique la moins fiable ici, dans les deux sens. Sous 85 pour cent, séparez les vrais échecs des échecs instables avant de le rapporter ; une suite instable rend le chiffre dénué de sens. Au-dessus de 95 pour cent, soupçonnez le problème inverse — une suite qui passe toujours peut avoir des assertions faibles ou des tests incapables d'échouer.
La densité de défauts est le nombre de défauts par unité de taille. Son vrai usage est comparatif : lancez-la par module et l'anomalie vous dit où concentrer l'effort ensuite. Comparer votre densité à un chiffre du secteur est proche de l'inutile, car les unités de taille ne sont pas standardisées entre équipes.
À propos de la couverture
La couverture est la métrique dont les examinateurs parlent le plus et la plus souvent mal utilisée. La couverture de lignes vous dit quel code a été exécuté, pas quel comportement a été vérifié — un test sans assertions produit quand même de la couverture. La couverture des exigences (quels critères d'acceptation ont au moins un test) est plus honnête, et aucune n'a sa place dans un rapport sans les données de défauts échappés à côté. Couverture plus DRE dit quelque chose. La couverture seule dit seulement que du code a tourné.
Erreurs courantes
Citer un chiffre que vous ne pouvez pas interpréter. En entretien, c'est pire que de ne pas en citer. Chaque résultat ici vient avec une interprétation pour cette raison.
Rapporter une seule métrique isolée. Le DRE sans un taux d'instabilité, ou la couverture sans données de défauts échappés, est un chiffre de vanité. Ce qui gagne des points seniors, c'est de nommer quelles métriques vous suivez ensemble et quelle décision chacune changerait.
Compter seulement ce qui est pratique. Si les défauts de production sont loggés dans un autre système et discrètement exclus, le DRE gonfle. Convenez de la règle de comptage avant que le chiffre entre dans une présentation.
Utilisez une release ou un sprint par calcul. Mélanger les périodes produit un chiffre qui ne décrit rien. Tout le calcul tourne dans votre navigateur ; rien de ce que vous entrez n'est envoyé où que ce soit.
Questions fréquentes
Comment calcule-t-on l'efficacité d'élimination des défauts ?
Divisez les défauts trouvés pendant les tests par le total des défauts trouvés pendant les tests plus les défauts trouvés en production, puis multipliez par 100. Si vous en avez attrapé 85 et que les utilisateurs en ont trouvé 7, le DRE est 85 ÷ 92 × 100, soit 92,4 pour cent. Au-dessus de 90 pour cent est considéré comme solide.
Qu'est-ce qu'une bonne densité de défauts ?
Cela dépend entièrement de votre unité de taille et de votre seuil de sévérité, donc traitez les cibles absolues avec méfiance. Cet outil signale sous 1 par unité comme bon et sous 3 comme acceptable. La densité est surtout utile pour comparer des modules au sein d'une même base de code, pas entre équipes.
Quelle est la différence entre la fuite de défauts et le DRE ?
Deux vues des mêmes données. Le DRE est le pourcentage de défauts attrapés avant la release ; la fuite est le pourcentage qui a échappé aux utilisateurs. Ils font toujours 100 pour cent à eux deux. Les équipes rapportent généralement le DRE vers le haut et suivent la fuite en interne.
Pourquoi un taux de réussite très élevé est-il un signal d'alerte ?
Parce qu'une suite qui n'échoue jamais est peut-être incapable d'échouer. Des assertions faibles, des tests qui passent quel que soit le comportement, et des tests sautés-mais-comptés produisent tous d'excellents taux de réussite. Appariez le chiffre au nombre de vrais défauts que la suite a attrapés.