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.

Mesures. Lorsque les exigences et les spécifications ne sont pas correctement établies, comment s'assurer que les tests peuvent néanmoins être conduits le plus efficacement possible?

Bernard Homès. Nombreux sont ceux d'entre nous qui se sont effectivement trouvés confrontés à des exigences ou des spécifications ambiguës, voire contradictoires. Ceci n'apparaît souvent que tardivement dans le cycle de développement, alors qu'une détection anticipée –par la mise en place de revues ou d'inspections– aurait pu les détecter. Beaucoup d'équipes de développement sont sensibilisées à l'intérêt de mettre en place des revues de documents (notamment des revues d'exigences, de spécifications, de code), mais relativement peu les mettent en œuvre avec un niveau de formalisme adapté. Cependant de nombreux auteurs reconnus tels que Tom Gilb, Capers Jones, Karl Wiegers ont démontré, statistiques à l'appui, une rentabilité des revues variant entre 40 et 85% selon le niveau de formalisme utilisé. Dans le cas d'analyses statiques de code, avec des outils appropriés, le résultat permet d'identifier les efforts de maintenance et de test à anticiper pour atteindre un niveau de rentabilité adéquat.

Les activités de revue devant être menées en parallèle avec les activités de développement, nous considérerons ici qu'elles se sont limitées à valider les exigences et les spécifications qui en ont découlé.

Mesures. Quels sont les meilleurs moyens de s'assurer de l'efficacité des tests et donc de détecter le plus grand nombre d'anomalies logicielles?

Bernard Homès. Selon de nombreuses sources concordantes, le taux d'efficacité (capacité de détection des anomalies) d'une technique de test plafonne à 30-40%. Ceci signifie que plusieurs techniques doivent être utilisées à la suite les unes des autres pour garantir le taux de détection d'anomalies souhaité. Il est évident que le taux de détection obtenu par l'utilisation d'une technique dépendra aussi du niveau de connaissance et de l'expérience des testeurs qui la mettront en œuvre, ainsi que du temps alloué aux testeurs pour mettre en œuvre ces techniques. Par conséquent, il sera nécessaire de recourir à plusieurs techniques de test différentes et complémentaires afin d'atteindre le taux de détection de 95% des anomalies que nous nous sommes fixé.

Mesures. Combien d'itérations sont-elles nécessaires pour atteindre le taux de détection fixe?

Bernard Homès. Chacune de ces techniques de test ne pouvant pas, comme on vient de le voir, atteindre seule la cible de 50% en terme d'efficacité, il faudra donc utiliser plusieurs techniques de test complémentaires afin d'atteindre un taux de détection de 50% par itération de test. L'itération de test étant l'ensemble des activités de test effectuées sur une version de logiciel fourni par les équipes de conception. Cette limitation de 50% est due en partie à l'impossibilité d'exécuter tous les tests sur le logiciel. Lors de la première itération nous trouverons donc 50% des anomalies, puis 25% de plus (soit 75% du nombre total d'anomalies initialement présentes dans le logiciel livré) lors de la seconde itération.

Les itérations suivantes trouveront respectivement : 87,5 %, 93,75 %, 96,87 % des anomalies, et ainsi de suite. Il en résultera une courbe de détection d'anomalies similaire à celle proposée par Weibull ( voir graphique ). Dans ce contexte, l'objectif que nous avions fixé (95 % de détection) n'est atteint qu'à partir de la cinquième itération (96,87 %) et que, si nous l'avions établi à 99 %, il aurait été nécessaire de prévoir au moins 7 itérations.

“ Il faut utiliser plusieurs techniques complémentaires ”

Mesures. Ce résultat peut-il être obtenu dans n'importe quelles conditions ou ce calcul est-il toutefois soumis à un certain nombre d'hypothèses?

Bernard Homès. Plusieurs hypothèses doivent effectivement prise en compte. La première hypothèse est que chaque nouvelle itération trouvera 50% des anomalies restantes. Ceci sous-entend que les techniques mises en œuvre antérieurement n'ont pas permis d'identifier ces anomalies, ou que le niveau de couverture de l'application ne permettait pas d'identifier ces anomalies.

La seconde hypothèse est que le logiciel est d'un niveau de maturité avancé lors de la livraison à l'équipe de test, et que les développeurs n'ajoutent pas de nouvelles fonctionnalités (et par la même occasion de nouvelles anomalies) lors de la correction d'anomalies identifiées précédemment. Si nous prenions ceci en compte, nous aurions dû accroître le nombre total d'anomalies, et nous nous rapprocherions de la courbe de Weibull, ce qui aurait eu pour effet d'augmenter le nombre d'itérations nécessaires pour atteindre nos objectifs de qualité.

La troisième hypothèse est que la durée du test lors de chaque itération est similaire, vu que la charge de travail est similaire. En effet, il est nécessaire de vérifier que tout ce qui fonctionnait précédemment continue à fonctionner (tests de non-régression), que tout ce qui a été identifié comme anomalie fonctionne lors de cette itération (retest ou test de confirmation), et que ce qui n'a pas encore été testé le soit effectivement. Si nous ne testons pas tout le logiciel –par exemple en faisant l'impasse sur ce qui fonctionnait précédemment– nous faisons une hypothèse risquée, basée sur une confiance aveugle en la qualité de nos développeurs, et leur capacité à éviter de faire des erreurs lors des corrections. Or ce sont les mêmes qui ont introduit les défauts dans le code initial.

La quatrième hypothèse est que les défauts sont corrigés à la fin de l'itération et ne réapparaissent pas ultérieurement. Ceci implique plusieurs choses: une gestion de configuration correcte évitant la propagation d'une anomalie entre plusieurs itérations; la capacité des équipes de développement à traiter toutes les anomalies pendant la durée de l'itération, sans introduire de délais dans le processus; enfin, que les livraisons de correctifs au sein des itérations soient limitées, de façon à ne pas introduire de retard par l'obligation de réinstaller et réinitialiser l'environnement de test (logiciel, données, etc.), d'effectuer du retest et du test de non-régression, car cela aura un impact sur la charge de travail –et les délais– sans améliorer la qualité du logiciel.

La cinquième hypothèse est que le traitement des défauts ne prend pas de temps significatif lors d'une itération. Ceci est évidemment faux, les activités de gestion des anomalies (comme par exemple la rédaction des fiches d'anomalies, le retest et les tests de non-régression, et les autres tâches de suivi de l'évolution des anomalies) prenant d'autant plus de temps qu'il y a d'anomalies identifiées lors d'une itération. La taille et la complexité du logiciel auront donc un impact sur le nombre d'anomalies et la charge de travail nécessaire pour les gérer.

Les courbes de détection d'anomalies sont exprimées en pourcentage, et si le nombre total de défauts dans l'application est important – en entrée des activités de test d'une itération– le nombre d'anomalies livrées aux utilisateurs sera plus élevé. Dans notre exemple initial (300 défauts), après 5 itérations près de 10 anomalies seront livrées, alors qu'il nous faudra 9 itérations pour tomber à 1 anomalie livrée. Les enseignements de ces courbes doivent donc être mis en rapport avec le nombre total –estimé– d'anomalies dans les logiciels.

Mesures. Est-il possible de réduire davantage le nombre d'anomalies?

Bernard Homès. Au travers des propos qui précèdent, nous avons vu qu'obtenir un niveau de qualité suffisant, se traduisant par une absence d'anomalies visibles par les utilisateurs, n'est pas facile à atteindre et requiert la mise en place d'un processus itératif de filtrage (test et correction) des anomalies après le premier codage. Ceci prend du temps, et nécessite un effort de test non négligeable.

Si nous souhaitons réduire le nombre d'anomalies livrées aux utilisateurs, il est indispensable, soit d'augmenter le nombre de phases de test pour une version de logiciel livré, soit d'accroître le taux d'efficacité des testeurs et des méthodes de test qu'ils mettent en œuvre, soit de réduire le nombre d'anomalies à l'entrée des phases de test (par exemple à l'aide de revues formelles des exigences, des spécifications, de l'architecture, du code, etc.).

Mesures. Quelles procédures, quelles approches ou encore quelles pratiques conduisent aux meilleurs résultats?

Bernard Homès. Penser que l'on peut réduire arbitrairement la durée ou le nombre d'itérations des tests est une illusion, car le taux d'efficacité des testeurs, tout comme la capacité de correction des développeurs, n'est pas extensible. Nous savons que les développements prennent souvent (pour ne pas dire toujours) plus de temps qu'initialement prévu, et que les dates de livraison aux clients sont moins flexibles que les dates de livraison aux équipes de test.

Par conséquent, une réduction des durées et du nombre d'itérations de test sera forcément contreproductive. Les courbes de détection d'anomalies (voir graphique) illustrent parfaitement l'impossibilité de réduire les tests sans réduire de concert le niveau de qualité des logiciels livrés.Parce que le test est de plus en plus considéré comme un vrai métier, l'augmentation du taux de détection des anomalies par une amélioration de la formation des testeurs devient possible. Cette approche est soutenue actuellement par les nombreuses initiatives du CFTL (fiches métier du test) et de l'ISTQB (syllabus niveau Fondation et niveau Avancé des testeurs, certifications de testeurs, etc.). Elle nécessite toutefois la formation des équipes de test et le temps nécessaire pour mettre ces formations en place, les pratiquer et atteindre un niveau de compétences dans leur utilisation.Enfin,la meilleure solution consiste à éviter de commencer les tests avec de trop nombreuses anomalies en réduisant leur nombre par une détection en amont,par exemple lors des phases d'analyse, de conception ou de codage. Ceci implique de former aussi les développeurs qui sont principalement en charge des tests unitaires, de composants et des tests d'intégration, et qui – malheureusement – n'ont des tests qu'une vision parcellaire (au mieux) ou une méconnaissance totale (au pire).

Cette approche requiert des activités d'amélioration de la qualité en amont du test, telles que les revues et inspections (avec un niveau de formalisme suffisant et dans des délais permettant de réellement prendre en compte les corrections), ainsi que l'utilisation d'outils d'analyse statique du code, de façon à identifier tôt les logiciels complexes ou difficiles à maintenir.

Une réduction de la taille des composants logiciels permettrait en outre de réduire le nombre d'anomalies dans chacun des composants, mais en contrepartie multiplierait le nombre de composants, sans réduire la complexité du logiciel.

“ Impossible de réduire les tests sans affecter la qualité logicielle ”

Mesures.Certains secteurs d'activités sont-ils plus sensibles à l'amélioration de la qualité logicielle?

Bernard Homès. L'actualité nous fait régulièrement part d'un nombre de rappels de véhicules pour des vices dont certains sont liés à des problèmes logiciels. L'industrie automobile n'est pas la seule à être confrontée à ce type de défaillances. Un autre secteur emblématique, celui de la téléphonie et notamment les opérateurs téléphoniques français, doit également y faire face. Sans oublier de nombreux autres cas qui ont fait la une de l'actualité tels que des factures envoyées à des clients avec des montants astronomiques ou une pompe à essence délivrant gratuitement son carburant. Mais, ces exemples ne sont que la partie émergée de l'iceberg, la majorité des entreprises souhaitant cacher les problèmes (défauts logiciels) qu'elles subissent.

Dans certains domaines tels que le spatial, l'aéronautique, le médical, le nucléaire, le ferroviaire, etc., un défaut logiciel ne peut être accepté car il peut entraîner des problèmes critiques. Des standards, des niveaux de couverture et des types de tests à exécuter sont donc imposés. Ceci implique l'utilisation de métriques et de mesures et conduit à une augmentation des coûts des tests. Comme la complexité des systèmes augmente, il est évident que la complexité et le nombre des tests vont eux aussi s'accroître.

Mesures.Les systèmes étant de plus en plus complexes, leurs logiciels sont souvent développés par plusieurs entités et intègrent des modules commerciaux sur étagère. Qui est alors responsable du test?

Bernard Homès. L'utilisation de composants logiciels commerciaux sur étagère (dits COTS) n'implique pas que les tests exécutés sur ces logiciels sont exhaustifs. Il est donc du ressort de l'intégrateur –de l'industriel qui utilisera ces composants– de s'assurer que le niveau de qualité est en rapport avec celui du produit qu'il vend. Si l'airbag de votre voiture se déclenche intempestivement, vers qui vous tournerez-vous?Vers le constructeur automobile, ou vers le soustraitant qui a conçu l'airbag, ou celui qui a développé le logiciel? Souvent ces sous-traitants sont sélectionnés sur un critère de prix, plutôt que sur un critère de qualité –ou d'exhaustivité– des tests exécutés. Ce critère devrait pourtant être pris en considération lors de la sélection de la meilleure offre.

Mesures. Quels autres conseils proposez-vous pour atteindre le niveau de qualité logicielle souhaitée?

Bernard Homès. Parce qu'admettre des objectifs intenables est la meilleure façon de s'assurer de ne pas les atteindre, il en ressort qu'il est nécessaire de fournir des estimations les plus correctes possibles, qu'il est primordial d'anticiper le nombre d'anomalies qu'il y aura dans un logiciel, qu'il est indispensable de mesurer le taux de détection d'anomalies par les testeurs pour mieux prévoir le nombre d'itérations à mettre en place afin d'atteindre le niveau de qualité souhaité.

Ceci nécessite des métriques ainsi qu'une analyse d'informations historiques sur les projets antérieurs. Dans le cas – trop fréquent – où nombre de ces données ne seraient pas disponibles, il sera bon de définir et mesurer les métriques nécessaires sur le projet actuel ; les conclusions que nous en tirerons ne pouvant alors s'appliquer que sur les projets futurs.

Voyons la réalité en face, des mesures d'amé-lioration de la qualité des logiciels existent, nos clients et utilisateurs sont en droit de les exiger, notre devoir est de les utiliser.