Les principes du test logiciel

Tester une application informatique…

Tout part des exigences à partir desquelles l’application a pu être conçue et réalisée, qui sont de deux natures :

• exigences fonctionnelles, qui permettent de définir les fonctionnalités de l’application ainsi que leurs règles de gestion, mais aussi les processus (enchaînements de fonctionnalités) qui seront déroulés au cours de son utilisation,
• exigences non-fonctionnelles, qui permettent de préciser les caractéristiques attendues des fonctionnalités et/ou des processus. Par exemple, une exigence de performance imposera un temps de réponse inférieur à 1 seconde pour un délai de connexion de l’utilisateur, tandis qu’une exigence de tenue à la charge imposera la possibilité de supporter 5000 utilisateurs simultanés sans affecter les performances attendues.

Si les exigences fonctionnelles déterminent l’architecture fonctionnelle de l’application (les « briques » de base et leurs enchaînements), les exigences non fonctionnelles déterminent la qualité attendue de chacune de ces briques ou d’un ensemble de briques :

… c’est vérifier sa conformité à toutes les exigences exprimées

S’il s’agit avant tout de vérifier la conformité fonctionnelle de l’application (fonctionnalités et processus), vérifier la réponse de l’application aux exigences non-fonctionnelles qui lui sont affectées est tout aussi important et peut éviter des situations critiques (par exemple, une application de banque en ligne ne remplissant pas les exigences de sécurité peut avoir des conséquences fatales pour la banque qui la diffuse).

Structurer et formuler de façon complète et précise les exigences fonctionnelles et non fonctionnelles permet de disposer très tôt d’une idée précise de l’architecture fonctionnelle qu’il conviendra de vérifier et des types de tests non-fonctionnels qu’il sera nécessaire de mettre en œuvre, sans attendre que la réalisation ait débuté. Cela permet de préparer le projet de test au plus tôt et dans les meilleures conditions : évaluation de la complexité et de l’effort de test, définition des compétences et moyens nécessaires, etc.

Rappelons que précision et complétude des exigences sont un atout majeur pour une conception et une réalisation de qualité ainsi qu’une meilleure maîtrise des risques de dérive des projets : si tester reste indispensable, on peut néanmoins envisager un effort et un coût moindres en corrections et modifications de conception.

Investir en début de projet sur un effort de réflexion accru quant aux attentes et exigences portées à la fois par les utilisateurs et les contraintes d’intégration au système d’information sécurise l’ensemble du projet en termes d’effort, de coût et de qualité du résultat

Identifier les types de tests pour décider quoi tester, quand et par qui

A l’image des exigences, il existe deux grandes natures de tests : les tests fonctionnels vérifient la conformité aux exigences fonctionnelles et les tests non fonctionnels vérifient la conformité aux exigences non-fonctionnelles. Dans tous les cas, leur mise en œuvre s’appuie sur les exigences formulées explicitement.

Certains tests sont mis en œuvre par la maîtrise d’œuvre (MOE) tandis que d’autres sont de la responsabilité de la maîtrise d’ouvrage (MOA). Cependant, les exigences qui déterminent type et contenu des tests sont le plus souvent de la responsabilité de la MOA, notamment en ce qui concerne les exigences fonctionnelles ainsi que les caractéristiques de performance, d’ergonomie et de sécurité.

Il n’est ni nécessaire ni souhaitable d’attendre la fin des développements pour procéder aux tests. Certains d’entre eux peuvent être effectués très tôt pendant le cycle de réalisation, alors que d’autres nécessitent d’attendre la fin de la réalisation pour être mis en œuvre.

Les types de test évoqués ci-dessus sont les plus courants, mais cette typologie n’est pas figée; elle évolue notamment avec les technologies et les supports de mise en œuvre (Web, mobilité, etc.).

Les tests fonctionnels sont pratiqués systématiquement, dans la mesure où ils portent sur le fonctionnement même de l’application. Parmi ces tests :

• les tests unitaires visent à vérifier le bon fonctionnement de tout ou partie d’une fonctionnalité ou d’un programme,
• les tests de conformité fonctionnelle, effectués par la MOE, visent à s’assurer de la conformité d’une fonctionnalité à sa conception; effectués par la MOA, ils visent à s’assurer de la conformité de cette même fonctionnalité aux règles de gestion déterminées par les exigences fonctionnelles,
• les tests d’intégration applicative visent à s’assurer que les différentes fonctionnalités d’une même application s’enchaînent correctement et échangent entre elles de la manière attendue. Les tests d’intégration « système » vérifient la conformité des interactions entre l’application et les autres composants du système d’information de l’entreprise, ainsi que des composants externes à l’entreprise, le cas échéant, et que sa mise en œuvre ne provoque pas de dysfonctionnement de ces autres composants,
• les tests de processus visent à s’assurer que les processus métier portés par l’application intégrée au système d’information de l’entreprise fonctionnent conformément aux attentes des métiers.

