Analyse de mes principales erreurs – la suite

Introduction

Cet article est la suite d’un premier où je revenais sur les erreurs que j’ai faites lors de certaines de mes missions mais aussi les enseignements que j’en avais tiré. Ma carrière de « fauteur professionnel » n’étant pas terminée il me semble intéressant de partager avec vous des erreurs ultérieures qui, même si elles paraissent moins grandes (grâces aux enseignements des premières), m’ont aidées à évoluer!

Mon premier audit

J’étais tout jeune et tout fringuant. Des idées plein la tête, des certitudes et une confiance débordante. C’est dans ce contexte que s’est déroulé mon premier audit. Mes articles ayant attiré l’attention d’un collègue qui cherchait un expert test il m’a proposé ce challenge que j’ai accepté. J’ai alors été formé et accompagné pour réaliser mon premier audit. Sur place tout se passe bien, j’échange régulièrement, je comprends bien les problématiques, je suis capable de synthétiser les process et les points de douleurs ce qui me permet d’écrire mon rapport.

Je suis honnêtement assez fier de ce premier rapport, d’ailleurs la qualité de ce dernier m’a permis d’être recommandé pour en faire d’autres et débuter des missions d’accompagnement… Néanmoins, 1 an après, rien a changé, mes préconisations n’ont pas été mises en œuvre et, au final, on peut considérer que cet audit n’a pas été utile. 😦

Mes erreurs:

Clairement, on ne peut pas considérer cet audit comme une réussite. La raison ? J’avais convaincu un grand nombre de personnes de l’intérêt des changements que je proposais. Néanmoins, il y a une personne avec qui je n’ai que peu échangé, pas assez passé de temps ni discuté. Cette personne n’était pas le test manager responsable d’une équipe de 20+ testeurs mais son responsable. Ce responsable était la personne à convaincre car c’est en fait lui qui avait le pouvoir de mettre en place des actions.

Mes conseils:

Que cela soit pour un audit ou toute autre activité, il est primordial de savoir à qui s’adresser et qui convaincre. Lorsque l’on ne concentre pas ses efforts sur les « bonnes » personnes on arrive alors régulièrement à des désillusions et un manque d’efficacité de ce que l’on souhaite.

Il est bon de noter que ce conseil s’applique au delà des personnes à convaincre et même au delà du test. Il faut savoir où mettre ses efforts pour être le plus efficace.

Cette expérience m’a servie pour dans mes autres audits qui ont donné lieu à plus de changement et en général à une amélioration du test.

Ma mission de PO et testeur

Cette mission est la mission sur laquelle j’ai travaillé sur la période la plus longue de ma carrière. Elle s’est étalée sur près de 4 ans (à 80% puis à 50%). Lors de cette mission j’ai principalement travaillé sur 1 outil développé en Agile. J’ai contribué de la genèse à la fins des développements sur ce produit dont les utilisateurs étaient satisfait!

Néanmoins, je n’étais pas uniquement sur ce produit et, surtout au début, ai travaillé sur quelques autres produits.

Mon erreur:

J’étais concentré sur « mon » produit mais je devais en tester d’autres, peu documentés et que je ne connaissais pas forcément. Dans ce cadre j’ai rapidement demandé des informations sur le produit et proposé de mettre en place certains tests vitaux à exécuter régulièrement. De même j’ai été amené à tester l’application lors d’un gros déploiement.

Ce déploiement, après une validation de ma part, s’est avéré avoir laissé passer une très grosse régression! La raison était simple: je ne connaissais pas assez le produit testé et son utilisation.

Mon conseil:

Toujours bien appréhender le produit. Il n’y a pas de campagne « facile », surtout lorsque l’on ne connaît pas assez bien le produit. Il ne faut jamais hésité à se renseigner auprès d’utilisateurs ou des personnes travaillant sur le logiciel afin de s’assurer que notre compréhension de l’utilisation du produit et donc nos tests sont bien adaptés… Pour cela il faut rester humble et concerné… Ce qui m’avait sûrement manqué à ce moment là trop car concentré sur un autre produit.

Mission de mise en place d’une stratégie de test

Cette mission était particulièrement intéressante. J’avais en charge d’établir le plan de test maître pour la gestion d’une clé virtuelle. Dans le même temps je travaillais dans une équipe où les personnes qui n’étaient pas encore habituées à l’Agile. J’ai donc encadré cette équipe afin de l’aider à s’adapter à l’Agile.

Mon erreur:

Ici je n’ai pas fait 1 mais 2 erreurs!

La première était de commencer à travailler sur le plan de test maître (appelé stratégie sur cette mission) sans prendre assez connaissance de ce qu’attendait réellement le client. Au final la première version de mon document ne correspondait pas du tout à ce qui était attendu (il y avait des choses bien et instructives mais pas ce qu’attendait réellement le client). Fort heureusement, étant habitué à travailler en Agile la première version avait été proposée très vite ce qui a permis de reprendre la bonne direction.

La seconde erreur était plus liée à ma vision de l’Agile et la manière dont je l’ai présentée aux personnes travaillant avec moi. Cette vision était proche de la contradiction sur certain points entre ce que le client demandait et attendait (par exemple en surchargeant des sprint et sachant qu’il était impossible de tout faire en 1 sprint) et ce que j’avais présenté à l’équipe. Du coup cela a créé des tensions inutiles.

Mes conseils:

Dans les 2 cas les erreurs ont été vite corrigées grâce à une communication fréquente avec le client.

Mon premier conseil est donc d’adopter une bonne communication tout au long du développement de n’importe quel logiciel. Cette communication permet l’amélioration continue mais aussi d’éviter de trop s’enfoncer dans l’erreur.

Mon deuxième conseil, spécifique au premier problème, est de bien s’accorder sur le vocabulaire. Le terme « stratégie de test » est très vague et ce qui est attendu dépend de l’entreprise voir même de l’équipe qui le met en place. Afin d’éviter ce genre de problème, que cela soit pour une stratégie ou tout autre chose il faut se mettre d’accord sur l’attendu… C’est d’ailleurs un peu le rôle des 3 amigos en Agile.

Mon troisième conseil, valable pour la seconde erreur c’est de ne pas dépeindre des situations toute noires ou toutes blanches. La nuance est importante. Dans ma transmission sur l’Agile j’ai été trop proche de l’Agile des textes, l’Agile théorique. Malheureusement cet Agile est rarement l’Agile du terrain et il faut bien faire comprendre ces nuances.

Autre conseil général:

Il ne faut jamais considérer que tout va bien et toujours échanger, discuter, chercher à s’améliorer. Il m’est souvent arriver de découvrir que certains processus ne se passaient pas assez bien, que certaines relations étaient tendues, que mon travail ne correspondait pas entièrement à ce qui était attendu. J’ai réussi à avoir ces informations grâce à la communication. Dans certains cas il aurait été mieux de le découvrir plus tôt, dans d’autres je l’ai découvert de suite… Dans tous les cas, découvrir le problème m’a aider à rectifier le tir et améliorer les choses.

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.

Publié par

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s