Un plan de test explique ce qui sera testé, pourquoi, comment, par qui et dans quelles conditions. Sa valeur vient d’une compréhension partagée de l’approche et des limites plutôt que de la longueur du document.
Quand un plan de test est utile
- →La fonctionnalité est vaste, risquée ou s’étend sur plusieurs équipes.
- →La portée, les priorités, les environnements, les rôles et les critères de préparation nécessitent un accord explicite.
- →Les attentes externes incluent les audits, la conformité, la réglementation ou les rapports formels.
- →Sans plan convenu, l’équipe peut interpréter différemment la profondeur et les limites des tests.
Ce que comprend un bon plan
- →Objectifs des tests et principaux risques.
- →Portée incluse et exclue.
- →Types et niveaux de tests applicables.
- →Environnements, données de test et dépendances.
- →Rôles, responsabilités, calendrier et critères d'achèvement.
Ce qu'il faut éviter
- →Modèles génériques déconnectés du produit.
- →Excès d’informations que personne n’utilise.
- →Un document statique écrit une seule fois et jamais mis à jour.
- →Remplacer la réflexion réelle sur les risques et la stratégie par de la paperasse.
Conseils pratiques
Un bon plan répond à de vraies questions : qu'est-ce qui est critique, où se situent les risques, ce qui reste en dehors des tests, ce qui manque pour la qualité et quelles preuves appuieront la publication. Si cela n’aide pas à prendre des décisions, c’est trop lourd ou trop abstrait.
Exemple rempli : une petite version de formulaire de paiement
Toutes les hypothèses de ce plan sont fictives et pédagogiques. Il ne s’agit pas d’un rapport sur une banque, un client ou une version livrée. L’application accepte des jetons de paiement synthétiques et appelle un simulateur local du prestataire (stub), qui renvoie une approbation, un refus ou une expiration du délai. Aucune donnée de carte, aucun compte et aucun argent réels ne sont utilisés. Les montants sont exprimés en centimes entiers dans une devise de démonstration explicitement configurée.
ID du plan : PAY-DEMO-1 ; version : 1 ; responsable : ingénieur QA
Objectif : valider le formulaire de paiement et empêcher les paiements réussis en double.
Objet des tests : un build de démonstration figé ; relever son commit et sa configuration réels avant l’exécution.
Périmètre inclus : envoi, validation, réponses du prestataire, répétition de requêtes et de callbacks, actualisation de la page de résultat, clavier et affichage à 375 px.
Hors périmètre : prestataire réel, règlement réel, remboursements, abonnements, 3-D Secure, autres devises, certification de charge ou de sécurité.
Environnement : application locale jetable + simulateur du prestataire (stub) + base de test préremplie.
Données : nouveau client et nouvelle commande synthétiques par cas ; réinitialiser le journal du stub entre les cas.
Observation : ID de requête, journal des paiements du stub et lecture seule des commandes.
Intervenants : un ingénieur QA ; un développeur disponible pour les correctifs ; le responsable produit décide du risque résiduel accepté.
Estimation, sans engagement : deux journées de 6 heures QA chacune ; 2 heures d’assistance développeur et 1 heure de revue par le responsable.
Livrables : correspondance exigences/cas, journal d’exécution, preuves sans données sensibles, défauts et recommandation de livraison.Périmètre basé sur les risques avec des résultats observables
Les cas C01–C08, C11 et C12 sont à haut risque dans cet exemple : un paiement en double, un montant erroné, un faux succès ou une répétition mal gérée peuvent corrompre l’état financier. C09–C10 vérifient l’utilisabilité et restent dans le périmètre. Les résultats ci-dessous décrivent les exigences de démonstration, pas un comportement universel des API de paiement.
ID Scénario Résultat attendu
C01 Jeton approved Une commande confirmée de 1999 centimes ; un paiement accepté
C02 Jeton declined Message de refus ; aucune commande payée ni aucun paiement réussi
C03 Jeton timeout État en attente/inconnu affiché ; aucun second paiement automatique
C04 Même clé, même corps envoyé deux fois Même résultat enregistré ; un paiement et une commande
C05 Même clé, montant modifié Conflit signalé ; aucun nouveau paiement ni aucune nouvelle commande
C06 Jeton de paiement absent Erreur de champ ; aucune requête de paiement
C07 Montant nul reçu par le serveur Refus par l’API ; aucun paiement ni aucune commande
C08 Callback approved reçu en double Une seule transition vers payé ; un seul succès dans le registre des paiements
C09 Clavier uniquement Tous les contrôles sont accessibles ; envoi et erreurs utilisables sans souris
C10 Fenêtre de 375 px Aucun débordement horizontal ; total et bouton d’envoi visibles
C11 Actualiser la page de résultat Commande existante affichée ; paiement non renvoyé
C12 Inspecter une transaction de 1999 centimes Même montant et même devise dans l’UI, la requête et la commande enregistréeCritères d'entrée, de suspension et de sortie
Entrée : les 12 résultats attendus ont été revus ; le build est identifié ; les modes approved/declined/timeout du stub sont vérifiés ; le client de test est créé ; le journal des paiements est lisible ; les tests smoke de l’environnement passent. Si un critère échoue, consignez le blocage au lieu d’annoncer une version entièrement testée.
Suspendez les tests si le journal est indisponible, si l’environnement de test ne peut pas être réinitialisé ou si des paiements en double compromettent les cas suivants. Conservez les preuves. Reprenez après correction de la cause, réussite des tests smoke de l’environnement et réinitialisation puis réexécution des cas concernés.
Sortie permettant une recommandation : les 12 cas sont exécutés avec preuves ; les 10 cas à haut risque passent ; C09 et C10 passent ou disposent d’une exception documentée par le responsable nommé ; aucun défaut ouvert ne provoque de paiement réussi en double, de montant erroné ou de faux statut de paiement ; chaque défaut à haut risque corrigé est retesté et les tests de régression concernés passent. Signalez explicitement toute fonction exclue. Une échéance ne suffit pas à satisfaire ces critères.
Exemple de calendrier : jour 1 — revue des exigences 1 h, environnement et données 1 h, préparation des cas 2 h, exécution 2 h. Jour 2 — exécution restante 2 h, correctifs et retests 2 h, régression concernée 1 h, synthèse 1 h. Si le comportement du prestataire change ou si le build est remplacé, réestimez et réexécutez les vérifications concernées ; ne conservez pas silencieusement les anciens statuts de réussite.
Modèle de plan copiable
Plan / version / responsable :
Modification et objectif métier :
Objet des tests / build / configuration :
Exigences et principaux risques :
Périmètre inclus / exclu :
Environnement / données synthétiques / procédure de réinitialisation :
Mécanismes d’observation et preuves :
ID des cas associés aux risques et résultats attendus :
Rôles / capacité / estimation / dépendances :
Critères d’entrée :
Critères de suspension / reprise :
Critères de sortie et responsable de la décision :
Risques résiduels / exceptions / prochaine date de revue :
Lien vers le rapport d’exécution :Ce document définit le travail à effectuer ; il ne prétend pas que les douze cas ont réussi dans une véritable application de paiement. Pendant l’exécution, ajoutez à chaque cas les résultats, statuts, preuves et défauts réels. Transmettez au responsable de la décision de livraison la couverture et les risques restants, pas seulement un taux de réussite.
Pour aller plus loin
Relier le plan de livraison à la stratégie de test
Organiser les tests de release