La différence entre un plan et une stratégie test

Afin de réaliser votre projet de test, l’une des pratiques les plus conseillées est de décrire de la façon la plus détaillée l’organisation des actions à effectuer. Bien que cela paraisse assez logique et simple a faire, en réalité cela devient plus complexe lorsque l’on parle de stratégie ou de plan de test. Ces deux appellation désignent deux types de documents ayant un but commun, celui d’organiser les actions de tests, cependant le problème est abordé via deux prismes différents, des éléments semblent être d’ordre stratégique pour certains et de l’ordre de la planification pour d’autres. 

 

Quelle est alors la différence entre un plan et une stratégie test ?

Pour commencer essayons de voir ce qu’est la stratégie, c’est selon le Larousse “l’art de coordonner des actions, de manœuvrer habilement pour atteindre un but“. On voit donc qu’ elle est reliée à une prise de risque dans la prévision des actions à effectuer. 

Le plan quant à lui est défini comme suit, c’est une “suite ordonnée d’opérations prévue pour atteindre un but”. On voit donc que le plan est lié à une problématique d’organisation des actions et à leur planification. 

Dans une stratégie, l’action est tournée pour augmenter les chances d’atteindre un but non-certain dans une situation complexe. Dans un plan, l’enjeu réside dans la maîtrise du contexte et la planification des actions afin de parvenir à un but considéré comme atteignable.

 

Qu’en est-il de ces notions dans le milieu du test qualité logiciel?

Pour l’ISTQB la stratégie et les plans de test sont tout d’abord des documents au rôle bien défini. 

La Stratégie de test décrit les méthodes de test générales et indépendantes des projets au sein de l’organisation. C’est « un document de haut niveau qui fournit une description générale du processus de test […] ».

Les plans quant à eux sont une documentation explicitant les étapes permettant la mise en place de la stratégie. Cette documentation peut être composée d’un ou plusieurs documents en fonction de la taille et des contraintes inhérentes à chaque projet. Ils peuvent aussi être spécialisés et dédiés à un niveau précis. Nous pouvons avoir un plan de test maître (ou plan de test projet) décrivant l’implémentation de la stratégie de test sur un projet particulier et un ou plusieurs plan de test de niveau (ou plan de test de phase) décrivant les activités précises à mettre en œuvre pour chaque niveau de test.

On comprend donc assez aisément que la stratégie et les plans sont intimement liés, et font référence l’un à l’autre très régulièrement. La ou la stratégie listera les plans à mettre en place, les plans devront quant à eux faire référence aux points de la stratégie qu’ils traitent.


Des confusions persistent ! 

Des confusions entre plan et stratégie tendent à persister dans le marché des tests informatiques. Bien que leur finalité soit différente, ils décrivent tous deux une démarche prévisionnelle et organisationnelle, provoquant la confusion entre les termes. Actuellement, il est difficile, voire impossible, de disposer d’une structure documentaire qui se veut générale et universelle et dans laquelle se trouve parfaitement définis plan et stratégie. Le consensus professionnel autour des variations du nom et du contenu de ces documents entretient aussi à sa façon cette confusion (voir syllabus, ISTQB, chapitre 2.4).


Conclusion

La stratégie de test tend à s’appuyer sur la politique qualité de votre organisation afin d’identifier les risques et de coordonner les plans de tests. Les plans de test sont quant à eux une documentation définissant les actions opérationnelles à effectuer pour mener à bien la stratégie. Que se soit 1 ou 2 ou n documents séparés, qu’il s’appelle plan ou stratégie, l’important est de formaliser cette organisation et de la faire vivre tout au long du projet. Soumettre ces documents à une réflexion collective est indispensable. Toutes les parties prenantes des projets ne peuvent qu’enrichir ces documents en apportant leur point de vue et leurs expériences. En particulier, impliquer les testeurs à leur élaboration et leurs évolutions est essentiel pour que ces derniers puissent mettre du sens à leurs actions. Rien n’est pire que de tester juste pour… tester.