Dans la taverne il est fréquent de trouver des articles traitant des plan de test. Le sujet a été abordé de plusieurs manières que cela soit pour le présenter, l’imager, expliquer sa place au sens ISTQB ou dans la série « duel« …
Il reste néanmoins un axe sur lequel la plan de test n’a pas été traité et qui est selon moi essentiel. Cet axe c’est: comment utiliser cet outil!
Le plan de test est un outil très puissant. Néanmoins, comme tout outil, il peut être tout à fait inutile!
Les cas où le plan de test est inutile
Le plan de test a beau être un outil très puissant, il est, dans la grande majorité des cas où je l’ai observé, inutile… voire contre-productif.
Ces cas fréquents sont:
- Lorsque le plan de test n’est qu’un document parmi d’autre qui n’est présent que parce qu’il doit être présent. Il est alors qu’une suite de mot dans un coin et ignoré de tous.
- Lorsque le plan de test n’est pas partagé, c’est à dire qu’il est écrit par les testeurs mais non connus, suivis ou accepté par les autres acteurs du projet. Dans ce cas il ne sert à rien car le plan de test se doit d’impacter tous les acteurs pour être efficace
- Lorsque le plan de test n’évolue pas. Les tests dépendent du contexte, le contexte évolue, le plan de test le doit aussi. Son manque de maintien ne peut qu’engendre un délaissement. Ce manque de maintien peut être engendré par plusieurs facteurs. Les plus fréquents sont: un fichier trop complexe à maintenir, un fichier trop long à maintenir, une manque de compréhension du plan de test
Il y a évidemment d’autres cas pour lesquels le plan de test est inefficace. Pour avoir un plan de test efficace, comme pour tout outil, il faut savoir l’utiliser… Hors même si le plan de test est un outil très puissant, il reste un outil qui n’est pas forcément simple à utiliser
Les cas pour lesquels le plan de test apporte énormément
Je vois personnellement le plan de test comme un outil de communication, un outil de synchronisation, un outil offrant de la visibilité… voire même un outil permettant une intégration aisée de nouveaux acteurs.
Pour qu’un plan de test soit efficace il faut:
- que le plan de test soit initié par des testeurs, amélioré, validé et adopté par l’ensemble des autres acteurs. Le plan de test impacte l’ensemble des acteurs, les développeurs, les testeurs, les analystes métiers… Le plan de test ne peut donc être efficace que lorsque tout le monde s’est mis d’accord sur son contenu et que ce dernier est appliqué.
- que le plan de test évolue. Le contexte et le logiciel évoluent, le plan de test doit également évoluer. Pour cela il doit être maintenu et faire l’objet d’un œil critique. Quelque chose ne fonctionne pas assez bien ou peut être amélioré ? Il faut modifier le plan de test en conséquence. C’est simplement le principe de l’amélioration continue.
- que le plan de test soit adapté au contexte en terme de taille, de sujets abordés, de processus, de philosophie liée au test…
Et concrètement en Agile ?
Une remarque que je lis souvent est que le plan de test est un outil spécifique au cycle en V qui n’est pas adapté à l’Agile. Il est vrai qu’au premier abord, un gros document, déjà peu utilisé en cycle en V peut paraître totalement désuet pour l’Agile.
Je pense pourtant que les plans de test, au niveau produit, peuvent être très utile en Agile… à condition de suivre les mêmes principes de réussite que ceux cités plus tôt!
Ce document m’a d’ailleurs été d’une grande aide sur une mission spécifique dans laquelle on devait tester des clés virtuelles. L’établissement du plan de test niveau produit a permis:
- De bien définir le périmètre des tests et développement
- De bien comprendre l’architecture de la solution
- De bien comprendre le travail et les difficultés des développeurs
- De bien comprendre les différentes phases de test
- De faire accepter le principe des tests exploratoires
- De mieux estimer l’effort pour les US mais aussi mieux faire comprendre ces estimations au client
- De faire monter en compétence les nouveaux arrivant (à la fin le document servait même de document de base pour comprendre le projet)
De même, il est également possible de proposer des plans de test très court pour chaque US. J’ai personnellement essayé d’en implémenter sur 2 missions différentes mais l’expérience n’a pas été concluante et l’expérimentation arrêtée. Je reste cependant persuadé que dans certains contexte, des plans de test d’1 page peuvent être d’une grande aide… Notamment pour bien se synchroniser sur le périmètre.
Enfin, il est intéressant de noter que certaines personnes considèrent que la stratégie de test (souvent confondue avec plan de test) est en fait la Definition of Done en Agile… Le plan de test se retrouve donc intrinsèquement lié à tout développement en Agile mais sous une autre forme.
Et pour l’automatisation des tests ça peut aussi servir ?
Une autre question quant à pertinence des plans de test est lié à l’automatisation. Il est évidemment possible de faire un plan de test de niveau spécifique à l’automatisation (on demande souvent une « stratégie d’automatisation ») mais je ne suis pas forcément un partisan de cette solution.
Mon point de vue, et ma pratique, c’est d’intégrer les principes généraux de l’automatisation au sein même du plan de test maître. L’automatisation, même si elle reste une activité spécifique, reste un des processus gérant la qualité. En partant de cela je l’introduit dans es plans de test, généralement de 2 manières:
- En y faisant mention dans de nombreuses parties (notamment avec les processus et les différentes campagnes)
- En proposant une partie dédiée sur la manière dont l’automatisation sera envisagée (objectifs, périmètres, outils…)
Bien évidemment tout cela évolue lors de la construction, je ne fais qu’initier le plan de test, mais aussi tout au long de la vie du logiciel.
Conclusion
Le plan de test est un outil de communication et de synchronisation très puissant. Comme tout outil il peut être bien ou mal utilisé. Comme tout outil il ne s’adapte pas à tous les contextes.
Je fais partie de ceux qui pensent que le fait d’être en Agile n’est pas un critère permettant de dire que le plan de test ne sera pas utile, néanmoins il est important de noter que les développements en Agile sont forts différents des développements en cycle en V! Les plans de test doivent donc s’adapter. Cette adaptation peut se faire au niveau de la taille, la forme voire même l’utilisation.
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.
