Les peurs du testeur

Le testeur, comme toute personne, a des appréhensions et est sujet à des peurs. En voici quelques-unes touchent de nombreux testeurs.

Comme pour toutes les peurs il faut savoir les dominer et s’en servir pour s’améliorer.

·        Avoir un bug majeur/critique qui est passé à travers les tests avant la mise en production de l’application (ou d’une de ses versions).

Explication : La peur lors d’une mise en production est commune à l’ensemble des membres du projet. Elle est cependant souvent plus importante chez les testeurs car lorsqu’il y a un bug la responsabilité retombe souvent sur les testeurs… Au moins du point de vue des utilisateurs finaux. Qui n’a jamais entendu cette phrase (ou un équivalent) : « L’application est truffée de bugs, ils l’ont vraiment testée ? ».

Que faire : La première chose à faire est d’avoir une bonne conception des tests de préférence avec une étude en amont faite avec les utilisateurs finaux, les spécifieurs et développeurs (à travers un plan de test si possible). Ensuite il faut bien écrire, exécuter et analyser les tests. Si tout est bien fait, la probabilité d’avoir un bug majeur est faible car la couverture des tests choisie pendant la conception doit justement permettre d’éviter ce problème. La seule possibilité restante, dans ce cas, est d’avoir mal évalué (ou pas pensé du tout) un risque. Cette possibilité est limitée grâce à l’étape de conception qui a été validée par les membres du projet.

·        La peur du changement :

Explication : peur du changement de logiciel de test ou de processus, de membres de l’équipe… En fait, la peur de l’inconnu. Ici c’est plus la peur de l’inconnu qui prime. Je travaille avec mes outils, mes collègues et tant que je ne suis pas mécontent, je ne souhaite pas de changement. Qui dit nouveauté dit adaptation dit efforts qui n’étaient pas nécessaires et qui ne seront potentiellement pas fructueux.

Que faire : Ici, il faut changer d’état d’esprit et considérer le changement comme une opportunité. Dans l’idéal il faut être pro-actif et contribuer à ce changement afin que les intérêts des tests ne soient pas oubliés.

·        La peur d’être le premier budget coupé.

Explication : Cette peur est malheureusement souvent avérée. Par exemple, en cycle en V, le test arrivant « à la fin » du projet et les dates étant souvent « fixes », le test voit son temps alloué diminué de tous les retards accumulés.

Que faire : Malheureusement le budget test est souvent coupé en premier. Pour éviter cela il faut continuellement communiquer autour de l’utilité des tests, expliquer quel est leur retour sur investissement (ROI). Afin de limiter les effets des coupes il faut également prioriser les tests afin de savoir lesquels sont les plus importants à exécuter et à analyser (tout cela est idéalement fait lors de l’étape de conception des tests).

·        La peur d’être considéré comme ne servant à rien.

Explication : Lorsque les tests ne repèrent aucun bug, lorsqu’un bug arrive en production, lorsque l’on ouvre des bugs qui ne sont pas corrigés… Dans tous ces cas le testeur peut avoir cette impression.

Que faire : Pour cela, seule une bonne communication peut servir. Les résultats des tests se font sentir principalement à moyen et long terme. Rien n’empêche cependant, lors des bilans de mettre en avant ce qui a été détecté, comment l’analyse des bugs a permis une correction facile ou même ce que les tests ont permis d’apporter en confiance sur la qualité de l’application (0 bug détecté cela ne veut pas forcément dire que les tests sont inutiles !)

·        La peur d’être considéré comme responsable des retards des projets.

Explication : Les tests n’étant pas une activité créatrice la phase de test peut souvent être considérée comme non productive et empêchant l’application de sortir (des fois c’est même pire, le testeur donne un NO GO et bloque la sortie de l’application) en production alors que l’application (et le code) est considérée comme finie par certains membres du projet.

Que faire : Là encore une bonne communication et un point régulier permet de « cibler » les responsabilités si besoin. De plus, si le temps de test est réduit, il faut exécuter les tests les plus importants en priorité, quitte à ne pas tous les exécuter. Enfin, je tiens à rappeler que ce n’est pas les testeurs qui ont le dernier mot pour une mise en production de l’application, le dernier mot appartient aux responsables de l’application. Une application qui ne sort pas car on y a détecté des anomalies est une application qui a des anomalies bloquantes et qui d’après le responsable de l’application ( et grâce aux rapports des testeurs) ne peut pas être mis en production.

Conclusion :

Les peurs ont très souvent comme source l’incertitude. La meilleure chose à faire pour minimiser (ou faire face à) ces peurs est de limiter les effets ou les probabilités d’occurrence de ces évènements qui génèrent cette peur (c’est le même principe que la gestion des risques).

Il faut également apprendre à vivre avec ces incertitudes et se servir de ses expériences, de ses échecs. Les erreurs arrivent sur tous les projets et tout le monde fait des erreurs, d’ailleurs, les testeurs vivent de ces « erreurs ». C’est justement leurs erreurs qui leur permettent d’avancer et d’acquérir de l’expérience.

De plus, je tiens à ajouter qu’il est normal d’avoir peur. Que la peur permet de se poser de bonnes questions et donc d’anticiper de nombreux problèmes.

La peur doit nous booster, nous pousser à devenir meilleur mais en aucun cas cette peur doit nous tétaniser !

ps : J’ai eu l’idée de cet article en écoutant Discard your fear de Riverside en allant au travail il y a une dizaine de jours.

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 apprendre plus sur le test ou venir partager vos connaissances

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles