Glossaire · Fondamentaux du test
Plan de test
En anglais : Test plan
Également appelé : plans de test, plan de tests, planification des tests, test planning
Définition
Document qui définit le périmètre, l'approche, les ressources, le planning, les environnements, les risques et les critères d'entrée et de sortie des tests d'une release.
Un plan de test décrit comment les tests seront menés pour une release, un projet ou une fonctionnalité donnée : ce qui est dans le périmètre et ce qui en est exclu, quels types de tests s’appliquent, qui fait quoi, où cela s’exécute, quand cela a lieu et comment l’équipe saura que c’est terminé. C’est l’accord entre la QA, le développement et le produit sur les tests, mis par écrit avant le début de l’exécution. La norme IEEE 829 (aujourd’hui remplacée par l’ISO/IEC/IEEE 29119-3) en est le modèle classique.
Ce que contient un plan de test utile
- Périmètre : les fonctionnalités incluses et, tout aussi important, celles explicitement exclues.
- Approche : niveaux et types de tests (unitaires, API, interface, performance, sécurité, accessibilité), ce qui est automatisé et ce qui est manuel.
- Environnements et données : quels environnements, comment les données de test sont créées ou anonymisées, les sandboxes des services tiers.
- Critères d’entrée : ce qui doit être vrai avant le début des tests, par exemple « build déployé en staging et smoke tests au vert ».
- Critères de sortie : ce que signifie « terminé », par exemple « aucune anomalie critique ou majeure ouverte, tous les scénarios P1 réussis, suite de régression au vert ».
- Risques et mesures d’atténuation : par exemple « la sandbox de paiement est instable, nous la stubberons donc pour les tests fonctionnels et exécuterons chaque jour un contrôle end-to-end contre la vraie sandbox ».
- Rôles, planning et livrables : qui teste quoi, les dates clés et les rapports produits.
Plan de test ou stratégie de test
Une stratégie de test est l’approche de haut niveau, plus durable, d’un produit ou d’une organisation : principes de test, niveaux, outils et standards. Un plan de test applique cette stratégie à une release ou à un projet, avec un périmètre, des dates et des personnes concrets. De nombreuses équipes agiles tiennent une page de stratégie légère et un plan court par release ou par epic.
Erreurs fréquentes
- Écrire un document de 40 pages que personne ne lit. Dans une équipe agile, un plan d’une page tenu à jour vaut mieux qu’un plan exhaustif dépassé dès le deuxième sprint.
- Des critères de sortie flous. « Tests terminés » n’est pas mesurable. Énoncez les conditions.
- Pas de section hors périmètre. Les exclusions non formulées se transforment en disputes après la release.