Qualité logicielle : comment Decathlon Technology la mesure

Comment se faire une idée globale de l’efficacité d’un processus de gestion de la qualité logicielle ? En définissant des « macro-indicateurs ». Par exemple, les taux de détection et de résolution des problèmes. C’est ce qu’a choisi Decathlon Technology.

Au vu des cycles de delivery variables, il a été décidé d’effectuer les mesures à intervalle mensuel.

Le taux de détection est déterminé pour chaque phase de test (cf. premier tableau ci-dessous), mais le résultat est exploité de manière simplifiée (deuxième tableau). Il se calcule avec la formule suivante :

(Problèmes détectés en préprod / Nombre total de problèmes) x 100

Les défauts identifiés lors des tests manuels sont pris en compte dans le calcul (ils sont stockés dans l’ALM, comme ceux signalés en prod). Il est en revanche plus difficile de récupérer les données liées aux tests automatisés. Si bien que Decathlon Technology les a exclues.

Mêmes fondements pour le taux de résolution… et mêmes limites en matière de collecte d’informations. Certains défauts n’arrivent jamais dans l’ALM, ou du moins ne s’y matérialisent pas comme tels. C’est le cas, entre autres, lorsqu’un CI/CD déclenche plusieurs niveaux de test après un commit et que le dev corrige le problème avant le dernier test.

Dans l’exemple qu’il donne (une application e-commerce), Decathlon Technology a fixé, pour l’un et l’autre indicateur, la « zone rouge » à 80 %. Pendant la période considérée, le taux de détection a été inférieur sur un mois. Raison avancée : la prise de congé de l’ingénieur qualité, dont les tâches, déléguées à l’équipe, n’ont pas été complètement réalisées.

Illustration principale © Parradee – Adobe Stock