Rediger un plan de test
22 avril 2018

Licence Creative Commons

Selon l'Institute of Electrical and Electronics Engineers (IEEE), un plan de test est un document qui décrit l'étendue, l'approche, les ressources et la planification des activités prévues. Sa rédaction s'effectue généralement juste après la phase d'analyse des exigences.

Il existe deux types de plan de test :
  • Le plan de test maître qui a pour but de décrire la stratégie de test sur un projet particulier.
  • Le plan de test de phase qui a pour but de décrire de manière détaillé les activités à mettre en œuvre pour chaque niveau de test.

En fonction du contexte, le plan de test maître et le plan de test de phase peuvent former un seul et même document. D'après le standard IEEE 829-2008, ce document peut être structuré comme ci-dessous :



01. Identifiant

Il permet d'identifier le document sans ambiguïté. Il s'agit le plus souvent d'un identifiant alphanumérique. Cet identifiant doit être unique. Pour un meilleur suivi des modifications, le plan de test doit contenir un historique de révision avec la date, la description et l'auteur de la modification.


02. Référence

La partie « Références » a pour but de lister les documents qui ont permis la rédaction du plan de test. Il peut s'agir de documents externes ou internes à l'organisation. Le dossier de spécifications fonctionnelles détaillées ou le cahier des charges sont des exemples de document qui peuvent être listé dans cette partie. L'emplacement de chaque document doit être indiqué.


03. Introduction

Il contient les objectifs et un résumé des informations que donnera le plan de test. Cette partie peut également contenir une brève description du produit et une explication du contexte. Le rôle des parties prenante concernés par la rédaction du plan de test doit être évoqué.


04. Eléments à tester

Il s'agit tout simplement de la liste des matériels et des logiciels à tester. Cela correspond à ce qui sera livré avec le produit et non les fonctionnalités fournies par le produit.


05. Fonctionnalités à tester

Cette partie décrit les caractéristiques fonctionnelles et non fonctionnelles qui doivent être testées. Il contient les références aux documents de spécification des exigences.


06. Fonctionnalités à ne pas tester

Ce sont les caractéristiques fonctionnelles et non fonctionnelles qui ne seront pas testées. Dans cette partie, les raisons expliquant pourquoi ces fonctionnalités ne seront pas testées doivent être décrites.


07. Approche stratégique

Il s'agit de la stratégie globale qui sera utilisé pour tester le produit. C'est dans cette partie que seront décrits le processus de gestion des anomalies, les types et les niveaux de test, les dispositifs de suivi et de contrôle des activités de test, etc


08. Critères de succès et d'échec

Cette partie décrit les critères à utiliser pour déterminer si une campagne de test est un échec ou un succès. On peut par exemple considérer qu'une campagne avec 98% de test à l'état réussi et deux bugs cosmétiques est une réussite.


09. Reprise et suspension

Dans cette partie, il faut spécifier les critères à utiliser pour suspendre ou reprendre les activités de test. Il faut également décrire les tâches à réexécuter en cas de reprise.


10. Environnement et outils

Il s'agit de lister les outils et les matériels nécessaires à l'exécution des tests et éventuellement de décrire le fonctionnement de l'infrastructure.


11. Rôles et répartition des tâches

Il faut identifier les tâches nécessaires à la préparation et à l'exécution des tests et indiquer les personnes responsables de chaque tâche.


12. Besoins en formation

Il s'agit de déterminer les compétences et les besoins en formation. Cela peut inclure les formations sur l'utilisation de l'application à tester et des formations sur l'utilisation d'outils et de méthodes.


13. Planning des activités

Il s'agit d'établir un planning pour les différentes activités de test.


14. Risques et contingences

Il s'agit d'identifier les contraintes et les risques important qui peuvent survenir durant l'exécution des activités de test. Il faut définir un plan d'urgence pour chaque risque.


15. Livrables

Il s'agit d'identifier tous les livrables qui seront produits au cours des activités de test, par exemple les cas de test, les rapports d'anomalies, les rapports de test, les fichiers logs.


16. Approbation

Il contient la liste des personnes qui doivent lire et approuver le plan de test. Les approbations doivent être datées et signées.


17. Glossaire

Cette partie doit fournir une définition des termes, des abréviations et des acronymes utilisés dans le plan de test.



Remarque :

Pour la rédaction des plans de test, il existe une autre norme beaucoup plus récente:  ISO/IEC/IEEE 29119-3 (Part 3) - Test Documentation



A lire aussi:

Références: