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.
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 :
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 :
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.
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 :
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.
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.
Recevez GRATUITEMENT le Guide Pratique du Chef de Projet Performant
👉 Suivez une méthodologie claire pour gérer vos projets de bout en bout
👉 Améliorez votre efficacité opérationnelle en utilisant les bons livrables au bon moment
👉 Suivez 25 conseils d'expert et arrêtez de subir les dérives
Vous recevrez régulièrement des contenus intéressants. Vos données seront en lieu sûr, nous détestons le spam sans doute autant que vous, et vous pouvez vous désinscrire à tout moment. Voir notre politique de confidentialité.
