Modèle de plan de test logiciel : modèle gratuit pour Confluence
Un auditeur ou un client pose une seule question sur vos tests : quelles exigences ont été testées, sur quelle version, et avec quel résultat ? Ce modèle de plan de test est construit autour de cette question, avec un tableau de traçabilité à remplir au fil de l’eau.
Plan de test : [Produit] [version]
Rédacteur : [nom] · Approuvé par : [nom, date] · Version testée : [build ou version]
1. Périmètre
Testé : [fonctions, exigences, plateformes]. Non testé : [ce qui ne l’est pas, et pourquoi].
2. Approche
Niveaux de test : [unitaire / intégration / système / recette]. Manuel ou automatisé : [répartition]. Non-régression : [tests rejoués à chaque version].
3. Environnement
[Site ou environnement de test, configuration, données, outils et leurs versions.]
4. Critères d’entrée et de sortie
On commence quand : [build disponible, données prêtes]. C’est fini quand : [tous les tests prévus sont passés, aucun défaut bloquant ouvert, chaque exigence couverte par au moins un test réussi].
5. Rôles
Testeurs : [noms]. Revoit et approuve les résultats : [nom].
6. Traçabilité
| Exigence | Cas de test | Résultat | Défaut |
|---|---|---|---|
| [EX-1] | [CT-1] | [Réussi / Échoué / Non passé] | [lien] |
| [EX-2] | [CT-2, CT-3] | [Réussi / Échoué / Non passé] | [lien] |
7. Rapport et approbation
Bilan : [passés, réussis, échoués, non passés]. Défauts ouverts et leur justification : [liste]. Décision : [livrer / ne pas livrer], par [nom, date].
L’utiliser dans Confluence
- Cliquez sur Copier le modèle, ouvrez une nouvelle page Confluence et collez : titres, listes et tableaux restent en place.
- Remplacez les parties [entre crochets] et supprimez ce qui ne vous concerne pas.
- Pour le réutiliser, enregistrez-le comme modèle d’espace : Paramètres de l’espace › Modèles › Créer un modèle, puis collez.
Là où les plans de test pèchent le plus souvent
- Des exigences jamais testées. Une liste de tests réussis ne dit rien de ce qui n’a jamais été testé. Le tableau de traçabilité rend les trous visibles.
- Des résultats sans version. « Réussi » n’a de sens qu’avec le build sur lequel le test a tourné.
- Pas d’approbation. Pour un logiciel réglementé (par exemple sous l’IEC 62304 pour les logiciels de dispositifs médicaux), quelqu’un doit revoir et approuver les résultats avant la livraison.
À lire aussi : Clearlane Tests et notre aide à la validation.