Plusieurs Techniques De Test Sont Nécessaires Pour Détecter Un MaximUm D'anomalies

Le 01/01/2013 à 0:00  

Mesures. Les tests de logiciels ne sont souvent pas si poussés qu'ils pourraient l'être par manque de temps. Comment dans un tel contexte définir un niveau de qualité suffisant?

Bernard Homès. Le niveau de qualité peut se définir selon divers critères, d'une part selon le risque associé au logiciel (et à une défaillance potentielle de celui-ci), d'autre part selon l'effort que l'on va consentir pour limiter ce risque (combien de test nous allons envisager – l'effort de test – ainsi que les techniques de test que nous allons utiliser et leurs efficacités respectives (le nombre d'itérations nécessaires pour arriver au niveau de qualité requis). Je vous propose de nous pencher ici sur ce dernier point. Combien d'itérations de test faut-il mettre en œuvre pour assurer un niveau de qualité “suffisant” ? Une telle question implique de définir ce que nous considérons comme un “niveau de qualité suffisant”, et de nous rendre compte que ce niveau peut ne pas être celui qui est demandé par nos clients ou utilisateurs. Pour ce faire, deux aspects doivent être pris en considération : d'une part, le pourcentage d'anomalies livrées par rapport au nombre total d'anomalies contenues initialement dans le logiciel à l'entrée de la phase de test, et d'autre part, le nombre d'anomalies que l'on souhaite laisser passer à la phase suivante, généralement la livraison.

Il sera aussi nécessaire d'évaluer les impacts économiques (en termes de coûts et de charges de travail) des choix qui seront faits. Nous savons intuitivement que l'option “zéro défaut” est une solution non atteignable. Il en résulte donc que le pourcentage d'anomalies identifiées par les filtres successifs du test de logiciel sera inférieur à 100 %. Pour atteindre un niveau de qualité suffisant, le pourcentage d'anomalies identifiées doit être important, proche de 95 % voire de 99 %. Il est évident que certains équipements ne peuvent se permettre de tomber en panne, et donc nécessitent plus de 99% de bon fonctionnement (par exemple les téléphones portables, les airbags de voitures, etc.) et impliqueront un niveau de qualité – et un nombre d'itérations – plus important.

Il est nécessaire d'évaluer les impacts économiques des choix qui sont faits

Plus le pourcentage sera important, plus il faudra tester et plus les coûts et charges de test seront importants. Prenons pour cible un taux d'identification des anomalies de 95 %, ce qui sous-entend que les utilisateurs pourront être potentiellement confrontés à 5% d'anomalies qui subsisteront dans le logiciel. Bien entendu, si un tel pourcentage peut paraître élevé, il faudra reprendre le raisonnement avec une cible différente.

Partons de la fourchette basse de 3 anomalies par unité de mesure (100 lignes de code ou 1 point de fonction) et estimons que notre produit logiciel comportera environ 10 000 lignes de code ou 100 points de fonction. (nous pouvons considérer que le taux initial est de cinq anomalies, mais que les développeurs en identifient deux lors de leurs activités de test unitaires et d'intégration; ces pourcentages correspondent à ceux fréquemment trouvés dans l'industrie, tels que décrits par Capers Jones et Olivier Bonsignour dans leur ouvrage The Economics of Software Quality ). Nous aurons donc un nombre potentiel de 300 anomalies restant dans le logiciel à l'issue de la phase de conception. L'atteinte de notre objectif de 95% de détection sous-entend que nous livrerons 15 anomalies en pâture aux utilisateurs.

La lecture de cet article est payante.
Pour le lire abonnez-vous ou connectez vous.

Dans la même rubrique

Copy link
Powered by Social Snap