En 2002, le National Institute of Standards and Technology (NIST) a publié un rapport détaillant l'impact économique des tests logiciels inadéquats (Rapport NIST, 2002). Le rapport concluait que :
« … les coûts annuels nationaux d’une infrastructure inadéquate pour les tests de logiciels sont estimés entre 22,2 et 59,5 milliards de dollars. »
Le rapport du NIST a également souligné que les pratiques en matière de tests de logiciels étaient cruellement insuffisantes.
Sept ans plus tard, Wong et al., dans un rapport de l'IEEE Reliability Society (Wong et al., 2009), ont examiné 15 pannes logicielles largement médiatisées, dont plusieurs ont entraîné des pertes de vies humaines, et ont conclu que :
« … de meilleures procédures et pratiques de test doivent être mises en œuvre, et cela est particulièrement vrai pour les logiciels liés aux systèmes critiques pour la sécurité. »
Dans un article plus récent, Wong et al. ont examiné une série de défaillances logicielles dans plusieurs secteurs (Wong et al., 2017) et ont fait une remarque plutôt inquiétante :
« … la triste vérité est que les logiciels sont loin d’être exempts de défauts et que des sommes importantes sont dépensées chaque année pour réparer ou maintenir les logiciels (défectueux). »
L'article a analysé les pannes logicielles sur une période de 30 ans, de 1985 à 2015 ; a identifié la nature des bugs logiciels qui ont précipité les pannes, ainsi que d'autres facteurs contributifs, tels que les erreurs d'utilisateur ; et a classé les pannes en deux catégories : celles qui ont été fatales (entraînant des pertes de vies humaines) et celles qui n'ont pas été fatales mais ont entraîné des pertes économiques substantielles. Les pannes fatales comprenaient l'incident de Therac-25 en 1985, où au moins six patients ont reçu des surdoses de radiations, ainsi que les accidents d'aviation civile entre 1995 et 1997, où plus de 650 personnes ont perdu la vie. Il incluait également l'incident d'Ebola en 2014, où une panne du logiciel des dossiers médicaux électroniques a entraîné un mauvais diagnostic d'un patient infecté par Ebola, entraînant un décès ultérieur. Les pannes non fatales comprenaient une panne logicielle d'une centrale nucléaire, qui a entraîné une perte de 2 millions de dollars, ainsi que la panne logicielle d'Ariane 5, qui a entraîné une perte de 7 milliards de dollars. Dans leur conclusion, les auteurs ont fait l’observation suivante :
« … l’omniprésence des logiciels intégrés dans les infrastructures publiques, les systèmes de transport, les produits de consommation et bien plus encore nous laisse incrédules quant au fait qu’une personne ayant travaillé sur des systèmes logiciels complexes puisse croire qu’il est possible de construire de tels systèmes sans faille… »
Malheureusement, malgré ces comptes-rendus éclairants sur les types de systèmes logiciels dont nous dépendons de plus en plus, un point essentiel manque à l’esprit dans ces discussions : la plupart des pannes logicielles ne sont ni détectées ni signalées. Dans certains cas, la panne est subtile, voire intermittente, et passe donc facilement inaperçue. Par exemple, une application de statistique peut présenter des statistiques mal calculées. Ces statistiques mal calculées sont des pannes, mais elles peuvent ne pas être immédiatement apparentes, en particulier pour un non-expert. Néanmoins, de telles pannes peuvent conduire à des décisions incorrectes ou sous-optimales et peuvent donc avoir de lourdes conséquences.
Il est évident que l’écriture de logiciels, quelle que soit la sophistication des environnements de développement intégrés utilisés, la sophistication des méthodes de programmation ou les compétences des programmeurs, est un art imparfait qui entraînera des bogues. Cette réalité signifie que la découverte de ces bogues avant la sortie du logiciel dépend de la rigueur des tests logiciels. Comme l’indiquent le NIST et Wong et al., ne pas le faire peut avoir des conséquences importantes. Barry Boehm, une figure emblématique de la communauté de l’ingénierie logicielle, a souligné dans son article fondateur sur l’économie de l’ingénierie logicielle (Boehm, 1984), que le coût de la recherche et de la correction d’un bogue après le déploiement du logiciel est généralement au moins 100 fois supérieur à celui de l’identification et de la correction du bogue avant le déploiement.
Dans ce contexte, les méthodes de test de logiciels sont-elles tout simplement inadéquates ? Je dirais que ce n’est pas le cas. En fait, la recherche sur les tests de logiciels est un domaine de recherche solide depuis plus de 50 ans. En 2014, Orso et Rothermel ont écrit sur les progrès substantiels réalisés dans le développement de méthodes de test de logiciels au cours des 15 années précédant leur article (Orso et Rothermel, 2014). La période de 15 ans précédant 2000 a également été une période de développement spectaculaire des méthodes de test de logiciels. Glenford Myers (Myers, 1978) et Boris Beizer (Beizer, 1984), deux figures emblématiques de la communauté des tests de logiciels, ont fait leur travail de pionnier dans les années 70 et 80. Malheureusement, le principal problème est celui de l’adoption, et non de l’adéquation des méthodes de test. La communauté du développement de logiciels a mis du temps à adopter des méthodes rigoureuses de test de logiciels au fil des ans, malgré les preuves empiriques disponibles de leur utilité (Kuhn et al., 2015, Morgan, 2018). Cette situation a été exacerbée par deux réalités du développement de logiciels. Les efforts de test de logiciels sont notoirement sous-financés et sous-financés. En outre, la vitesse et la complexité des efforts de développement de logiciels ont considérablement augmenté ces dernières années.
Les systèmes logiciels sont désormais plus répandus que jamais et jouent un rôle de plus en plus important dans nos vies. L’importance cruciale de méthodes de test de logiciels robustes est évidente et constitue un aspect du développement de logiciels dont tous les praticiens du développement de logiciels doivent être davantage conscients. Pour répondre à ce besoin, nous avons entrepris cette série d’articles de blog. Cet article est le deuxième de cette série, et d’autres suivront.
Ouvrages cités
Beizer, Boris. Tests de systèmes logiciels et assurance qualité . Van Nostrand Reinhold Co., 1984.
Boehm, Barry W. « Économie de l'ingénierie logicielle ». IEEE Transactions on Software Engineering (1984) : 4-21.
Kuhn, DR, Bryce, R., Duan, F., Ghandehari, LS, Lei, Y., & Kacker, RN (2015). « Tests combinatoires : théorie et pratique. » Advances in computers , 99 , 1-66.
Myers, Glenford J. « Une expérience contrôlée dans les tests de programmes et les inspections/travaux de code. » Communications of the ACM 21.9 (1978) : 760-768.
Morgan, J. (2018). « Tests combinatoires : une approche des tests de systèmes et de logiciels basée sur des tableaux de recouvrement. » Méthodes analytiques dans les tests de systèmes et de logiciels , 131-158.
Rapport du NIST. « Les impacts économiques d'une infrastructure inadéquate pour les tests de logiciels. » National Institute of Standards and Technology Planning Report 02-3. Mai 2002.
Orso, A., et Rothermel, G. (2014) « Tests de logiciels : un récit de voyage de recherche (2000-2014) », dans Proceedings on the Future of Software Engineering , ACM, mai 2014, pp. 117-132
Wong, W. Eric, Vidroha Debroy et Andrew Restrepo. « Le rôle des logiciels dans les accidents catastrophiques récents. » Rapport technologique annuel 2009 de la société de fiabilité IEEE 59.3 (2009).
Wong, W. Eric, Xuelin Li et Philip A. Laplante. « Connaître davantage nos ennemis et ouvrir la voie : un aperçu des rôles joués par les bogues dans les échecs logiciels. » Journal of Systems and Software 133 (2017) : 68-94.
Les tests combinatoires (voir ci-dessous les références de l'article) sont une approche de test qui se concentre sur les défauts dus aux interactions. L'objet mathématique sous-jacent est un tableau de couverture et il s'agit donc d'une approche très efficace, même lorsqu'il y a des milliers d'entrées ! Ce sera le sujet d'un prochain blog.
Kuhn, DR, Bryce, R., Duan, F., Ghandehari, LS, Lei, Y., & Kacker, RN (2015). « Tests combinatoires : théorie et pratique. » Advances in computers , 99 , 1-66.
Morgan, J. (2018). « Tests combinatoires : une approche des tests de systèmes et de logiciels basée sur des tableaux de recouvrement. » Méthodes analytiques dans les tests de systèmes et de logiciels , 131-158.
