Un avis ? Un commentaire ?
Cet espace est pour vous.
Mettre en place une politique de test est une étape importante dans la vie d’une entreprise concernée par la qualité logicielle. Toutefois, il existe peu de ressources qui expliquent concrètement comment procéder. Au travers de ce retour d’expérience, nous souhaitons proposer un exemple, à reprendre et adapter.
Mais pour commencer, faisons un rappel de vocabulaire !
La politique de test est un document qui vise à orchestrer la gestion des tests d’une organisation. Le glossaire CFTL/ISTQB (dont vous pouvez retrouver le contenu ici) la définit ainsi :
Un document de haut niveau décrivant les principes, l’approche et les principaux objectifs de l’organisation en matière de tests.
C’est un document qui peut être très concis, tant qu’il répond correctement à ces questions élémentaires :
À l’inverse, ce document ne contient d’éléments temporels ou de bas niveau. Par exemple, si vous voulez lister les outils de test préconisés par l’entreprise, ce n’est pas dans la politique de test qu’il convient de le faire !
De la politique de test vont découler les autres documents importants qui concernent les tests :
La politique de test est en général unique au sein d’une entreprise.
La mise en œuvre d’une politique de test est préconisée par TMMi aussi bien que par l’ISTQB.
Cela étant dit, regardons les choses en face : quelle minime pourcentage d’organisations possède effectivement une politique de test ? Et celles qui en ont une l’utilisent-elles vraiment ?
Marc Hage Chahine témoignait ainsi en 2021, dans un très bon article de La Taverne du Testeur :
Je vais être honnête, je n’ai jamais connu, dans aucune de mes missions à ce jour, de politique de test.
Chez Hightest, nous avons pu faire le même constat. Se pose alors la question…
Car en effet, on peut faire de très bons tests dans une organisation qui n’a pas de politique de test.
Toutefois, la politique de test est un symbole fort. Elle atteste du fait que la direction de l’organisation se soucie de la qualité logicielle et la traite comme un levier de performance à part entière. Elle permet de faire de lien entre la raison d’être de l’organisation, et la pratique (parfois inconnue des hautes couches de la hiérarchie) des tests logiciels. Bref, de mettre en lumière ce qui est souvent invisible !
En découlent deux effets.
Si une organisation déclare faire du test un sujet important, alors elle doit aligner les moyens nécessaires à leur bonne mise en œuvre.
Mettons qu’une entreprise ait un comité de direction très sensible aux tests. Des moyens sont fournis année après année. Mais un jour, le comité de direction change du tout au tout, et compte désormais des personnes peu renseignées sur le test. La politique de test est la porte d’entrée qui permet de comprendre la logique de ce qui se pratique concrètement. Elle fait le lien entre ce qui intéresse vraiment la nouvelle direction, et les pratiques concrètes de test que l’on va retrouver dans d’autres documents (stratégie de test, plans de test maître, plans de test de niveau…) En l’absence de politique de test, le sujet restera peut-être trop obscur au yeux du nouveau comité. Les moyens qui seront alloués au test déclineront peut-être.
Toutes les activités de test doivent découler de la politique de test : il y a une recherche de cohérence, ce qui est déjà un début d’harmonisation des pratiques.
Mettons qu’une autre entreprise possède une stratégie de test et un respectable troupeau de plans de test en tous genres. En l’absence d’une politique de test qui récapitule les véritables enjeux du test, une nouvelle recrue pourrait se sentir un peu perdue, et tester sans vraiment comprendre ce qu’on attend d’elle, l’intention du test dans cette entreprise. C’est un peu comme si on enlevait les nuances d’une partition !
On comprend donc bien pourquoi TMMi insiste sur l’importance de mettre en place, en tout premier lieu, une politique de test. Celle-ci doit être validée par la direction de l’organisation, être dûment diffusée, et périodiquement révisée.
When an organization wants to improve its test process, it should first clearly define a test policy.
(TMMi v 1.3, p. 24. C’est nous qui mettons en italique.)
C’est le moment de faire notre REX !
Dernièrement, nous avons animé une démarche de création de politique de test avec l’une de nos sociétés clientes. Voici comment nous avons procédé.
Tout d’abord, il est à noter que cet atelier s’inscrivait dans une démarche globale visant à améliorer les pratiques de test de l’entreprise. En amont de la planification de la réunion, nous avions en effet mené un état des lieux des pratiques de test de cette société. Lors de la restitution, nous avions notamment expliqué la nécessité de partager une même vision, et pour ce faire, que la société se dote d’une politique de test.
Il est essentiel de donner du sens à cet exercice, sous peine de se retrouver avec un document qui sonne creux.
Afin de réaliser cette politique de test, nous avons identifié des personnes clés, fortement impliquées dans les tests. Nous avons ajusté la forme de l’atelier en fonction du nombre d’individus ayant accepté l’invitation, afin de garantir des échanges à la fois fluides et riches.
En amont de la réunion, nous avons demandé à ce qu’on nous transmette des documents résumant les valeurs de la société. Nous avons « ratissé large » afin d’avoir le plus de matière possible. Ceci pouvant inclure :
Cette étape nous paraissait indispensable. Nous avons d’ailleurs décalé une première fois l’atelier, ayant collecté trop peu de documents pour avoir une vision suffisamment précise des valeurs de l’organisation.
Pour un peu plus de contexte, cette organisation étant complexe, plusieurs « systèmes de valeurs » y coexistent, ce qui a conduit à une liste d’une dizaine de valeurs.
Une partie du groupe de travail se situant dans une autre zone géographique, il était important d’inclure tout le monde en proposant un atelier au format numérique. C’est ainsi que nous avons prévu, au lieu de traditionnels post-its, un atelier sur l’outil Draft.io.
À noter que cet outil est gratuit pour une utilisation légère ; au-delà d’un certain nombre d’éléments créés, il est nécessaire de prendre un abonnement.
En amont de la session, nous avons créé un tableau blanc dans Draft.io. Dans ce tableau, chacune des valeurs identifiées possède une colonne.
Nous avons également prévu (en bleu sur le schéma) des postits vierges, à disposition des membres de l’équipe le jour J.
Le jour de l’atelier, nous avons eu soin de réexpliquer les enjeux de la politique de test, et avons utilisé une variante du Bingo des Recettes à la Noix pour briser la glace et aider les personnes à rassembler des souvenirs, bons ou mauvais, relatifs à la qualité logicielle.
Après cela, le tableau blanc a été passé en revu et rempli d’idées. Il était initialement prévu de laisser les personnes remplir les post-its elles-mêmes sur leur PC ; l’ambiance étant plutôt à l’échange à bâtons rompus, nous avons proposé de plutôt prendre le rôle de scribe tandis que les personnes discutaient ensemble à l’oral au sujet des différentes colonnes.
Cet atelier a duré une heure et demie.
Pour la suite, nous avons proposé deux choix aux personnes ayant participé à l’atelier :
C’est la deuxième solution qui a été retenue.
Nous avons donc passé en revue toutes les idées et créé un document très concis (une page A4) les regroupant.
Les idées non retenues pour le document :
Nous avons également procédé à une synthèse des valeurs, afin de n’en conserver que 3 : ambition, solidarité et efficacité. Elles permettent de classer les idées ayant émergé, tout en fournissant un rappel des valeurs initiales.
Une fois ce travail de synthèse terminé, une nouvelle réunion a eu lieu afin de revoir ensemble le brouillon. Nous avons réalisé quelques changements et ajouté 2 items. La politique de test est désormais prête, mais l’aventure n’est pas finie !
La prochaine étape est de faire valider officiellement la politique de test par la direction de l’entreprise.
NB : idéalement, il aurait fallu que la direction prenne part directement aux ateliers, mais cela n’était pas envisageable pour des raisons d’organisation.
L’étape finale, et non des moindres : la diffusion ! Divers canaux sont envisageables, tous étant cumulables :
Il faudra également songer à revoir périodiquement cette politique de test. Il est important que ce document évolue au rythme de l’organisation. Ainsi, il continuera de donner du sens aux activités de test au fil du temps.
La politique de test n’est pas un document qui s’improvise. Comme il engage l’organisation dans une démarche de qualité logicielle, il est essentiel qu’il soit coécrit par des personnes à la fois représentatives, impliquées et influentes.
Sa forme finale n’a pas besoin d’être imposante : inutile d’écrire un épais document. Bien au contraire, une politique de test concise a beaucoup plus de chances d’être bien assimilée par toutes les parties prenantes.
Encore une fois, notre retour d’expérience n’est pas un exemple « parfait », mais une possibilité dont vous pouvez vous inspirer.
Et vous, avez-vous des expériences de mise en place de politique de test à partager ?
Nous vous conseillons de compléter cette lecture avec celle d’un autre article de la Taverne du Testeur. Vous y trouverez quelques exemples de politiques de test actionnables et qui ne prendront pas la poussière !
Cet espace est pour vous.