Introduction au test logiciel/Introduction

Avant d'entrer dans le vif du sujet, revenons à la notion de qualité logicielle pour détourer quels aspects de celle-ci nous allons traiter. Voyons ensuite les symptômes du développeur qui ne teste pas ou teste mal. Enfin, nous expliquerons pourquoi ce livre devrait susciter l'intérêt du lecteur concerné.

La qualité logicielle ?

Une notion subjective

Selon les points de vue, la qualité logicielle n'a pas la même définition.

• Pour le développeur, il s'agit d'abord de voir la qualité du code-source : celui-ci est-il modulaire, générique, compréhensible, documenté ?
• Pour le responsable du système d'information un logiciel doit plutôt être facile à administrer et ne pas corrompre la sécurité globale du SI.
• L'utilisateur, lui, s'attend plutôt à ce qu'un logiciel remplisse d'abord son besoin sans être trop coûteux, en étant si possible ergonomique voire esthétique.
• Pour le financier, il s'agit plutôt de savoir si le logiciel se vend bien, s'il permet de faire du profit ou s'il permet d'améliorer la compétitivité d'une structure.

Autant de préoccupations différentes pour un même produit. Dans ce qui suit, nous allons plutôt nous intéresser à la qualité du logiciel telle qu'elle est perçue par le développeur.

La nécessité d'assurer un suivi de la qualité logicielle

Pour vous convaincre de la nécessité d'intégrer dans toute démarche de développement (qu'elle se fasse dans le cadre d'une entreprise, d'un projet institutionnel, d'une réalisation bénévole en logiciel libre) une approche raisonnable de la qualité logicielle, nous pourrions lister les plus fameuses défaillances de l'histoire de l'informatique et d'autres domaines de l'ingénierie.

Sans nous lancer dans le récit exhaustif de ces grandes catastrophes techniques dont les plus fameuses ont coûté des vies humaines tandis que d'autres ont gaspillé des milliards de budget, citons tout de même quelques cas où une défaillance informatique s'est avérée responsable au moins en partie d'une catastrophe :

• la sonde Mariner 1 dont l'explosion a été déclenché 294,5 secondes après son décollage en raison d'une défaillance des commandes de guidage ;
• le satellite Mars Climate Orbiter a raté sa mise en orbite autour de la planète Mars pour s'écraser sur la planète rouge : certains paramètres avaient été calculés en unités de mesure anglo-saxonnes et transmises à l'équipe de navigation qui attendait ces données en unités du système métrique. Coût total du projet : 327,6 million de $ ;
• Therac-25 est une machine de radiothérapie qui coûta la vie à plusieurs patients ;
• Le projet Virtual Case File est un fiasco : le développement, commandé par le FBI, fut entièrement abandonné au bout de 5 ans et 100 millions de $ ;
• Le vol 501 de la fusée Ariane 5 : elle explosa lors de son premier vol, 40 secondes après son décollage, emportant avec elle les 370 millions de dollars investis dans le projet et les satellites qu'elle devait transporter.

Ces projets sont bien sûr hors du commun et sont bien différents de ceux que chaque entreprise, ingénieur ou développeur rencontrera dans sa carrière. Souvent, le risque causé par une panne est plus limité. Toutefois, de nombreux projets nécessitent un haut niveau de sureté de fonctionnement :

