Qu'est-ce qu'un plan de test ?
Un plan de test est un document détaillé qui décrit la stratégie de test, les objectifs, les ressources, le calendrier et le périmètre d'une campagne de tests. C'est le plan directeur de toute la phase QA — qui répond à qui teste quoi, comment, quand et à quoi ressemble « terminé ».
Considérez un plan de test comme un contrat entre l'équipe QA, les développeurs et les parties prenantes. Il définit les attentes, précise les responsabilités et fournit une feuille de route pour l'exécution des tests. Que vous testiez un petit site web ou une grande application d'entreprise, un bon plan de test maintient tout le monde aligné.
Cet article fournit un modèle de plan de test gratuit et prêt à copier-coller, avec un exemple réel, afin que vous puissiez créer votre propre plan de test en quelques minutes.
Modèle de plan de test (prêt à copier-coller)
Voici un modèle complet de plan de test. Copiez-le dans votre document, votre feuille de calcul ou votre outil de gestion de projet et personnalisez-le pour votre projet.
Plan de test
============
### 1. Introduction
1.1 Objectif
[Brève description de la raison d'être de ce plan de test]
1.2 Périmètre
[Ce qui est testé — inclure les fonctionnalités, les modules, les systèmes]
1.3 Hors périmètre
[Ce qui n'est PAS testé — soyez explicite]
1.4 Références
[Liens vers les documents d'exigences, les spécifications de design, les user stories]
### 2. Objectifs du test
[Ce que vous souhaitez atteindre avec les tests. Exemples :]
- Vérifier que tous les flux de travail métier critiques fonctionnent correctement
- Garantir la compatibilité multi-navigateurs (Chrome, Firefox, Safari, Edge)
- Valider l'intégrité des données sur toutes les opérations CRUD
- Atteindre un taux de réussite des cas de test ≥ 95 % avant la validation finale
### 3. Stratégie de test
3.1 Niveaux de test
[ ] Tests unitaires
[ ] Tests d'intégration (SIT)
[ ] Tests système
[ ] Tests d'acceptation utilisateur (UAT)
3.2 Types de test
[ ] Tests fonctionnels
[ ] Tests de régression
[ ] Tests de performance
[ ] Tests de sécurité
[ ] Tests d'utilisabilité
[ ] Tests d'accessibilité
3.3 Environnement de test
- URL de préproduction : [https://staging.example.com]
- Base de données : [PostgreSQL 15, réplique de préproduction]
- Navigateurs cibles : [Chrome 125+, Firefox 125+, Safari 17+, Edge 125+]
- Appareils mobiles cibles : [iOS 17+, Android 14+]
- Outils de test : [BugCapturer, Lighthouse, axe DevTools]
### 4. Livrables de test
[ ] Document de plan de test (ce document)
[ ] Spécifications des cas de test
[ ] Données de test (comptes factices, échantillons de contenu)
[ ] Rapports de bug (consignés pendant l'exécution)
[ ] Rapport d'exécution des tests (résumé réussi/échoué)
[ ] Document de validation UAT
### 5. Calendrier des tests
| Phase | Date de début | Date de fin | Durée |
|-------|------------|----------|----------|
| Planification des tests | [Date] | [Date] | [X jours] |
| Préparation des cas de test | [Date] | [Date] | [X jours] |
| Exécution des tests (cycle 1) | [Date] | [Date] | [X jours] |
| Correction des bugs | [Date] | [Date] | [X jours] |
| Exécution des tests (cycle 2) | [Date] | [Date] | [X jours] |
| UAT | [Date] | [Date] | [X jours] |
| Validation finale | [Date] | [Date] | [X jours] |
### 6. Rôles et responsabilités
| Rôle | Nom | Responsabilités |
|------|------|-----------------|
| Chef de test | [Nom] | Planifier, coordonner, rendre compte |
| Ingénieur QA | [Nom] | Rédiger les cas de test, exécuter les tests, consigner les bugs |
| Développeur | [Nom] | Corriger les bugs, assister le dépannage |
| Product Owner | [Nom] | Définir les critères d'acceptation, valider l'UAT |
| Participants à l'UAT | [Noms] | Exécuter les scénarios UAT |
### 7. Récapitulatif des cas de test
| Module | Cas de test totaux | Taux d'automatisation % | Priorité |
|--------|-----------------|--------------|----------|
| Inscription utilisateur | [XX] | [X%] | Élevée |
| Connexion / Auth | [XX] | [X%] | Élevée |
| Paiement | [XX] | [X%] | Critique |
| Recherche | [XX] | [X%] | Moyenne |
| Panneau d'administration | [XX] | [X%] | Basse |
### 8. Processus de suivi des bugs
1. Le testeur trouve un bug
2. Le testeur consigne le rapport de bug avec :
- Capture d'écran ou enregistrement d'écran (annoté)
- Étapes de reproduction
- Détails de l'environnement (URL, navigateur, OS)
- Résultat attendu vs résultat réel
3. Le chef de test trie et assigne la priorité
4. Le développeur corrige le bug
5. Le testeur vérifie la correction
6. Le bug est clôturé
Outil recommandé : BugCapturer pour les rapports de bug en un clic
avec métadonnées capturées automatiquement et captures d'écran annotées.
### 9. Critères d'entrée et de sortie
9.1 Critères d'entrée (ce qui doit être vrai avant le début des tests)
[ ] Toutes les fonctionnalités critiques sont développées
[ ] L'environnement de préproduction est stable
[ ] Les données de test sont préparées
[ ] Les cas de test sont examinés et approuvés
9.2 Critères de sortie (ce qui doit être vrai avant la fin des tests)
[ ] Tous les bugs critiques et hautement prioritaires sont corrigés
[ ] 95 % des cas de test ont réussi
[ ] L'UAT est validée par les parties prenantes
[ ] Les objectifs de performance sont atteints
### 10. Risques et mesures d'atténuation
| Risque | Impact | Probabilité | Mesure d'atténuation |
|------|--------|-------------|------------|
| Environnement de préproduction instable | Élevé | Moyenne | Avoir un plan de restauration, un environnement de secours |
| Modifications d'API tierces | Moyen | Moyenne | Simuler les services externes tôt |
| Disponibilité limitée des participants à l'UAT | Élevé | Faible | Recruter des testeurs de secours, prolonger la fenêtre UAT |
| Dérive du périmètre | Moyen | Élevée | Geler les exigences avant le début des tests |
### 11. Approbations
| Rôle | Nom | Signature | Date |
|------|------|-----------|------|
| Chef de test | [Nom] | | |
| Chef de projet | [Nom] | | |
| Product Owner | [Nom] | | |
Exemple de plan de test
Voici un exemple de plan de test rempli pour le lancement d'un site e-commerce :
Projet : Lancement d'AcmeShop.com v2.0 Chef de test : Alex Wang Calendrier : 4 semaines (2 semaines d'exécution + 1 semaine de correction de bugs + 1 semaine d'UAT)
Périmètre :
- Inscription utilisateur, connexion, réinitialisation du mot de passe
- Navigation produit, recherche, filtrage
- Panier et paiement
- Historique des commandes et suivi
- Gestion des commandes en administration
- Intégration de la passerelle de paiement (Stripe)
Hors périmètre :
- Système de gestion des stocks tiers (fournisseur séparé)
- Validation des données de migration de l'héritage v1.0
- Tests de charge au-delà de 1 000 utilisateurs simultanés
Récapitulatif des cas de test :
- Total : 245 cas de test (85 automatisés, 160 manuels)
- Modules : Auth (32), Produits (48), Panier (55), Paiement (70), Admin (40)
- Taux de réussite attendu : 95 % avant l'UAT, 98 % avant le lancement
Risques clés :
- Le bac à sable de l'API Stripe se comporte différemment de la production — atténué en ajoutant des cas de test supplémentaires pour les cas limites
- Les participants à l'UAT sont des membres de l'équipe commerciale avec une disponibilité limitée — 10 participants recrutés, visant 5 actifs
Suivi des bugs :
- BugCapturer utilisé pour tous les rapports de bug
- Bugs critiques : correction sous 4 heures, retest immédiat
- Bugs hauts : correction sous 24 heures, retest le jour même
- Bugs moyens : correction avant le lancement
- Bugs faibles : backlog pour l'après-lancement
Exemple de plan de test : explication des sections clés
Objectifs du test
C'est la section la plus importante. Elle répond à « pourquoi testons-nous ? ». De bons objectifs sont spécifiques et mesurables :- ❌ « Tester le site web en profondeur »
- ✅ « Vérifier que les 20 flux de paiement se déroulent sans erreur sur Chrome, Firefox, Safari et Edge »
Critères d'entrée et de sortie
Les critères d'entrée évitent les efforts gaspillés (ne commencez pas à tester sur une build cassée). Les critères de sortie évitent une validation prématurée (ne déclarez pas les tests terminés quand des bugs critiques sont encore ouverts).Processus de suivi des bugs
Un processus clair de suivi des bugs est essentiel pour une phase d'exécution de tests fluide. Plus les bugs sont signalés vite, plus ils sont corrigés vite. Utiliser un outil comme BugCapturer pendant l'exécution des tests accélère la boucle de retour :- Annotation de captures d'écran — les testeurs peuvent mettre en évidence les problèmes directement sur la page avec des flèches, des rectangles et du texte
- Métadonnées techniques automatiques — l'URL, le navigateur, l'OS, la résolution d'écran et la fenêtre d'affichage sont capturés automatiquement
- Enregistrement d'écran — enregistrez une courte vidéo WebM du bug, puis rognez et extrayez les images clés
- Collecte de données de diagnostic — les erreurs de console et les requêtes réseau ayant échoué sont capturées en complément des preuves visuelles
- Export Excel/TSV — copiez en un clic une ligne de rapport de bug structurée dans votre presse-papiers pour le suivi d'équipe
Comment créer un plan de test
Étape 1 : Comprendre le projet
Lisez les exigences, discutez avec les parties prenantes et comprenez ce qui est en cours de construction. Un plan de test n'est aussi bon que votre compréhension du projet.Étape 2 : Définir le périmètre
Soyez explicite sur ce qui est dans et hors du périmètre. Un périmètre vague est la cause n° 1 des litiges sur les plans de test.Étape 3 : Choisir votre stratégie
Décidez quels niveaux et types de test s'appliquent à votre projet. Un petit site marketing a besoin de tests différents d'une application bancaire.Étape 4 : Estimer les ressources et le calendrier
Utilisez les données historiques des projets précédents. Si vous n'avez pas de données historiques, ajoutez 30 % de marge à vos estimations.Étape 5 : Rédiger le plan
Utilisez le modèle ci-dessus. Commencez avec le modèle, puis personnalisez-le. Ne partez pas de zéro.Étape 6 : Obtenir les approbations
Un plan de test que personne n'a validé est un plan de test que personne ne suit. Obtenez l'approbation écrite du chef de projet et du product owner.Téléchargement : modèle de plan de test
Le modèle ci-dessus fonctionne dans n'importe quel format :
- Google Docs / Word — utilisez la structure de sections comme document formel
- Confluence / Notion — créez une page de plan de test avec des sous-pages pour chaque section
- Excel / Google Sheets — utilisez-la comme une feuille de calcul avec des onglets pour chaque phase
- Markdown — conservez-le dans votre dépôt pour le contrôle de version
Choisissez le format qu'utilise votre équipe. Le format importe moins que le contenu — un bon plan de test dans un document simple vaut mieux qu'un mauvais plan de test dans un outil sophistiqué.