Les tests non-fonctionnels seront décidés en fonction des exigences qui leur sont rattachées. Les plus couramment pratiqués sont les tests de performance et de tenue à la charge, les tests de sécurité et les tests d’ergonomie.

Il importe de conserver à l’esprit qu’une exigence non-fonctionnelle non formulée peut entraîner la mise en évidence tardive de contraintes dont la prise en compte pourra alors s’avérer coûteuse.

Conformité et Non-Régression

On dit qu’une application régresse lorsqu’elle présente des dysfonctionnements jamais observés auparavant dans des conditions strictement identiques d’utilisation. Les régressions peuvent porter aussi bien sur le fonctionnement même de l’application (régression fonctionnelle) que sur des caractéristiques non-fonctionnelles telles que la performance, l’ergonomie, etc.

Les causes majeures de régression applicative proviennent de modifications apportées à l’application consécutive- ment à un besoin d’évolution ou de correction :

• modification du code assurant le déroulement d’un composant,
• modification de l’étendue de valeurs que peuvent prendre certaines données gérées par l’application.

L’effet régressif d’une modification peut être observé dans le fonctionnement de l’application elle-même, mais aussi dans celui d’une autre application qui partage des données avec elle.

Une illustration éloquente de ce cas de figure est le vol 501 de la fusée Ariane 5 en juin 1996 : le logiciel de guidage inertiel de la fusée, conçu et opérationnel pour Ariane 4, n’était pas en mesure de traiter correctement toutes les valeurs transmises par les équipements d’Ariane 5, ce qui a conduit à l’auto-destruction de la fusée en plein vol. Selon l’enquête, des raisons financières avaient conduit à renoncer aux tests de régression de ce système.

Le test de la première version d’une application consiste à vérifier la conformité de l’application aux exigences qui la décrivent. On parle alors de tests de conformité.

Lorsque l’on teste une nouvelle version d’une application, il y a lieu de pratiquer deux séries de tests :

• en premier, la conformité des parties modifiées aux exigences ayant conduit à leur modification,
• en second, la non-régression des parties n’ayant subi aucune modification, dont le comportement doit être identique à ce qu’il était avant les modifications.

En pratique, tester la non-régression revient à effectuer, sur les parties non-modifiées, les tests de conformité effectués lors de la création ou de la dernière modification de ces parties. Contrairement à une idée reçue, les tests de non-régression ne sont donc pas un type de test au même titre que les tests fonctionnels et les tests de performance. Dans certains cas, on peut être amené à tester la régression des performances d’une application comme sa régression fonctionnelle.

Tester une nouvelle version d’une application existante nécessite trois pré-requis :

• la disponibilité des tests effectués pour les précédentes versions, formalisés de façon très précise dans un plan de test, de manière à être certain d’effectuer les mêmes contrôles dans des conditions exactement iden- tiques, faute de quoi les tests de régression perdraient toute valeur,
• l’actualisation de ce plan de test pour tenir compte des modifications apportées, en vue du test de leur conformité aux exigences ayant conduit à leur mise en œuvre,
• la disponibilité d’un périmètre de régression potentielle de l’application, c’est-à-dire des parties non modifiées de l’application et de ses « partenaires », susceptibles d’être affectées par les modifications effectuées. Ce périmètre est fourni par une étude d’impact des modifications apportées. Il permet de cibler précisément les parties à tester en non-régression et évite le coût inutilement élevé d’un test systématique de la totalité de l’ensemble applicatif concerné.

Optimiser l’effort de test par la maîtrise du risque logiciel

Faut-il attendre que tous les composants aient été testés et tous les bugs corrigés pour décider de la mise production d’une application ? C’est une idée encore assez répandue, mais qui ne correspond pas à la réalité, pour deux raisons :

• d’une part, le « zéro défaut » n’existe pas. Tout au plus peut-on se dire que, si une application n’a présenté jusqu’ici aucun dysfonctionnement, c’est heureux, mais cela ne présage pas de l’avenir,
• d’autre part, l’expérience des projets de test montre qu’il n’est pas possible de prévoir et mettre en œuvre tous les tests possibles sur une application, sauf à disposer d’un budget infini en temps et en moyens.

Alors sur quoi peut-on se baser pour déclarer qu’il est possible de mettre une application en production ? La réponse réside dans le choix de ce qu’il est nécessaire et suffisant de tester pour garantir que les défaillances éventuelles n’auront pas d’impact significatif. L’analyse du risque logiciel, qui évalue le niveau de risque porté par chaque composant de l’application, permet ce choix par la définition des priorités de test.

Le risque fatal est celui qui n’a pas été identifié

Les avantages d’une telle pratique sont nombreux, notamment :

• la prise de risque est possible, car elle se fait en connaissance de cause,
• le budget du projet de test est sécurisé et son pilotage assoupli, du fait de choix lisibles, partageables et arbitrables,

les résultats de l’analyse des risques peuvent aussi servir à sécuriser la réalisation, en posant des prio- rités sur les développements, sur l’attention à y consacrer et sur les compétences à y affecter.