Quand on pense à un plan de test, on imagine souvent des documents qui décrivent en détail tous les aspects possibles d'un projet de test sur de nombreuses pages. Peut-être avez-vous déjà eu à rédiger un tel document ou à contribuer à son élaboration. Pourtant, n'avez-vous pas constaté qu'une fois ce plan de test détaillé finalisé, il était rarement relu sérieusement, voire même jamais par vous ?
Je vais vous présenter un autre type de plan de test qui regroupe tous les aspects pertinents de la gestion de votre projet de test sur une seule page (cf. Fig. 1). L'objectif est de disposer d'un document unique, clair, concis et bien structuré, facile à consulter, à partager et à utiliser comme base de discussion avec les autres parties prenantes du projet. Ce document de planification concis vous guidera dans tous les aspects importants de la gestion de vos activités de test. Vous pouvez facilement le diffuser ou le joindre où vous le souhaitez, sous forme imprimée ou numérique. Comme le James Whittaker : « Nous savons pertinemment que nous n'allons pas tout tester, alors pourquoi tout documenter ? » (cf. référence à la fin).
Quelques domaines pertinents pour le plan de test d'une page
Vous pourriez par exemple aborder les sujets suivants dans votre plan de test d'une page :
- Introduction/Contexte/Objectifs : Décrivez le contexte de vos activités de test, le produit ou les principaux objectifs de votre projet de test.
- Stratégie : Quelle stratégie de test sera principalement appliquée ?
- Dans le périmètre : Il est primordial de bien définir le périmètre de vos tests afin de pouvoir vous concentrer facilement et efficacement sur ces domaines.
- Hors périmètre : Il est tout aussi important de définir les aspects à exclure de votre projet de test. Vous éviterez ainsi de gaspiller du temps et des ressources, et vous vous assurerez d’atteindre les objectifs fixés. Vous pourriez par exemple exclure certains aspects des tests non fonctionnels, tels que la portabilité ou la fiabilité, s’ils ne font pas partie de votre mission de test.
- Risques liés au projet : Tout risque majeur susceptible de nuire à votre projet doit être pris en compte ici, par exemple l’absence soudaine de membres de l’équipe projet, un retard, un dépassement de budget, etc. Au lieu d’une liste de risques spécifiée directement dans cette section, vous pouvez également insérer un lien vers votre gestion des risques ou votre matrice des risques plus détaillée.
- Risques liés au produit : Si un risque n’affecte pas votre projet, mais le produit lui-même, par exemple en diminuant sa qualité prévue, il s’agit alors d’un risque lié au produit. Parmi les autres exemples, citons une mauvaise ergonomie, des fonctionnalités insuffisantes ou une évolutivité inadéquate.
- Conditions/Exigences : Dans cette section, vous pouvez mentionner les conditions nécessaires à la réalisation des objectifs de votre projet. Vous pouvez par exemple lister les conditions d’entrée spécifiques à satisfaire pour lancer la phase de test proprement dite, ou les conditions de sortie pour arrêter les activités de test.
- Ressources/Personnes : Si vous avez besoin de ressources spécifiques, veuillez les indiquer dans cette section.
- Calendrier/Échéancier : Vous pouvez indiquer ici les étapes clés de votre projet et l’échéancier correspondant, sans entrer dans les détails. Vous pouvez vous référer à un calendrier de projet plus détaillé.
- Communication/Interaction : En matière de tests logiciels, une communication appropriée et opportune avec toutes les parties prenantes est essentielle à la réussite de votre projet. Vous pouvez décrire le processus de validation avec les représentants métiers, la gestion des anomalies, le reporting, etc.
- Environnement : Spécifiez les éléments clés de l’environnement nécessaires à la réalisation des tâches de test ou à l’atteinte de vos objectifs, par exemple le système testé, la génération des données de test, le traitement des données sensibles, la gestion des accès, etc.
- Outils : Dans cette section, vous pouvez lister les outils essentiels que vous utilisez dans les processus centraux de votre projet de test.
- Hypothèses/Estimations : Tout élément pertinent pour votre projet et que vous pouvez supposer se produire au moment de la création de votre test peut être mentionné dans cette section.
- Liens : Si vous souhaitez faire référence à d’autres pages ou documents importants dont le contenu ne peut être intégré de manière concise dans cette section, veuillez indiquer brièvement les liens vers ces ressources ici (par exemple : matrice des risques, documents de conception, architecture, liste des cas de test, etc.). Vérifiez si votre public a accès aux ressources liées, le cas échéant. En règle générale, le plan de test d’une page doit être autonome et ne pas contenir trop de liens vers d’autres informations.
- Points en suspens : Au stade du développement initial, il est possible que certains points n’aient pas été suffisamment traités. Par conséquent, n’hésitez pas à soulever des questions importantes qui nécessiteront des éclaircissements prochainement.
- Informations de contact : Incluez vos coordonnées au cas où des personnes souhaiteraient obtenir plus d’informations et de détails sur votre projet de test.
Une fois votre plan de test adapté à votre public cible, vous pourrez déterminer son contenu le plus pertinent et le langage approprié. En intégrant certains des sujets mentionnés ci-dessus dans un plan de test fictif d'une page, très général, cela pourrait ressembler à ceci :
Conseils de formulation
Essayez d'utiliser des phrases courtes, plutôt que des paragraphes entiers ou des listes, pour décrire le contenu pertinent. Selon James Whittaker, il est utile de se concentrer sur :
- Attributs : « adverbes et adjectifs qui décrivent les concepts de haut niveau que les tests sont censés garantir » (rapide, sécurisé, utilisable, etc.).
- Composants : « noms qui définissent les principaux blocs de code constituant le produit » (classes, noms de modules et fonctionnalités de l’application)
- Capacités : « verbes qui décrivent les actions et les activités de l'utilisateur » – très important !
Ces aspects essentiels de la rédaction d'un document concis ne se rapportent pas seulement à l'application ou à l'objet de test, mais au style et au langage de votre plan de test en général.
Aspects de conception
Bien entendu, vous êtes libre d'organiser les sujets rassemblés dans l'ordre et la forme qui vous conviennent le mieux. Il est souvent judicieux de présenter les sujets sous forme de tableau ou de matrice, car cela facilite la lecture du plan de test et permet de bien distinguer les différentes sections.
Vous pouvez regrouper les domaines connexes en un seul afin de limiter le nombre total de champs. Essayez de vous concentrer sur les sujets réellement pertinents pour la gestion de vos tests, afin de ne pas surcharger votre public cible d'informations. Selon la pertinence de chaque domaine, vous pouvez mettre davantage l'accent sur certains sujets si le format de présentation souhaité le permet.
N'utilisez pas une police trop petite afin d'inclure un maximum d'informations dans votre plan de test d'une seule page. Concentrez-vous plutôt sur les aspects les plus pertinents et n'hésitez pas à laisser des espaces vides.
Vous pouvez colorier les zones comme vous le souhaitez pour obtenir l'impression visuelle globale désirée.
Le résultat du travail d'équipe
Selon les spécificités de votre projet, le responsable des tests peut élaborer ce plan de test seul, à condition de disposer de toutes les informations nécessaires. Cependant, un document d'une telle importance est généralement le fruit d'un travail d'équipe étroit. Je vous recommande de faire élaborer ce plan de test d'une page par une équipe restreinte de parties prenantes capables de contribuer aux principaux points abordés. Vous pouvez par exemple organiser un atelier où de petits groupes déterminent les domaines à prendre en compte. Une fois les idées recueillies discutées en réunion plénière, une première version sera élaborée, éventuellement à nouveau en petits groupes, soit sous la forme d'un plan de test complet, soit en répartissant certains points entre les groupes pour un développement ultérieur. Lors d'une séance de clôture, une version finale sera établie.
Durant la durée du projet, les modifications pertinentes doivent être consignées dans le plan de test d'une page. En règle générale, vous n'aurez probablement que rarement besoin de modifier ce document de pilotage concis.
Avantages
En élaborant un plan de test d'une seule page, vous devez vous concentrer sur les aspects les plus pertinents pour un projet de test logiciel et limiter les informations à inclure dans ce document central. L'un des principaux objectifs d'un tel plan est qu'il soit effectivement lu par le public cible et qu'il ne soit pas oublié. Ainsi, vous évitez de gaspiller du temps et des ressources à rédiger des documents qui ne seront pas lus par la majorité des destinataires. Vous pourrez ainsi vous concentrer pleinement sur l'avancement de votre projet de test et atteindre vos objectifs.
Conclusion
Si votre projet de test est géré par un plan de test concis d'une seule page, vous pourrez l'adapter rapidement et efficacement à l'évolution rapide d'un projet logiciel. Ce plan constituera ainsi un guide précieux en toutes circonstances, tout au long du projet. La prochaine fois que vous devrez élaborer un plan de gestion de vos tests, pensez aux nombreux avantages d'un plan de test d'une seule page. Ce document sera consulté régulièrement, ce qui augmentera vos chances d'atteindre vos objectifs de test. Sa concision vous laissera une grande liberté créative. Une fois que vous aurez acquis une expérience positive avec ce type de plan, partagez-la au sein de votre organisation. La gestion des projets de test bénéficiera ainsi largement de votre expertise, et par conséquent, l'assurance qualité dans son ensemble.
Ressources supplémentaires
Vous trouverez de nombreux conseils pour concevoir votre plan de test d'une page dans l'article « The One Page Test Plan » de Claire Reckless sur site Ministry of Testing. Visionnez également la courte et inspirante vidéo « On Test Plans » d'Ilari Henrik Aegerter (PDG de House of Test). Un article intéressant, « The 10 Minute Test Plan », met davantage l'accent sur la création rapide d'un plan de test pratique.
Pour toute question concernant la gestion des tests, les tests agiles, le DevOps, l'automatisation des tests, l'intégration d'outils de test ou les produits Atlassian, nous serons ravis de vous aider. N'hésitez pas à nous contacter.
