Le domaine du test logiciel

Le test logiciel est le processus qui consiste à évaluer et à vérifier qu’une application logicielle fait ce qu’elle est censé(e) faire.

un test désigne une procédure de vérification d’un système. Son objectif principal est d’identifier un nombre maximal de comportements problématiques du logiciel. Il permet ainsi, dès lors que les problèmes identifiés seront corrigés, et d’augmenter la qualité du logiciel.

La définition qui suit est issue de la norme IEEE 829-19982 revue à l’aide du glossaire de l’ISTQB :

Un test est un ensemble de cas à tester (état de l’objet à tester avant exécution du test, actions ou données en entrée, valeurs ou observations attendues, et état de l’objet après exécution), éventuellement accompagné d’une procédure d’exécution (séquence d’actions à exécuter). Il est lié à un objectif.

Histoire du test

Le test logiciel est arrivé en même temps que le développement logiciel, qui a débuté juste après la seconde guerre mondiale. C’est à l’informaticien Tom Kilburn que l’on doit l’écriture du premier logiciel qui a été lancé le 21 juin 1948 à l’Université de Manchester, en Angleterre. Il effectuait des calculs mathématiques à l’aide d’instructions en code machine.

Le débogage était la principale méthode de test à l’époque et il l’est resté pendant les deux décennies suivantes. Dans les années 1980, les équipes de développement ne se contentaient plus d’isoler et de corriger les bogues des logiciels, mais elles testaient les applications dans des conditions réelles. Cela a ouvert la voie à une vision plus large des tests qui englobaient un processus d’assurance qualité faisant partie du cycle de vie du développement logiciel.

Dans les années 1990, il y a eu une transition des tests vers un processus plus complet appelé assurance qualité, qui couvre l’ensemble du cycle de développement logiciel et affecte les processus de planification, de conception, de création et d’exécution des cas de test, le support des cas de test existants et les environnements de test.

Importance du test

Peu de gens peuvent s’opposer à la nécessité d’un contrôle qualité lors du développement logiciel. Les retards de livraison ou les défauts logiciels peuvent nuire à la réputation d’une marque, et entraîner la frustration et la perte de clients. Dans des cas extrêmes, un bogue ou un défaut peut dégrader les systèmes interconnectés ou provoquer de graves dysfonctionnements.

Bien que les tests eux-mêmes sont coûteux, les entreprises peuvent économiser des millions par an en développement et en support si elles disposent d’une bonne technique de test et de processus d’assurance qualité. Les tests logiciels précoces révèlent les problèmes avant qu’un produit ne soit mis sur le marché. Plus vite les équipes de développement reçoivent des informations sur les tests, plus vite elles peuvent résoudre des problèmes comme ceux ci-dessous :

• Défauts architecturaux
• Mauvaises décisions de conception
• Fonctionnalité non valide ou incorrecte
• Vulnérabilités de sécurité
• Problèmes d’évolutivité

Lorsque le développement laisse une large place aux tests, il permet d’améliorer la fiabilité des logiciels et de livrer des applications de qualité avec peu d’erreurs. Un système qui répond aux attentes des clients, voire les dépasse, permet d’augmenter les ventes et la part de marché.

Différent types de test

il existe plusieurs types de tests, qui interviennent à différents stage de développement d’un logiciel et vérifient différents modules d’un logiciel. la liste suivant n’est pas exhaustive, elle nous donne une idée sur les types de tests qu’on peut avoir. Les différents types de test ne sont pas nécessairement exclusive et ne sont pas impérativement mis en place, sa dépend de chaque structure et les modules du leur logiciel:

• Les tests fonctionnels valident le bon comportement du logiciel en matière de service rendu. Ces tests sont souvent ceux décrits en détail dans les scénarios et sur lesquels l’essentiel de l’investissement est fait, par analogie aux spécifications qui décrivent souvent en détail la fonction à remplir. Notre recommandation sur le sujet rejoint les points évoqués ci-dessus. Ecrire les scénarios très tôt est fortement souhaitable, car cela valide la bonne analyse fonctionnelle, tout en donnant de la matière au développeur pour ses propres tests unitaires. Mais mettre l’exclusivité de l’effort sur ces tests est une erreur encore fréquente.
• Les tests de compatibilité de plate-forme comprennent au minimum des tests d’installation et de bon fonctionnement sur des environnements ciblés (système d’exploitation, base de données… ), voire pour les éditeurs des tests plus poussés détectant les problèmes potentiels avant certification pour une plate-forme donnée. Ils permettent de détecter le respect des bonnes pratiques telles que l’utilisation de répertoires virtuels, l’exécution sans droits d’administration, la désinstallation, la localisation des ressources etc. Les postes des développeurs ne doivent pas être confondus avec l’environnement d’exécution cible.
• Les tests de robustesse visent à tester le logiciel dans des conditions dégradées ou aux limites. Ils sont rarement menés de manière systématique, alors qu’ils ne sont pas compliqués à mettre en œuvre : débranchement d’un câble, arrêt brutal d’une machine…
• Les tests de performance sont souvent menés en fin de projet. Les facteurs influant sur la performance étant nombreux, il est risqué de tirer des conclusions hâtives sur des tests partiels en l’absence de volumes représentatifs et de présence de l’ensemble des conditions d’exécution.

Différent niveaux de test

Il existe plusieurs niveaux de test qui vérifie différents composant d’un logiciel. Ces tests sont complémentaires et sont mis en place à différents stage du développement d’un logiciel.

Notons que ces tests font partie des différents types déjà mentionnés et il n’y a pas de relation d’exclusivité d’un type avec un niveau. Un type de test peut contenir plusieurs niveaux.

• Tests unitaires, qui sont menés par le développeur lui-même, et qui consistent à vérifier la bonne exécution des fonctions dont il a la charge.
• Tests d’intégration, qui sont menés par un testeur dédié, au sein de l’équipe de développement ou d’une équipe qualité travaillant en coopération étroite. La particularité de ces tests est que ceux-ci visent à tester la mise en commun de plusieurs composants et l’enchaînement de processus complets au-delà des simples fonctions unitaires. On parle parfois de tests en boîte blanche, dans la mesure où l’on est amené à regarder les relations entre les composants pour vérifier leur bonne coopération.
• Tests de qualification, qui consistent à dérouler des scénarios complets, représentant les cas d’utilisation du logiciel, sans se préoccuper de l’implémentation ou des composants sous-jacents. On est alors dans une logique de boîte noire, et il est fortement recommandé que l’équipe qui réalise ces tests soit distincte de l’équipe de développement.
• Tests d’acceptation, menés avec des utilisateurs pilotes, afin de valider l’adéquation du logiciel au métier et sa facilité d’adoption par ceux qui devront l’utiliser régulièrement.

Conclusion

Le test est domaine qui date de l’écriture du premier logiciel, et qui évolue dans le temps, sont importance est primordiale si on veut avoir un logiciel de qualité. Sans test ou cours le risque de déployer des logiciels qui ne fonctionnent pas comme prévus.

Il faut savoir qu’au delà du coût que représente les tests dans le cycle de développement, plus les tests sont mis en place tôt, plus on fait des économies puisqu’on s’assure qu’on ne déploie que le logiciel résultant voulu.

Autre particularité qu’il faut savoir, c’est que chaque organisation met en place les différents niveaux et types de test qui lui corresponde et que sur certain cas complexe, on ne pourra pas tous tester, si non beaucoup de logiciel complexe ne verront jamais le jour.