La politique de test: la boussole des tests dans l’entreprise

La politique de test est un concept que je trouve très intéressant mais qui au final voit assez peu le jour concrètement dans un document… ou lorsque c’est le cas se retrouve être un document « mort » c’est à dire inutile, inutilisé et non maintenu. C’est d’ailleurs en partant de ce constat que j’avais imaginé un nouveau format pour la politique de test en proposant il y a 2 ans une version « visuelle » et donc plus facile à partager.

Mon sentiment vis à vis de la politique de test évolue. Il est passé d’un document « inutile » car inutilisé à un document qu’il pourrait être intéressant d’avoir mais dont il faut revoir la forme à mon sentiment actuel: la politique est très importante et sa non utilisation handicape les testeurs.

Attention, je ne dis pas que l’on ne peut pas faire de bons test sans politique mais bien qu’avoir une politique de test bien connue et partagée permet de donner une orientation aux tests dans l’entreprise… et cela pour un investissement assez faible!

Mon sentiment a changé suite à des nombreuses interviews que je suis amenées à faire. Dans ces interviews j’échange avec de nombreux acteurs et il est particulièrement rare que mes interlocuteurs soient capables de me dire pourquoi l’entreprise teste ses logiciels et quelles sont les attentes vis à vis du test. Les indicateurs liés au test sont également assez peu connus quand ils existent et sont même dans ce cas des indicateurs creux car on ne sait pas forcément quels sont leurs objectifs.

Les testeurs se retrouvent alors sans vision globale du test, sans « valeur » à suivre pour adapter leurs tests. Ils se retrouvent donc à devoir imaginer ces dernières et les reconstruire en équipe… Ce qui fait retomber dans des travers similaires à ceux contre lesquels on souhaite lutter quand on met en place le BDD: une compréhension différente entre les différents acteurs.

De même, lors d’une formation, j’ai été amené à présenter le concept de politique de test à des personnes en reconversion. J’ai donc donné un contexte différent à mes stagiaires divisés en 3 groupes en leur demandant de m’élaborer la politique de test des sociétés de chaque groupe et j’ai obtenu ceci:

Pour une société de vente en ligne:

Pour une société développant des applications pour l’état:

Pour une société de jeu vidéo:

Rien qu’en regardant la politique de test on est capable de savoir à peu près ce que fait la société. De même on sait où sont placées les priorités et cela permet, quand on doit faire des choix de savoir à quoi se référer. Les tests dépendent du contexte et ces politiques de test l’illustrent parfaitement.

On voit bien que dans le cas d’une market place la sécurité et les performances vont être prépondérantes alors que les performances le sont beaucoup moins quand on fait des applications pour le gouvernement et que la sécurité l’est également beaucoup moins quand on travaille dans les jeux!

Conclusion

Avoir les informations de la politique de test offrent pour moi une vraie boussole aux testeurs et à l’ensemble des acteurs de la qualité. Comme une boussole, cette dernière ne nous dira pas comment passer les obstacles sur notre chemin, la politique de test sert à nous indiquer le nord et la direction vers laquelle on souhaite aller avec les tests.

Par ailleurs avoir une politique de test permet également de justifier la présence des tests et donc leur légitimité. On fait des tests pour répondre à des besoins spécifiques de notre entreprise et non « parce qu’il faut faire des tests ».

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 *

Automatisation

Outil de test: automatisation avec Robot Framework

Robot Framework en bref Robot Framework est un outil d’automatisation de test, développé au départ par Nokia Networks puis devenu open source, qui dispose d’une communauté active et réactive. Robot Framework permet d’automatiser des tests IHM, des APIs, des BDD, serveurs et même des environnements mobiles (IOS, Android)… Bref, il

Lire la suite »
Avenir

Le testeur 2017

Le testeur 2017 ne sera plus celui de 2016. Le testeur 2017 sera un testeur 2016 amélioré, prêt à répondre aux nouveaux défis qui se présentent en plus de ceux qu’il connaissait déjà avec 2016. Le testeur 2017 devra donc : ·        Travailler encore plus sur l’automatisation des tests : l’automatisation est de

Lire la suite »
Agilité

[STLS 2017] Intégration, Livraison et déploiement continu

Présentation que j’ai faite avec Audrey Menargues lors de la Soirée du Test Logiciel à Sophia (STLS). Un grand merci à elle pour son travail! Pensez à rejoindre le groupe Le métier du test si le test vous intéresse ! N’hésitez pas à me suivre et lire mes autres articles si vous voulez en

Lire la suite »