Duel: plan de test vs répertoire de test

Introduction

Lorsque l’on parle de « plan de test » on arrive rapidement à des incompréhensions. Selon son interlocuteur certaines pensent bien à des plans de test selon l’ISTQB, d’autres pensent à une « stratégie » ce qui reste une notion assez proche… et une très grande partie pense à ce que j’appelle un « répertoire de test » ce qui est totalement différent, un répertoire de test étant l’ensemble des tests écrits et centralisés dans un outil.

Pourquoi cette confusion ?

Cette confusion est selon moi intégralement dû aux outils du test et plus spécifiquement aux ALM. J’ai souvenir de ma première mission avec un outil reconnu du marché en juillet 2012. Je découvrais pour la première fois l’ALM référent de l’époque: HP ALM. Cet outil, tout comme XStudio et Refertest, divisé en plusieurs parties:

  • La partie exigence: qui propose un référentiel d’exigence (qui peut/doit être reliés à des tests)
  • La partie répertoire de test (appelée Test Plan dans ALM): qui répertorie les différents tests
  • La partie campagne de test: qui répertorie les différentes campagnes (chacun contenant une sélection de test pris du répertoire)
  • La partie anomalie: (non présente dans tous les ALM) qui trace les bugs remontés (et peut/doit proposer des liens avec les tests)

La confusion vient justement de la dénomination de ces parties dans certains ALM! Le répertoire de test est nommé Plan de test! Je ne vous raconte pas ma surprise lors de la formation ISTQB fondation quand j’ai appris que plan de test venait de « planification » et que sa définition officielle était très éloignée de celle proposée par les outils!

Quelle différence entre ces termes ?

Ces termes sont totalement différents, le problème ici est surtout la confusion.

Plan de test

Définition du plan de test selon l’ISTQB: 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.

Le plan de test est donc un document dans lequel on décrit, explique comment et quand les tests sont planifiés, exécutés ainsi que leur périmètre.

Un plan de test est spécifique à un projet/produit. Chaque projet/produit peut faire l’objet de plusieurs plan de test avec un plan de test maître coordonnant les autres plans de test appelés « plan de test de niveaux ».

Répertoire de test

Un répertoire de test est un emplacement (souvent dans un outil) dans lequel on va retrouver les/des tests scriptés liés à un projet/produit.

Ce répertoire centralise les tests ce qui permet de plus facilement les maintenir, de les consulter, d’étudier les traçabilité, de gagner du temps lors de la préparation des campagnes. Un répertoire de test peut également proposer un ordonnancement ou une classification des tests afin de faciliter le travail de tous les jours du testeur.

Conclusion

On est ici sur des concepts bien différents qui peuvent mener à des confusions bien réelles. Le terme « répertoire de test » est très peu utilisé au profit du terme « Plan de test » popularisé par les ALM. Au final, il est toujours possible de vivre avec des homonymes, néanmoins il faut garder à l’esprit que pour beaucoup de personnes un « Plan de test » c’est un « répertoire de test » et que pour ces mêmes personnes le « Plan de test » est alors une « Stratégie de test ». La seule manière d’éviter la problématique est alors la communication et bien s’assurer que l’on a la même vision du terme « Plan de test ».

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Outils

Outil de test : gérer ses tests avec REFERTEST

En bref, ce que fait l’outil Refertest est un outil de management de tests concurrent de Squash TM. Il bénéficie d’une interface full web très intuitive. Il permet à notre équipe de tracer et d’historiser facilement les exigences, les cas de tests et les campagnes des différents projets du Groupe

Lire la suite »
Agilité

Écrire des bons BDD

Je travaille sur différents projets dans lesquels les personnes utilisent des outils BDD (Business Driven Developement) comme cucumber ou JBehave. C’est une très bonne idée cela permet, par exemple, d’avoir des spécifications par l’exemple. Néanmoins, ce n’est pas simple d’écrire du BDD ! Dans cet article je vais tenter d’expliquer ce

Lire la suite »