• Contrôle de centrale nucléaire,
• Émetteur de télécommunication/télévision (niveau d'émission des ondes),
• En général, tout logiciel qui peut contrôler un équipement électrique/électronique utilisant une puissance électrique potentiellement dangereuse,
• De façon générale, tous les logiciels contrôlant des équipements impliquant des êtres vivants (médical, transport, ...).

Néanmoins, même pour les projets ne requérant aucun niveau de sécurité, la présence de bogues provoquant la défaillance d'un système peut engendrer des coût imprévus voire mener à l'échec d'un projet, ce qui est déplaisant pour tous les intervenants. En 2002, une étude commandée par le National Institute of Standards and Technology conclue que les bogues et les erreurs logiciels coûtent chaque année 59 billions de $ à l'économie américaine soit 0,6 % du PIB.

Les mauvaises pratiques ou « À qui s'adresse ce livre ? »

Si, lorsque que vous constatez l'apparition d'un bogue dans un programme que vous êtes en train de développer, vous adoptez le comportement suivant :

1. Placer des appels d'affichage un peu partout.
2. Lancer le programme pour évaluer l'affichage produit en espérant trouver des informations permettant d'isoler la zone d'où le bogue provient.
3. Corriger le bogue en modifiant et relançant le programme autant de fois que nécessaire.
4. Effacer tous les appels d'affichage qui polluent le code pour revenir à un code propre.
5. Recommencer à chaque fois qu'un bogue apparaît ou réapparaît.

Cette démarche, en plus d'être coûteuse en temps, est inefficace. Elle est difficile à mettre en œuvre dans une grande base de code lorsqu'on ne sait pas d'où le bogue peut venir. De plus, tout ce travail est perdu étant donné que si un bogue similaire réapparaît, il faudra remettre les traces dans le code en espérant ne pas avoir déjà oublié comment le bogue était apparu, et comment il avait été corrigé. Si c'est ainsi que vous procédez, ce livre est fait pour vous !

Si lorsque votre code atteint une complexité suffisamment grande, vous commencez à craindre de faire des modifications sur des portions de code que vous avez écrite il y a longtemps parce que vous ne savez pas si vos modifications risquent de casser quelque-chose sans que vous vous en rendiez compte ; si vous en avez marre de passer 20 % de votre temps à développer et 80 % de temps à chasser les bogues ; si vous perdez de l'argent parce que pour un produit donné, vous passez plus de temps à corriger des bogues gratuitement lors de la période de garantie que de temps à développer le produit en étant payé, alors ce livre est pour vous.

Pour un développeur, pratiquer des tests et vérifications permet de relire le code source, repérer les erreurs et apprendre à les éviter.

Pourquoi vérifier et tester ?

La vérification et les tests sont deux disciplines de la qualité logicielle. Ces techniques, si elles sont adoptées et appliquées rigoureusement et avec intelligence dès le début d'un projet peuvent améliorer significativement la qualité logicielle.

L'adoption d'une pratique de test systématique apportent de multiples avantages :

• Un développeur peut travailler plus sereinement. Si une modification introduit un bogue dans le code, le développeur en sera tout de suite informé. Les erreurs sont corrigées en amont : on évite ainsi les surprises ;
• En évitant ainsi les surprises, on a une meilleure visibilité sur le temps à consacrer pour le reste du développement. Ainsi, le gestionnaire ne verra pas ses ressources réquisitionnées par la découverte, le lendemain de la mise en production, de nombreux bogues qui auraient pu être corrigés plus tôt.
• Le produit final est de meilleure qualité, cela est apprécié par l'utilisateur final. On réduit ainsi le coût de la garantie.

Ce livre s'adresse donc aux développeurs qui ignorent les aspects techniques d'une démarche de test logiciel intégrée au processus de développement. C'est une initiation à ces pratiques qui est proposée tout au long de cet ouvrage.

Après la lecture de ce livre, vous serez en mesure :

• de choisir, en fonction des technologies que vous utilisez, les outils qui vous permettront de tester et de vérifier le code que vous écrivez ;
• d'écrire vos propres tests pour vérifier la qualité de votre code ;
• de concevoir vos applications de manière à les rendre testables ;
• de vérifier la qualité de vos tests ;
• d'intégrer ces éléments dans votre démarche globale de développement.

Remarquons que ces deux disciplines peuvent ne pas être suffisantes et être complétées par d'autres solutions adéquates visant à assurer la qualité logicielle. Remarquons enfin que si la qualité d'un logiciel au sens où nous la traitons ici peut jouer un rôle, elle n'est en rien garante du succès commercial d'un projet.

Quels sont les pré-requis ?

La lecture de ce livre nécessite d'avoir tout de même une expérience même courte du développement en utilisant la programmation orientée objet. Il est bon d'avoir une expérience sur un projet suffisamment complexe pour avoir perçu ce qui est évoqué plus haut.