Maulik OZWALA fut diplômé d’ingénierie informatique en 2009. Depuis, il a toujours travaillé en tant que testeur, ayant accumulé des expériences en campagnes SMS, santé ainsi que marketing out of home. Il est aujourd’hui à la tête d’une équipe de 15 personnes qu’il a construit. Je voulais comprendre comment réussir ses tests en agile mais Maulik étant Maulik, nous avons rapidement dérivé sur des sujets plus vastes, tels que le leadership et le recrutement.

En quoi les tests en agile diffèrent de ceux en environnement traditionnel ?

Dans un environnement traditionnel, il y a beaucoup de documentation à disposition, tant fonctionnelle que technique. Il faut être consciencieux, mais on peut « éteindre son cerveau » tant que l’on suit les scripts. C’est que j’appelle les tests formels.

En agile, il faut bien plus d’interactions entre les équipes. Un plus grand effort est nécessaire pour recueillir et diffuser l’information. Des changements peuvent également être introduits au fur et à mesure et il faut l’accepter.

Au lieu de se concentrer sur la documentation, on se concentre sur l’exécution. C’est que j’appelle les tests exploratoires. On explore l’application et le business, on engrange de l’information et on la réutilise dans les tests. Un plus grand degré d’automatisation est également nécessaire, car les releases sont plus fréquentes.

C’est bien plus intéressant pour moi, mais c’est dur à accepter pour certains.

Comment as-tu gérer la transition vers l’agile ?

Il m’a fallu, tant à moi qu’à mon entreprise, entreprendre une transformation culturelle. RSoft est certifiée CMMI niveau 3. Nous sommes habitués à travailler avec des procédures et produits documentés de manière exhaustive. Nous n’avions rien de tel lorsque nous avons entamé notre premier projet agile. J’étais perdu, les choses bougeaient trop vite et les attentes envers moi étaient très importantes. Les releases n’avaient pas le niveau de qualité attendu, j’ai donc pris du recul.

Lorsque j’ai visité le client, j’ai eu une épiphanie. Il me fallait m’asseoir avec les utilisateurs afin de voir comment ils interagissaient avec l’application et à quoi ressemblait une journée typique. Cette expérience m’a aidé à grandement améliorer mes cas de tests, reproduisant leur parcours dans l’outil.

Par moment, il m’a paru que je rétro-ingénierais l’application.

Ne reconnaissons-nous pas un échec de l’agile ? S’il est nécessaire de « rétro-ingéniérer » le software à chaque fois qu’on intègre un projet, comment assurer sa longévité ?

Tout d’abord, un néant quasi-total de documentation n’est pas la norme. Cela dépend de la maturité du processus et des stakeholders.

Mais surtout, en agile, collaboration et communication sont des facteurs clefs de succès. Tu n’es pas une étape dans le processus, tu es un catalyseur pour ton équipe et l’environnement dans lequel tu évolues. Tu te dois de prendre conscience que le succès est la responsabilité de tous : va chercher et diffuse l’information.

La transition vers l’agile m’a également permis de m’améliorer en tant que manager.

En quoi ?

Mon équipe doit être en contact constant avec plusieurs autres stakeholders, je ne peux pas les micro gérer. Je me dois de les responsabiliser. Au lieu de leur dire quoi faire, je décris l’environnement dans lequel ils évolueront ainsi que les enjeux pour l’entreprise. Je les responsabilise alors du succès, non seulement de leur travail, mais du projet en entier.

Je m’attache également à bien gérer leurs attentes. Pour aider mon équipe à grandir, j’accepte l’échec, mais je m’assure qu’une leçon est apprise et je suis les améliorations. La formulation est également très importante : je les aide à travailler sur leurs faiblesses, mais je ne les pointe jamais du doigt. La ligne est mince.

Enfin, je suis convaincu qu’un département de test qui réussit est fortement impliqué dans le support ainsi que dans le recueil de besoins. Ainsi, nous infusons une perspective technique dans les spécifications et réduisons les cycles de test, tout en assurant qualité et exhaustivité. Cela aide à réduire la procédure d’escalade en cas de problème, tout en donnant accès à des informations permettant d’améliorer les cas de tests.

Cela a-t-il impacté le processus de recrutement ?

Et celui d’intégration en effet. J’essaie de trouver des collaborateurs qui sont créatifs et pensent différemment de ceux en place. Mais ma préoccupation principale est l’aspect comportemental et culturel : nous sommes prestataires de services travaillant en agile. J’ai besoin d’un engagement réel envers la satisfaction client et un esprit d’équipe. Un recrutement raté peut avoir des conséquences néfastes.

L’intégration prend environ 6 semaines. Nous commençons par le business, la stratégie, comment il opère etc… Seulement après nous découvrons l’application. La meilleure manière que j’ai trouvé pour m’assurer que le processus était réussi est que l’élève devienne le professeur. Cela me permet de vérifier si le formé a bien compris le sujet et si le formateur a été suffisamment clair. J’attache de l’importance à construire un cercle vertueux.

Enfin, je crois beaucoup aux 4 étapes de la formation d’une équipe : « formation, turbulence, normalisation, performance ». Lorsque je suis témoin de tensions dans l’équipe, je n’interviens pas, à moins que cela soit vraiment sérieux : construire une équipe performante prend du temps. Expliquer cela à mes équipes les aide à accepter les soubresauts initiaux pour ce qu’ils sont.

Comment envisages-tu le futur de l’outsourcing alors que l’agilité gagne en popularité ?

L’outsourcing est là pour durer. Travailler en agile avec des équipes offshore n’est pas facile, mais parfaitement faisable. Les entreprises cherchent à réduire leurs coûts tout en maintenant la qualité. Travailler avec l’Inde c’est avoir 5 ressources compétentes pour chaque employé en France par exemple. Je crois également que les indiens ont un degré d’engagement supérieur à la moyenne.

Le plus gros challenge sera la communication et la compréhension du business. Visiter les sites de l’un et de l’autre est le meilleur moyen de les surmonter, tout comme mettre en place les moyens de communication qui permettront un lien constant entre les équipes on et offshore. Une fois qu’elles se comprendront, tant personnellement que culturellement, elles produiront des résultats. Expliquons pourquoi le produit est important d’un point de vue stratégique et opérationnel, et nous réussirons.

Retrouvez l’article de Thomas NEVOA PEREIRA sur Medium