Comment Écrire un Plan de Test: Modèle et Exemples Réels

Un plan de test répond à une seule question : comment allons-nous tester ça ? La réponse va plus loin que "on va lancer des tests Selenium". Elle précise quoi sera testé, par qui, quand, avec quelles données, et à quoi ressemble "terminé".

Ce qu'est (et n'est pas) un plan de test

Ce que c'est :

Un document qui définit le périmètre, l'approche et les ressources pour tester une fonctionnalité ou une release
Un support de communication entre QA, développeurs et parties prenantes
Une référence pendant les tests pour que tout le monde sache ce qui devait se passer

Ce que ce n'est pas :

Une liste de cas de test (c'est un document différent)
Une garantie qu'aucun bug ne sera livré
Quelque chose qui a besoin de 40 pages

Un plan de test d'une page pour une petite fonctionnalité est parfaitement approprié. L'objectif est la clarté, pas la longueur.

Les sections fondamentales

1. Fonctionnalité ou système sous test

Qu'est-ce qu'on teste exactement ? Soyez précis.

Vague :

Tester le processus de paiement

Précis :

Tester le flux de paiement pour les utilisateurs enregistrés : panier → adresse de livraison → paiement (Stripe) → confirmation de commande. Exclut le checkout invité (testé séparément) et les remboursements (pas encore implémentés).

2. Objectifs

Qu'essaie-t-on d'accomplir avec cet effort de test ?

Exemple :

- Vérifier que les utilisateurs enregistrés peuvent finaliser des achats de produits physiques

- S'assurer que le traitement des paiements s'intègre correctement avec Stripe dans les scénarios de succès et d'échec

- Confirmer que les e-mails de confirmation de commande sont envoyés dans les 2 minutes suivant l'achat

- Valider que le stock est correctement décrémenté après un achat

3. Périmètre

Dans le périmètre :

Inscription et connexion des utilisateurs
Ajout d'articles au panier
Application de codes de réduction
Paiement par carte bancaire
Page de confirmation de commande
E-mail de confirmation de commande

Hors périmètre :

Intégration PayPal (Phase 2)
Checkout invité (fonctionnalité séparée)
Retours et remboursements
Application mobile (plan de test séparé)

C'est la section la plus importante à rédiger avec soin. Le glissement de périmètre dans les tests est aussi réel que dans le développement.

4. Approche de test

Comment les tests seront-ils menés ?

Exemple :

| Type | Approche | Qui |

|------|---------|-----|

| Tests smoke | Manuel, avant la régression | Équipe QA |

| Tests fonctionnels | Cas de test manuels | Équipe QA |

| Tests API | Automatisés avec Playwright | QA automatisation |

| Régression E2E | Automatisée avec Playwright | QA automatisation |

| Performance | Tests de charge avec k6 | DevOps |

| Exploratoire | Session de 2h par sprint | Équipe QA |

5. Environnement de test

Où les tests auront-ils lieu ?

Environnement: Staging (https://staging.myapp.com)
Données: Base de données staging fraîche alimentée avec des données de test
Navigateur: Chrome (principal), Firefox (régression)
Mobile: iOS Safari via BrowserStack (smoke uniquement)

Identifiants API: Clés Stripe en mode test
Carte Stripe test: 4242 4242 4242 4242
Carte refusée: 4000 0000 0000 0002

6. Données de test

Quelles données doivent exister avant le début des tests ?

Utilisateurs :

3 utilisateurs enregistrés avec différents rôles (admin, membre, lecteur)
1 utilisateur avec une méthode de paiement sauvegardée
1 utilisateur avec une méthode de paiement expirée
Cas limite : utilisateur avec un nom très long (pour tester la troncature des formulaires)

Produits :

Produit standard (en stock)
Produit épuisé
Produit avec code de réduction appliqué
Produit numérique (sans livraison requise)

Codes de réduction : SAVE10 (10 % de réduction, actif), SAVE50 (50 % de réduction, actif), et EXPIRED99 (expiré, ne doit pas s'appliquer).

7. Évaluation des risques

Quelles sont les zones les plus à risque ? Qu'est-ce qui pourrait mal tourner ?

|--------|------------|--------|-----------|

Risque plus élevé = couverture de tests plus importante nécessaire.

8. Critères d'entrée et de sortie

Critères d'entrée (les tests peuvent commencer quand) :

Toutes les fonctionnalités dans le périmètre sont déployées en staging
Les tests smoke passent
Les données de test sont configurées
La documentation API est à jour

Critères de sortie (les tests sont terminés quand) :

Tous les cas de test haute priorité passent
Aucun bug P1 ou P2 ouvert
Les tests de performance passent (chargement de page inférieur à 2s)
La suite de régression passe

9. Planning des tests

| Activité | Début | Fin | Qui |

|---------|-------|-----|-----|

10. Gestion des défauts

Comment les bugs seront-ils suivis ?

Outil: Jira
Projet: CHECKOUT
Labels de priorité: P1 (bloquant), P2 (majeur), P3 (mineur), P4 (cosmétique)

P1 bloquants: Arrêter les tests, corriger immédiatement
P2 majeurs: Corriger avant la release
P3 mineurs: Corriger dans le prochain sprint si possible
P4 cosmétiques: Ajouter au backlog

Modèle de rapport de bug:
- Environnement
- Étapes de reproduction (numérotées)
- Résultat attendu
- Résultat réel
- Capture d'écran/vidéo
- Navigateur/OS

11. Rôles et responsabilités

| Personne | Rôle |

|---------|------|

| Anna Smith | Lead QA : plan global, validation finale |

| Bob Jones | Ingénieur QA : rédaction des cas de test, tests manuels |

| Carol Wu | QA Automatisation : scripts Playwright |

| Dave Kim | Développeur : corrections de bugs, questions techniques |

| Eve Brown | Chef de produit : exigences, critères d'acceptation |

Un plan de test complet et concis

Voici à quoi ressemble un vrai plan de test pour une petite fonctionnalité : l'édition du profil utilisateur.

Plan de test : Édition du profil utilisateur Version 1.0 | Auteur : Équipe QA | Date : 2026-01-15 Fonctionnalité : Les utilisateurs peuvent modifier leur nom d'affichage et leur avatar depuis leur page de profil. Périmètre :

Dans le périmètre : changement de nom, upload d'avatar (JPEG/PNG, max 5 Mo), validation du nom
Hors périmètre : changement d'e-mail (nécessite une vérification d'e-mail, plan séparé), changement de mot de passe

Approche de test :

Tests fonctionnels manuels du chemin heureux et des cas limites, tests API de l'endpoint PUT /api/users/{id}, et régression automatisée pour les flux critiques.

Environnements : Staging avec comptes de test pré-alimentés Données de test nécessaires :

Compte utilisateur avec avatar existant, compte utilisateur sans avatar, et plusieurs images de test (JPEG valide à 2 Mo, PNG valide à 4 Mo, surdimensionné à 10 Mo, et un PDF invalide).

Risques : la limite de taille de fichier est souvent appliquée uniquement côté client. Tester aussi la validation côté serveur, ainsi que le comportement quand l'upload S3 échoue. Critères de sortie : Tous les bugs P1/P2 fermés, nom et avatar mis à jour correctement pour tous les cas de test, suite de régression au vert

C'est tout. Un bon plan de test tient sur une page.

Erreurs fréquentes

Trop vague : "Nous allons tester la fonctionnalité de connexion." Comment ? Tous les navigateurs ? Tous les rôles utilisateur ? API uniquement ? UI uniquement ? Trop long : Un document de 20 pages que personne ne lit n'est pas utile. Si les parties prenantes ne le lisent pas, il ne communique rien. Pas de section périmètre : Sans éléments explicitement hors périmètre, chaque partie prenante suppose que sa fonctionnalité est couverte. Pas d'évaluation des risques : Vous passerez autant de temps sur les zones à faible risque qu'à haut risque au lieu de prioriser. Pas de critères de sortie : Comment savoir quand c'est terminé ? "Quand on n'a plus de temps" n'est pas un critère de sortie.

Résumé

Un plan de test couvre :

1. Ce qui est testé (et ce qui ne l'est pas)

2. Comment ce sera testé (manuel, automatisé, exploratoire)

3. Où les tests ont lieu (environnements)

4. Quelles données sont nécessaires

5. Quels risques existent et comment les atténuer

6. Quand les tests commencent et se terminent (critères d'entrée/sortie)

7. Qui est responsable de quoi

Restez court et précis. Un plan de test d'une page que tout le monde lit vaut infiniment plus qu'un document de 20 pages qui dort dans un dossier.