Le plan de test d’un logiciel

L’International Software Testing Qualifications Board (ISTQB), l’un des principaux systèmes indépendants de certification professionnelle de test de logiciels les plus établis dans le monde, décrit le plan de test comme étant : “une documentation décrivant les objectifs de test à atteindre et les moyens et le calendrier pour les atteindre, organisée pour coordonner les activités de test.”

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

Le plan de test peut donc être considéré comme un manuel. Il décrit les objectifs des tests (ce qu’il faut vérifier et/ou valider), la portée des tests (ce qui sera et ne sera pas testé), ainsi que le calendrier général voire détaillé des activités à effectuer (comment le tester et quand le tester).

Bien qu’il existe différents types de test, tous les plans de test doivent répertorier les risques prévus dans le projet (que ce soit pour le développement d’applications, d’un logiciel ou encore d’un site web) et leurs niveaux respectifs afin que les tests puissent être hiérarchisés par risque.Une des parties les plus importantes d’un plan de test est la définition des ressources nécessaires pour le projet, qu’elles soient humaines (personnes impliquées) ou techniques (environnements de test, outils de test et les données de test).

Comment bien rédiger ce document ?

Un éditeur de document et un tableur seront souvent le combo utilisé. Le document principal contiendra la plupart du temps les informations suivantes :

• Cadre : objectifs qui vont être validés ; 
• Hors cadre : définition claire de ce qui ne sera pas testé ;
• Prérequis : toutes les conditions nécessaires au bon déroulement ;
• Plannings des processus et des actions à tester ;
• Rôles et responsabilités : liste des différents membres d’équipes avec leur fonction et leurs attributions ;
• Livrables : documents produits avec l’analyse des données, les résultats obtenus et à quels moments ;
• Environnement : environnement cible de test, utilisateurs, responsables ;
• Systèmes et outils : comme les bugs tracker par exemple ;
• Gestion des défauts : protocole de communication et d’escalade ;
• Risques et gestion des risques ;
• Critère d’arrêt.

Idéalement le document principal restera aussi peu détaillé que possible. Il pointera vers d’autres documents (feuilles de tableur par exemple) qui contiennent les informations détaillées les activités à tester (plannings, détail des tests etc.).Le but premier étant de maintenir un modèle de plan de test aussi résilient et flexible que possible face aux changements, évolutions et scénarios possibles. La seconde raison est d’alléger au mieux le plan de test afin de le rendre plus digeste. Comme tout document en entreprise, plus il sera volumineux, moins cela incitera les gens à le lire. Ce qui à terme pourra éventuellement mener à sa disparition.

Comment assurer la bonne exécution du plan élaboré ?

Dans cette optique d’allègement et de lutte contre le désintérêt sont apparus au fil du temps des propositions permettant d’aller à l’essentiel sans se perdre dans une prose souvent inutile.

10 Minute Test Plan

Le “10 minute test plan” était une expérience tentée par un directeur de test chez Google qui a mis au défi ses équipes de rédiger un plan de test en 10 minutes avec comme prédicat : “Si les plans de tests ont une quelconque valeur, allons les chercher le plus rapidement possible”.

Les résultats ont montré qu’aucune équipe n’a terminé en 10 minutes mais l’essentiel était couvert, avec 20 minutes supplémentaires 80% du travail était réalisé en remplaçant les paragraphes par des phrases simples, des listes, des tableaux et en laissant de côté les éléments sujets aux changements quasi inévitables d’ici le début des tests (environnement, plannings, architecture etc.).

Enfin, ce scénario de test en conclut que “ne faire que ce qui est absolument nécessaire et laisser les détails aux exécuteurs de test plutôt qu’aux planificateurs de test.”

One Page Test Plan

Suivant la même idée, l’exécution de la stratégie de “one page test plan” vise à créer un plan de test en une seule page en supprimant le superflu tout en se focalisant sur l’essentiel :

• Le produit et les fonctionnalités testées ;
• Ce qui est dans le cadre ou hors cadre ;
• Les risques à prévoir ;
• Les prérequis et exigences ;
• Les outils utilisés ;
• Les environnements de test ;
• Les ressources exploitées ;
• Les estimations des résultats.

On retrouve peu ou prou les thèmes abordés plus tôt mais ils seront idéalement présentés sous la forme d’un Dashboard de performance très synthétique, agréable et rapide à lire.

Que faut-il retenir du plan de test ?

Il n’existe bien évidemment pas de plan de test parfait qui correspondra à tous les projets ni à tous les utilisateurs. En effet, le test d’une application mobile ou d’un logiciel n’auront pas les mêmes enjeux. Ainsi, ce n’est pas les mêmes types de fonctionnalités à tester ou les mêmes résultats qu’on va interpréter.

Il faudra passer du temps à communiquer avec les personnes impliquées afin de savoir ce qu’il sera nécessaire de faire apparaître ou non et sous quel format car au final ce sont ces personnes qui devront s’en servir donc autant que cela réponde à leur besoin. Le plus important est de lister clairement les différents éléments à tester car cela vous permettra de structurer votre organisation sous forme de tâches distinctes.

Bon savoir : La différence entre une fiche de test et un plan de test est assez subtile. La fiche de test présente la stratégie d’un projet dans sa globalité. Alors qu’un plan de test va détailler les différents éléments à tester, ainsi que les processus à suivre.