Tests logiciels : ma classification

Plusieurs typologies de tests (le plus souvent complémentaires) coexistent ; la première d’entre elle, la plus simple, distingue les tests « Boite blanche » des tests « Boite noire » (différence en terme d’accès au fonctionnement interne de l’application). Une autre insistera davantage sur les aspects Statiques ou Dynamiques. On pourrait aussi catégoriser les tests selon le type d’activité à mener (l’IEEE 1012), Vérification (est-ce un produit bien fait ?) ou Validation (avons-nous fait le bon produit ?).

Je vous présente aujourd’hui la classification que j’utilise et qui mixe quant à elle, niveaux de test et caractéristiques de test. Cette classification répond à mes problématiques de ces dernières années et s’adapte à de nombreux contextes:

Avantages :

• C’est un bon support de communication : on va à l’essentiel (simplicité et signifiance)
• Elle s’inscrit complètement dans une démarche itérative, incrémentale et pilotée par les risques (Processus Unifié)
• Elle place les tests au cœur du projet
• Elle favorise la mise en place, dés le début du projet, d’une stratégie de test en fonction des risques identifiés et des exigences à tester
• Elle permet d’appréhender toute forme d’exigences : fonctionnelles (ce que le système doit faire), non fonctionnelles (qualité des services attendus, cf. ISO 9126)
• Elle permet de tracer ces exigences : toute exigence doit être couverte par au moins un type de test en fonction des risques
• Elle permet d’associer facilement des rôles et des ressources à un type de test (par exemple, les Tests d’Utilisabilité planifiés et réalisés par l’Ergonome; les Tests Unitaires réalisés par les Développeurs…)