Comment rédiger et implémenter un plan de test? (+Modèles)

Le plan de test est l’application tactique d’une stratégie de test à un projet ou un domaine donné. Il a pour rôle de préciser les conditions d’applications, le contexte de test, et les acteurs impliqués dans le test.

Il s'agit d'un document conçu pour être utilisé directement en production, et qui contient toutes les informations nécessaires pour être mis en place dans le cadre d'une recette de logiciel.

Dans cet article, nous allons voir ce qu’il contient, comment le construire, le mettre en application, et l’utiliser dans le cadre d’une certification qualité.

Qu’est-ce qu’un plan de test ?

Selon l’ISTQB, il s’agit d’un document décrivant l'étendue, l'approche, les ressources et le planning des activités de test prévues.

Il identifie, entre autres, les éléments et caractéristiques à tester, qui fera chaque tâche, le degré d'indépendance des testeurs, l'environnement de test, les techniques de conception des tests et les techniques de mesure des tests à utiliser, et tout risque nécessitant des plans de contingence. 

C'est un document reprenant les processus de planification des tests, d'après le standard IEEE 829.

kit du chef de projet 0923
outils du chef de projet 0923

Modèle de plan de tests

Téléchargez ce modèle pour donner une structure et un cadre à l'élaboration de votre plan de tests en l'adaptant à votre projet :

Télécharger ce modèle de plan de tests


Que contient un plan de test ?

Le plan des tests contient tout ce qui permet d’exécuter des tests en garantissant l’unicité et la traçabilité de la série de tests dont il se compose.

Nous y retrouvons ainsi les éléments suivants :

1. Une introduction ou fiche descriptive

Cette partie permet de comprendre le pourquoi de la série de tests à exécuter et le fonctionnel que nous allons valider.

C’est dans cette partie que les versions, spécifications, recueils d’exigences seront précisés.

2. Une description du "scope" et du "out of scope"

La description du « scope » (ou périmètre) explicite ce qui sera testé, les configurations prises en compte, les jeux de données et segments clientèle représentatifs. 

La description du « out of scope »  (ou hors périmètre) explicite ce qui ne sera pas testé.

Elle précise bien les conditions aux limites des tests effectués pour permettre d’identifier les risques

3. Une analyse des risques que permettent de couvrir les tests exécutés

Ces risques sont issus de la stratégie de tests. Cette partie est extrêmement importante, car elle permet également de mettre en avant le « risque résiduel », c’est-à-dire les risques résultants du fait de ne pas avoir réalisé certains tests. 

4. Les ressources matérielles et horaires nécessaires à sa réalisation

La bonne réservation et mise à disposition de ces ressources est une garantie que les tests seront exécutés dans les conditions prévues, et permettront donc d’obtenir un résultat fiable, reproductible et conformes aux exigences de qualité de l’organisation.

5. Les outils et environnements nécessaires à l’exécution des tests

Cette partie permet aux équipes de planifier la préparation de l’ensemble des ressources nécessaires à l’exécution du plan de test, les conditions de démarrage de la campagne, les outils à mettre en œuvre, licences, …

En complément, évaluer la maturité des tests logiciels de l'organisation facilite la sélection des outils et la planification des ressources, en déterminant le niveau d'automatisation des processus de test à implémenter. 

Dans ce contexte, il est utile d'avoir des compétences validées par la certification ISTQB pour gérer des déploiements automatiques à lancer avant ou pendant les tests.

Les actions à réaliser en fonction des résultats peuvent être indiquées.

Ci-après un schéma qui résume les composantes du plan de test :

composantes du plan de test

Conception du plan de test

Le plan de test découle de deux (parfois trois) documents :

  • La stratégie de tests, établie par le projet, et donc de l’analyse de risques, qui inclut une évaluation du niveau de maturité de l’organisation en termes de capacités de test
  • L’analyse fonctionnelle, ou encore les user stories et fonctionnalités, qui permettent de définir les contextes à tester et les chemins utilisateurs à valider
  • Les documents techniques, qui permettent d’établir les critères techniques (accessibilité, tenue à la charge, sécurité) nécessaire à une couverture complète du contexte de test par les tests

