Omniprésent tout au long du cycle de développement, le test logiciel n'est pourtant pas toujours correctement mis en oeuvre: cet article espère faire l'inventaire de quelques bonnes pratiques en la matière.

Généralités
Bien évidemment, il serait aberrant de vouloir réaliser des tests exhaustifs de toutes les fonctions et méthodes écrites pour une application : on ne va pas tester une méthode de calcul avec toutes les possibilités connues. L'attention va surtout se porter sur l'interaction entre les différentes fonctions, entre les fonctions et l'interface graphique, entre le logiciel et le système d'exploitation...
Dans tous les cas, le but avoué du test est de découvrir des défauts. Un test qui n'en trouve pas n'est pas forcément un test réussi...

Différents niveaux
Parce qu'il est impossible de créer un test qui puisse effectivement vérifier le bon fonctionnement de l'ensemble d'une application, le test est divisé en une série de tests plus spécifiques, chacun faisant appel à une logique particulière, ou se portant sur un niveau précis de la conception ou de l'utilisation. Nous allons survoler ici quelques-unes des méthodes les plus couramment utilisées, en sachant que la description complète de chacun prendrait plusieurs pages...

Méthodes affirmation/négation
Ces deux types de test sont complémentaires : le test par affirmation vérifie la conformité de l'application face aux spécifications, tandis que le but du test par négation est de montrer que l'application n'agit pas de la bonne manière. Ainsi, le test par affirmation suit le "mode d'emploi" à la lettre, tandis que celui par négation fait son possible pour ne pas le suivre, et agir de la manière la moins logique et prévisible possible.

Méthodes boîte noire/blanche
Boite noire : les essais tournent autour du fonctionnement externe du système : les détails d'implémentation des composants ne sont pas connus (ou sciemment ignorés), et seul le comportement extérieur est testé.
Boite blanche : à l'inverse, les détails d'implémentation des composants sont ici tous connus, et le test teste spécifiquement ces implémentations.

Le test unitaire
Ce test contrôle chaque unité logicielle (le plus petit composants compilable) : savoir si elle correspond à ses spécifications, s'il y a des erreurs de logique. Ce test est généralement fait directement par le développeur de l'unité, qui conçoit lui-même le test en question.
Ce test doit être fait de manière isolée en premier lieu (pour savoir si elle fonctionne comme on le souhaite, tant dans les entrées que dans les sorties), puis en combinaison avec les unités qui travaillent avec elle. C'est typiquement une technique boîte blanche qui est utilisée ici.

Le test d'intégration
Premier d'une série de tests (il est généralement suivi par le test système, puis le test d'intégration système), ce test cherche à tester la stabilité et la cohérence des interface et interactions de l'application. Il est lui aussi réalisé par l'équipe de développement plutôt qu'une équipe indépendante. Il s'agit ici d'un test de type boîte noire.

Le test système
On teste ici la fiabilité et la performance de l'ensemble du système, tant au niveau fonctionnel que structurel., plutôt que de ses composants. On teste aussi la sécurité, les sorties, l'utilisation des ressources et les performances.

Le test d'intégration système
Ce test vérifie le bon fonctionnement de l'application à la fois avec les autres applications qui sont susceptibles de fonctionner en parallèle sur le système, mais aussi son bon fonctionnement avec les système auxquels l'application pourrait faire appel.

Le test de recette
Ce test doit confirmer que l'application répond d'une manière attendue aux requêtes qui lui sont envoyées. Ce sont des utilisateurs lambda qui font ce test, et surtout pas les développeurs eux-mêmes. Ce test permet d'adapter l'application aux attentes des futurs clients.

Le test de régression
Ce teste fait suite à une modification de l'application (du fait d'une mise à jour ou de l'aboutissement du test de recette) : il faut alors vérifier que l'application n'a pas perdu de fonctionnalités lors de l'ajout de nouvelles fonctionnalités ou la modification de fonctionnalités existantes.

Ce n'est là qu'une poignée de tests, tout comme les modèles de conceptions décrits dans un autre article ne sont qu'une partie de l'iceberg, et ne saurait englober l'ensemble des possibilités face auxquelles une équipe de développement peut se retrouver. Le test est un métier à part entière, et connaître son fonctionnement permet de mieux collaborer lors de l'élaboration de suites de tests...

Les outils de tests les plus connus sont JUnit (Java, porté pour .NET, Python, Perl, Delphi...), JTest (Java), TeamTest et SilkTest.