Classez vos tests (1ère partie): boîtes noires, boîtes blanches

Ce qui frappe quand on s'intéresse au test logiciel c'est le grand nombre de dénominations existantes. Il est important de savoir à quelle catégorie un test appartient afin de ne pas se tromper de but et de méthode car il faut reconnaître que l'on s'y perd parfois un peu.

Je vous propose donc une suite d'articles ayant pour but de lister et de classer les différentes catégories de tests.

Classement par niveau d'accessibilité

L'activité de base de la qualification logicielle est le test. l'ISTQB, organisation fondée par des professionnels du test dans le but de partager les connaissances et les pratiques, définit un cas de test (test case) comme l'ensemble de l'état d'entrée, des valeurs d'entrées, des résultats attendus et de l'état en sortie d'une entité logicielle ayant pour but d'activer un chemin d'exécution ou de vérifier la conformité avec une spécification.

Cette définition est large afin de s'appliquer aux différents types de tests qui peuvent être réalisés. On retiendra tout de même qu'un test est toujours écrit avec un but précis et qu'il ne doit pas seulement prendre en compte le résultat à tester mais aussi l'état global de l'application en entrée et en sortie. Une trop grande dépendance du test avec cet état pouvant avoir un impact important sur la maintenabilité de la chaîne de validation.

On retrouve aussi dans cette définition, les 2 points de départs qui peuvent être pris pour écrire un test: un chemin d'exécution, c'est à dire la structure du programme ou une spécification.

Ces deux points de départs définissent la notion d'accessibilité d'un test c'est à dire la connaissance du testeur sur la structure interne du programme. On classe les tests dans deux grandes catégories:

• Les tests boîtes blanches ou tests structurels pour lesquels le testeur connaît la structure interne du programme.
• Les tests boîtes noires pour lesquels le testeur ne connaît que les spécifications du programme et ignore tout ce qui est lié à l'implémentation.

L'approche à utiliser est très différente dans les 2 cas. Un test boîte blanche nécessite de connaître en détail la structure du programme. Le principal bénéfice est de pouvoir tester les différents chemins logiques pris par le code. Cela permet d'optimiser le taux de couverture des tests. L'inconvénient est qu'il est plus difficile de maintenir ce type de test car il est probable qu'une partie des tests ne survivra pas à un refactoring. De plus, pour des applications complexes, il peut-être relativement difficile d'écrire des tests qui vérifient tous les cas.

Un test boîte noire ne prend en compte que les spécifications (parfois aussi appelées les exigences) de l'application. Le testeur ne pourra alors garantir que tous les cas aient été testés mais la base de test ne sera pas impactée en cas d'une nouvelle implémentation. Tant que l'interface reste identique, les tests restent valides.

Ainsi, pour le test d'un module donné, un testeur boîte blanche devra analyser l'ensemble du code et tester les différents cas particuliers. Un testeur boîte noire, ne testera lui que ce qui a été défini par les spécifications. Si des cas particuliers ou des limitations existent du fait de l'implémentation, il est probable qu'ils ne seront pas testés. Il est donc important de rester pragmatique et d'essayer de comprendre le fonctionnement du module même si on choisi de ne pas entrer dans les détails de l'implémentation. De plus, il est important de garder à jour des spécifications (fonctionnelles et techniques) exactes et complètes afin que d'éventuelles spécificités soient connues.

Les 2 approches ont leurs avantages et leur inconvénients et pourront être mixées selon les cas (on parle alors parfois de tests en boîte grise mais ce terme n'est malheureusement pas clairement défini). Il est toutefois recommandé d'identifier et/ou de séparer les tests boîtes blanches des tests boîtes noires. Il sera plus facile de maintenir le tout et de connaître les tests à reprendre suite à une modification du code. De même, un testeur devra toujours avoir en tête quelle stratégie a été choisie pour telle partie du programme. Cela doit être clairement défini dans le plan de test.

Quelle que soit l'approche choisie, une communication ouverte et fréquente entre l'équipe de développement et l'équipe de test reste une condition de succès.

Le prochain article de cette série définira quels sont les différents niveaux de test.