On dispose également parfois d’un plan de test « maître » servant de guide à la construction des plans de tests spécifiques. 

Le schéma ci-après illustre le positionnement hiérarchique du plan de test :

politique stratégie et plan de test

Dans les projets classiques, le plan de test est construit en parallèle des documents de spécification et servira à valider les développements une fois l’ensemble des implémentations terminées.

En Agilité, ces plans de tests sont souvent associés beaucoup plus directement aux user stories ou fonctionnalités pour pouvoir être exécutés rapidement et être automatisés, ce qui permet à la fois un temps de cycle très faible et la mise en place progressive des tests de régression.


interaction entre testeur outils et intégration

L’exécution des tests est ici réalisée par une intégration continue mettant en œuvre des outils de test logiciel. Cette intégration continue est parfois remplacée par des opérations manuelles (le testeur étant amené à déployer le logiciel, lancer les outils, injecter les données, réaliser la configuration, et parfois saisir le résultat de l’exécution des tests).

Podcast : Utiliser l'IA pour améliorer les tests logiciels

Ecoutez ce podcast pour découvrir comment intégrer l'intelligence artificielle pour améliorer les tests logiciels :

le kit du chef de projet 0923
outils du chef de projet 0923

Et le « One page test plan ? »

La mise en place d’un plan de test peut être longue et fastidieuse, tout en masquant les risques les plus importants.

Le principe du one page test plan est simple : faire tenir l’ensemble des rubriques sur une page (en général un format A4) comme celui fourni avec cet article.

modèle one page test plan

Mise en application

La mise en application d’un plan de tests consiste à mettre en place les conditions nécessaires, réunir les ressources, et exécuter les tests. Ces opérations peuvent être partiellement ou totalement automatisées, et être assistées par un ALM, ou outil de suivi des campagnes de tests.

Le plan de test est considéré lorsque tous les tests ont été exécutés, ignorés, que les rapports ont été générés et que les risques résiduels ont été évalués, comme le montre le schéma ci-après :

Ces résultats et rapports permettront ensuite de prendre la décision de valider ou pas l’intégration du périmètre testé dans la solution développée et/ou de la déployer en production.

Traçabilité et certifications

Une fois les plans de tests exécutés et les résultats publiés, ils sont en général archivés et regroupés en conservant le lien avec la version produite du logiciel. 

Les plans de tests, et leurs résultats qui sont consignés dans un cahier de recette, constituent une « preuve » au sens de l’ISO 9001 permettant lors d’un audit de prouver que tout est mis en œuvre pour délivrer au client un produit répondant à ses exigences dans des conditions optimales de maintenabilité et d’opérabilité. 

Ils peuvent constituer une preuve juridique en cas de conflit ou de défaillance d’un logiciel entraînant des conséquences. Ce sont donc des éléments extrêmement importants.

Conclusion

Élément intermédiaire entre la stratégie de test et les tests, les plans de test sont l’élément structurant de la validation d’un incrément de valeur dans le domaine du développement logiciel. Ils contiennent toutes les informations nécessaires et permettent de produire les preuves de validations utilisées pour garantir la maîtrise qualité d’un logiciel.

David Rochelet

A propos de l'auteur

David est expert en tests logiciels, mentor et entrepreneur dans le domaine du développement et du test logiciel depuis plus de dix ans.
Une solide expérience au sein de projets critiques (contrôle aérien, nucléaire) ainsi que dans la construction de stades dans des conditions très spécifiques, lui permettent aujourd'hui d'accompagner équipes et clients afin de livrer de manière fiable et rapide des projets très complexes.
En savoir plus sur David et ses publications

Les autres articles du dossier 

{"email":"Adresse email invalide","url":"Url du site invalide","required":"Champ obligatoire non renseigné"}

Guide GRATUIT du chef de projet

25 points clés que la plupart des chefs de projet négligent dans la gestion de leurs projets (+ concepts et notions clés).

>