Comprendre le temps vers la qualité
De nos jours, il existe de nombreux indicateurs pour suivre les progrès de l’assurance qualité (QA). La plupart sont très utiles, mais ils tendent tous à être unidimensionnels : ce sont des instantanés à un moment donné, ou une itération précise. Cela s’applique même aux métriques de taux et de tendance, qui sont pourtant cruciales, mais qui, là encore, ne sont que des instantanés.
Lorsque je travaillais chez Symantec, j’ai remarqué ceci :
De nombreux indicateurs étaient utilisés pour déterminer le *niveau* de qualité atteint (prétendument) à la date de livraison. Mais aucune métrique n’était recueillie, ni en cours de processus, ni rétrospectivement, pour mesurer le *coût* de l’atteinte de ce niveau de qualité.
En d’autres termes, nous ne nous préoccupions pas de la manière dont cette qualité avait été atteinte efficacement pendant la durée du projet.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Votre produit a peut-être été livré avec une qualité élevée, mais était-il nécessaire d’y consacrer autant de temps et d’efforts pour y parvenir ?
Il s’agit ici d’une question d’efficacité, et non, à proprement parler, d’une question de qualité, même si les deux sont très liées.
L’intersection entre qualité et efficacité
La qualité et l’efficacité se recoupent car l’une des principales raisons pour lesquelles les projets logiciels dépassent souvent largement le calendrier prévu (et cela survient souvent comme une surprise pendant la dernière phase du projet) est la mauvaise qualité du code. Pas seulement la qualité initiale du code, mais tout au long du projet.
Une autre raison, qui n’est en réalité qu’une conséquence inévitable d’une mauvaise qualité de code, ce sont les anomalies qui nécessitent plusieurs tentatives de correction, s’étalant sur plusieurs cycles de test ou sprints, avant que l’anomalie ne soit réellement corrigée. Si elle l’est un jour.
Ces itérations sans fin de correction, de test et d’échec rajoutent un nombre incalculable de semaines-personnes à pratiquement tous les projets logiciels.
Or, il est intéressant de noter que ce schéma d’échec n’est identifié par aucun autre indicateur de projet ou de qualité que j’ai observé. Car, comme mentionné plus haut, tous ces indicateurs sont des photos instantanées et passent donc à côté de ce phénomène.
J’ai alors pensé qu’il existait un moyen simple de capturer ce schéma d’échec. J’ai mis au point un indicateur que j’ai appelé « Time to Quality », ou TTQ.
Présentation d’un nouvel indicateur : Time To Quality (TTQ)
La mesure elle-même est très simple. Son principe est le suivant :
Pour chaque passage de test (selon la définition que vous en faites), il faut non seulement mesurer le nombre de tests réussis ou échoués, mais également le nombre de tests réussis du premier coup. Et combien en ont nécessité deux, trois ou davantage d’essais avant d’être enfin validés.
À titre d’exemple, si vous exécutez 20 tests et que 5 d’entre eux réussissent lors de la première tentative, votre ratio TTQ est de 25 %. Plus ce chiffre est élevé, mieux c’est. C’est un indicateur simple, calculable et facilement accessible de la qualité globale de votre code.
Ce métrique est un excellent indicateur de la qualité initiale du code.
Cela s’explique par le fait que plus le code est de qualité, moins vous aurez besoin de répéter un test avant qu’il ne réussisse. Et inversement. Ce métrique est bien plus précis que le simple comptage ou la tendance des anomalies.
TTQ est aussi un indicateur précieux pour le suivi des projets.
Par exemple, si lors du premier passage de test 70 % des tests sont réussis et 30 % échouent, on peut raisonnablement supposer que le projet reste dans les délais prévus. Mais si, par exemple, seulement 20 % des tests réussissent lors du premier passage, alors, pour le dire techniquement, « Ma fille, tu es mal barrée ! »
Parce que cela signifie qu’en réalité, vous n’avez pas vraiment effectué un premier passage de test réussi. Il faut donc réintégrer ce temps dans une passe ultérieure comme une dette de qualité.
