On entend rarement parler de la politique de test. En général, je dirais même plus que ce terme est peu utilisé et peu connu des testeurs… Au point de ne pas vraiment savoir ce que c’est. Pour rappel, une politique de test c’est le document qui fait référence en terme de test dans une entreprise. En d’autres termes, la politique de test définit le « cap » des tests dans une entreprise.
Je vais être honnête, je n’ai jamais connu, dans aucune de mes missions à ce jour, de politique de test. Cela veut dire que cet élément n’existe pas ? Dans de nombreux cas oui mais dans certains la politique existe forcément! C’est juste que l’on n’a pas de visibilité dessus…
Cela signifie-t-il que ce document est inutile ?
Dans l’état actuel je dirais que oui! Néanmoins, il reste au niveau 2 de TMMI donc essentiel d’après cette évaluation de la maturité des tests. Ce qui semble logique, la politique de test est un document qui est censé fixer un cap. Vous voyez-vous intégrer une équipe de foot sans connaître la philosophie de jeu de cette dernière ? Vous voyez-vous planifier vos prochaines vacances sans aucune idée de ce que vous recherchez ?
Pour bien orienter ses tests en fonction du contexte de l’entreprise il semble donc essentiel d’avoir une politique qui rappelle pourquoi on teste dans cette entreprise… Il faut donc avoir un format qui soit facilement diffusable, assimilable et intégrée par l’ensemble des acteurs de l’entreprise. Pour cela il faut se pencher sur la forme!
Adieu les document word obscurs que personne ne lit… et qui ne peuvent même pas servir pour caler les portes (une politique de test c’est pas assez épais!).
Non, il faut proposer quelque chose de visuel, de simple à retenir… quelque chose que l’on peut dire et redire, un phare auquel on puisse se raccrocher. Il existe évidemment beaucoup de formes possibles. Il suffit de s’inspirer de ce qui se fait ailleurs, par exemple en Agile avec le manifeste ou encore les listes de 12 principes! On peut également penser à des « product box » ou à des cycles (comme le cycle DevOps) dans lesquels on pourrait faire tenir toutes les informations que l’on souhaite. Ce type de communication se voit assez régulièrement dans les bureaux pour des aspects liés au développement, à l’Agile ou tout autre points comme les « 12 factors » pour les logiciels en tant que service (xxx as a service). Il est temps pour le testing de s’en emparer!
Les possibilités sont infinies, l’important c’est d’obtenir l’adhésion et la diffusion de la politique.
J’ai fait l’exercice théorique de mon côté et voici un exemple de ce que pourrait donner une politique de test visible, partagée (ex: placardée dans les couloirs et bureaux)… et qui lui permettrait d’atteindre son but:

Et vous, quelles idées avez-vous pour mettre en avant le test et le rendre plus visibles grâce à une politique de test dépoussiérée ?
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.



6 réponses
Salut !
C’est vrai que je découvre ça en 2025 et 6 mois après avoir passé l’ISTQB foundation v4. Du coup je suis dans une grosse organisation qui gère 50 applicatifs. De mon point de vue c’est quand même intéressant d’avoir ce type de doc même si j’ai eu du mal à le distinguer de la stratégie de test (et c’est toujours le cas un peu).
Bonjour,
merci pour ce retour.
La politique dit pourquoi on teste et la stratégie plus le « comment » de manière générale.
J’essaye d’expliquer ces différence dans cet article: https://latavernedutesteur.fr/2019/08/19/politique-strategie-et-plans-de-test/
Bonjour Marc Hage Chahine,
C’est une chance d’échanger avec toi. Oui, j’ai vu ça en effet. Je me demandais si cet article était toujours d’actualité. Cependant dans le schéma que tu présentes, j’ai du mal à voir où se situe le pourquoi. Je comprends la politique qualité comme une forme de « philosophie » de la qualité appliquée à l’ensemble de l’organisation.
Merci !
On peut voir ça comme cela.
D’un point de vue personnel je suis plus sensible à « pourquoi », c’est à dire les raisons concrètes (causes racines) pour lesquelles on teste. Comme toute activité il est important qu’elle est un sens et, selon le sens que l’on lui donne, les pratiques et moyens mis en œuvre, pour la réaliser diffèrent
Ok, je te remercie, autre sujet mais est-ce que dans une autre rubrique ou des sources que tu as pu produire tu évoques l’automatisation de tests de bout en bout ?
Il y a à ce jour 79 articles liés au mot clé automatisation.
Un certain nombre parle de tests de bout en bout. Le dernier en date est celui qui présente l’outil Eggplant: https://latavernedutesteur.fr/2025/03/13/sponso-testez-vos-applications-packagees-avec-le-computer-vision-deggplant/ mais il y en a évidemment d’autres