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…)
la classification a disparue ! (404) Dommage, les tests ca m’interesse 🙂
le passage de dotclear à wordpress a laissé des traces 🙂
En terme de stratégie de test, voici ce qui pourrait vous intéresser :
http://www.qualitystreet.fr/2009/03/11/strategie-de-test-qualite-et-agilite-la-vision-qui-change-tout/