Métriques KPI en QA

J'ai parlé dans plusieurs conférences et l'une des questions qui revient sans cesse lorsque j'aborde l'automatisation de l'assurance qualité concerne les métriques, plus précisément les indicateurs clés de performance (KPI) en assurance qualité. Tout le monde s'intéresse au type de métriques à considérer lors de l'évaluation de l'automatisation.

Quel type de métriques considérez-vous dans votre automatisation ? Discutons un peu des métriques KPI en assurance qualité.

En général, les métriques KPI de la qualité logicielle sont définies comme suit :

      • le nombre de défauts,
      • le taux d'impact (blast rate),
      • ou le nombre de cas de test échoués,
      • la couverture du code

Bien que ces informations fournissent des données importantes, toutes liées à l'activité de test, mon approche des KPI qualité dépend vraiment des questions suivantes :

    • Qui cherche les données ?
    • Qui regarde les données ?
    • À quoi les données vont-elles servir ?
    • Comment êtes-vous capable de prendre une décision à partir des données ?

En fonction des réponses à chacune de ces questions, je crée un tableau de bord pour rendre les données accessibles à tous dans l'organisation.

En parlant du "Qui" ?

D'après mon expérience personnelle, il y a trois groupes de personnes intéressés par les données sur la qualité logicielle pour déterminer la santé de l'application testée.

Le premier groupe, généralement le testeur, est celui qui effectue le travail de test : le testeur QA, l'ingénieur QA et l'ingénieur qualité.

Ils veulent simplement déterminer où ils en sont pendant le test afin de voir la progression et d'avoir un bon niveau de confiance concernant les tests.

Le deuxième groupe, généralement la direction intermédiaire, le gestionnaire direct des membres de l'équipe (responsable qualité logicielle, responsable développement, responsable DevOps, responsable des opérations) et toute personne qui soutient l'application et gère une équipe qui la soutient.

Ce deuxième groupe est plus intéressé par la progression de leur application en cours de test.

Enfin, le troisième groupe, la haute direction (les cadres dirigeants, le VP de la technologie, le VP produit, le CTO, le CIO, et le CISSO), est celui qui a vraiment besoin de voir les données à un niveau élevé, une vue d'ensemble.

Ce troisième groupe a besoin de savoir :

Comment se porte l'application ? Est-elle saine ? Puis-je dormir tranquille en sachant que mon application est sans bug ? Que rien ne va se passer en production,

surtout en cette période de fêtes ? Quelles sont les performances de mon application ?

Chacun de ces groupes mentionnés a des intérêts différents dans l'application. Ils ont des intérêts différents dans la qualité de l'application.

Ils ont également des intérêts différents dans les données qu'ils consultent.

Vous ne pouvez donc pas mélanger toutes les données et les leur donner telles quelles.

Vous devez vous assurer qu'à chaque niveau, vous fournissez un type de données vraiment utile et utilisable pour eux. Évidemment, si vous êtes le VP produit et que vous voulez plonger et vraiment examiner les bugs, vous êtes libre de le faire, ou si vous êtes un responsable développement et que vous voulez consulter le rapport de bugs, vous êtes également libre de le faire. C'est ainsi que j'essaie généralement de structurer mes métriques KPI qualité. J'aime aussi envisager une approche différente et promouvoir ce qui suit dans le cadre de vos métriques KPI qualité :

    • Meilleure visibilité
    • Transparence claire des données
    • Responsabilité directe
    • Guide pour l'amélioration continue

Pour chaque membre de l'audience, voici les métriques KPI QA possibles à considérer et le seuil d'évaluation :

 Pour le membre de l'équipe QA, envisagez de créer un tableau de bord de notation interne

      • Défauts actifs (nouveaux, ouverts ou corrigés) – tendance à la baisse(new, open or fixed) — trending low
      • Cas de test créés : Nombre de cas de test créés – Seuil devrait être de 1-1 par rapport au nombre de user stories ou 1-2: Number of test cases created – Threshold should be 1-1 to the number of user’s stories or 1-2
      • Exigences couvertes: Pourcentage de cas de test liés aux exigences – Seuil 80-100%
      • Défauts corrigés par jour / par semaine : À quelle vitesse l'équipe de développement corrige-t-elle les bugs ? fixed per day /per week: How fast is development fixing bug
      • Exigences couvertes: Nombre de cas de test réussis pour une exigence
      • Passed Tests: 80% threshold
      • Défauts rejetés : Pas plus de 5%:  No more than 5%
      • Exigences examinées:  Seuil de 100%
      • Défauts critiques:  Ne devrait pas dépasser 10

Pour le responsable d'équipe, les métriques devraient fournir la progression actuelle, donc considérez les métriques KPI suivantes :

      • #Nombre de user stories
      • #Nombre de user stories réussies
      • % de tests réussis
      • #Nombre de cas de test
      • #Nombre de cas de test réussis
      • #Nombre de cas de test échoués
      • #Nombre de cas de test non exécutés
      • Métriques des défauts
      • #Défauts ouverts
      • #Défauts fermés

      Pour l'équipe de direction, les métriques devraient permettre une décision rapide en un coup d'œil, donc considérez les métriques KPI suivantes :

      • 80 % des cas de test RÉUSSIS
      • % de user stories RÉUSSIES
      • Nombre de bugs P1 et P2 P1 and P2 bugs
      • Bugs échappés en production
      • Santé de la qualité du produit (rouge, jaune ou vert) (red, yellow or green)

Nous définissons également la santé de la qualité du produit ; j'ai défini un cadre de KPI pour déterminer la qualité de votre produit en utilisant les données suivantes et les seuils d'évaluation :

% de cas de test réussis

% de bugs échappés (bugs trouvés en production)

% Passed % de user stories réussies (taux de réussite par rapport aux stories) Stories (Pass Rate to stories Ratios).

% DE CAS DE TEST RÉUSSIS > 80 % – VERT EXCELLENT – < 10 % – VERT EXCELLENT

% DE CAS DE TEST RÉUSSIS < 80 – 50 % – JAUNE SatisfaisantYELLOW Satisfactory

% DE CAS DE TEST RÉUSSIS < 50 % – ROUGE Insatisfaisant RED Unsatisfactory

% de bugs échappés = # bugs échappés / # bugs fonctionnels

% de bugs échappés < 10 % – < 10 % – VERT EXCELLENT

% de bugs échappés > 10 -30 % – JAUNE – Satisfaisant

% de bugs échappés > 30 % – ROUGE – Insatisfaisant

En résumé, il est important de déterminer à qui vous livrez ces KPI afin de prendre la meilleure décision pour votre équipe. Essentiellement, pour déterminer la qualité et vous donner ce haut niveau de confiance que le logiciel a la meilleure qualité.

Commentez ci-dessous et dites-moi comment vous déterminez les KPI dans votre organisation ou quel type de défis vous rencontrez en termes de métriques KPI.