13 Mai 2016

Collaboration Développeur – Qualification

Quel développeur n’est pas touché dans son égo quand quelqu’un trouve un bug sur son application ? Celui qui écrit du code infaillible certes… je ferais peut-être un autre jour un article sur l’approche ego-less… Il n’empêche que de nos jours, je reste persuadé qu’il est quasiment impossible d’écrire une application sans le moindre problème et cela du premier coup et je souhaite vous faire découvrir la façon qui selon moi est la plus évidente pour les découvrir le plus tôt possible dans la chaîne de fabrication.

C’est pour cela que chez nous l’étape de qualification est intégrée dans le processus de développement de nos applications. Il existe plusieurs façons de qualifier une application. Je vais vous faire un retour sur ce que j’ai pu vivre dans mes projets, en partant d’une « non-qualification » plus connue sous l’appellation « tester c’est douter », pour arriver à la meilleure expérience que je suis en train de vivre, l’intégration d’un profil « testeur » au sein de l’équipe de développement.

affiche-tester-c-est-douter

Source: CommitStrip

 

Voilà moult années que je travaille ici, au WebCenter AXA de Lille, et des projets à mon actif j’en ai ! Et il y a toujours des raisons pour que des problèmes émergent (que l’on est prêt à accepter ou non) :

  • Fonctionnalité qui évolue
  • Un besoin difficile à assimiler
  • Montée en compétence sur une stack ou une techno
  • Reprise d’application legacy ou tiers qui ne respecte pas ou plus les processus de l’entreprise et les bonnes pratiques de dev

Les origines étant nombreuses. Ce qui compte c’est de s’en rendre compte, d’accepter,  d’analyser ses erreurs et d’avancer en faisant mieux. Comme le disait Henry Ford : “Échouer, c’est avoir la possibilité de recommencer de manière plus intelligente.”

De nos jours, pour limiter nos erreurs, il existe de nombreux moyens :

  • Les tests unitaires
  • Les tests automatisés
  • Les tests UI

Il existe également des méthodologies comme :

  • Le BDD qui permettront de s’assurer que l’on répond toujours au besoin fonctionnel,
  • Le TDD pour limiter au maximum les bugs en amont.

D’expérience ces pratiques sont tops ! Ce n’est pas un “nice to have” mais plutôt un indispensable qui fera que vos développements seront plus fiables. Mais pour moi ces pratiques ne remplaceront jamais les tests en situation réelle. D’où l’intervention de la QSI sur nos projets. Le but est de tester l’application dans ses conditions réelles d’utilisation. Haaa ce fameux testeur qui utilise l’application comme on ne l’avait pas prévu ! Cette personne bien relou qui n’a rien compris à notre vision super technique et pointue de notre conception carrément trop géniale… Toujours est-il que cette personne vient, en deux clics, de mettre un KO technique à votre application et vous a offensé au plus haut point.

Cette situation est vraiment dure à vivre (on passe par beaucoup d’émotions très distinctes : colère, vexation, etc.) mais tout va dépendre du type de testeur que vous avez en face de vous. Durant mes premiers projets chez AXA j’ai eu des bons testeurs, mais j’ai aussi eu ceux qui n’étaient pas vraiment formel dans leur démarche. Je m’explique. Je veux bien admettre que j’ai fait une erreur, mais pour cela il faut m’expliquer ce que j’ai mal fait et comment on fait pour reproduire… Malheureusement j’ai souvent eu le cas de la fameuse fiche de bug qui disait “Problème de développement, il y a un bug!” et quand j’avais de la chance j’avais le droit à une capture d’écran où je devais moi-même déduire le contexte de celle-ci, mais bon, comme ce n’est pas Noël tous les jours je me contentais seulement de savoir que quelqu’un avait trouvé un bug quelque part… (True Story)

Là aussi il y a des raisons:

  • Nouvel arrivé dans la société avec une faible connaissance des outils internes
  • Les fonctionnalités qui évolues et des difficultés à assimiler le besoin
  • La distance entre les interlocuteurs
  • Une grande quantité de tests à faire en très peu de temps

Résultat nous avions ce sentiment d’avoir perdu beaucoup de temps à se battre pour essayer de trouver/reproduire les problèmes, cette certitude de pouvoir être plus efficace et de travailler dans une meilleure ambiance.

Je vous propose de revenir dans l’art du rapprochement des équipes ! La Feature Team et plus précisément sur le rapprochement du « qualif » dans la squad !

Dans ce processus, les tests sont faits au plus tôt dans le chemin de livraison. Un développeur qui créer une multitude de fonctionnalités passe forcément à côté d’un cas spécifique. Afin de palier à cela, dès la fin des dev/tests unitaires et relecture de code avec un autre développeur, quand nous déployons l’application dans le premier environnement, on passe aux tests avec notre testeur adoré, et comme il y en a plus dans deux cerveaux plutôt que dans un seul, on tombe très vite dans les cas les plus farfelus. Ce processus fait d’ailleurs partit de la Definition of Done du projet.

Le plus intéressant dans ce procédé c’est que le développeur tombe face à son erreur quasiment par lui-même, et je dois vous avouer que niveau acceptation de l’erreur, cette manière de fonctionner me convient beaucoup mieux.

Une fois l’erreur sous nos yeux, le testeur peut rédiger et tracer le problème de manière exhaustive avec le cas de test qui va bien, et le développeur peut s’atteler à la tâche et corriger tout de suite son erreur.

Avec le temps on peut dire qu’on se lie d’amitié avec le mec que vous détestez le plus sur cette terre, retenons par-là que la collaboration est beaucoup plus agréable et les échanges deviennent beaucoup plus constructifs. Même la relation à distance peut fonctionner, c’est juste une question d’organisation. Mais ce qu’il faut comprendre c’est que les mentalités doivent changer, le dév doit mettre de côté son ego de warrior infaillible et le testeur ne doit pas être là pour faire la chasse aux bugs et être payé au rendement de bug trouvé, non non non il est là pour montrer que les dév ont effectués un travail de qualité. Il faut un bon mariage entre sérieux, professionnalisme et bonne intelligence. L’équipe étendue (Développeurs/Testeurs) a pour mission commune de livrer un produit fini.

Ce mode de fonctionnement m’a également permis de découvrir le métier de testeur, et honnêtement c’est un vrai métier ! Aujourd’hui je suis certain de ne pas être fait pour ça ! Mais cette expérience m’a également permis de voir comment la qualification faisait pour tester nos applications, que par moment il y avait beaucoup de choses rébarbatives à faire et que le métier n’a pas l’air toujours très fun. Du coup, avec la complicité que nous avons construite ensemble, j’ai décidé de les aider là où je pouvais.

Les testeurs n’ont pas tous forcément un passé de développeur, pour certains le développement est une chose bien abstraite. Du coup ils passent leurs journées à éplucher des logs, générer des requêtes en allant piocher des infos un peu partout, c’est long, c’est chiant, en tous cas moi, fainéant de dév que je suis, j’aime bien mettre en place des choses qui vont faire le travail pour moi (normal quoi, quel dev n’est pas fainéant et aime faire mile fois la même chose !!!).

C’est un fait, il est impossible de faire des tests exhaustifs qui couvrent tous les cas, en revanche il est possible de réduire le périmètre des tests grâce à l’automatisation. En voyant mon gentil qualif barbu en galère là ou moi je pouvais l’aider à gagner du temps, j’ai décidé de prendre un peu de mon temps personnel pour lui créer des outils pouvant automatiser une grande partie de ses tests:

  • création d’un contexte utilisateur
  • connexions OAuth automatisés pour ne pas qu’il entre son mot de passe 8500 fois par jour
  • interface permettant de contourner les webservices appelés histoire de ne pas faire la qualification de ces webservices qui n’ont rien à voir avec nos développements

Bref, autant de petits outils permettant d’automatiser une multitude de choses spécifiques au projet mais que nous ne souhaitons pas qualifier. Un petit exemple pour illustrer le tout, lorsque nous mettons notre projet en production, il faut forcement tout re-tester histoire de voir s’il n’y a pas de régression :

  • Applicative : qui serait passée entre les mailles du filet des autres environnement
  • Infrastructure : la config du serveur qui change

Pour simplifier le processus de test, nous avons mis en place un script mocha permettant au testeur de lancer tous les appairages qui vont bien pour son utilisateur de production, ainsi il gagne en moyenne 15 min de test. En effet il n’a plus à saisir à la main tous les comptes des partenaires, ici on ne cherche pas à qualifier le fait que la page d’authentification du partenaire fonctionne, non, on cherche bien à gagner ce temps pour se concentrer sur les tests de notre application.

test_qa

Source : La petite fabrique du jeu vidéo

Bientôt deux ans de projet à fonctionner comme cela et j’ai du mal à me dire qu’un jour il est possible que tout redevienne comme avant. La présence de la qualification au plus près des développeurs change vraiment la vie ! Je ne dis pas que vous allez produire moins de bugs, mais vous allez pouvoir les identifier plus vite dans la chaîne de production.

Aujourd’hui je suis convaincu qu’il est indispensable d’avoir une ressource dédiée aux tests fonctionnels de votre application, mais aussi que vous devez l’accompagner dans la phase de test de ce que vous avez produit.

Pour certains le fait de passer son temps à faire les tests avec le testeur passe pour une perte de temps mais je peux vous dire que c’est loin d’être de le cas pour des raisons évidentes:  vous ne refaites pas le test après lui pour vous remettre dans le contexte, so, deux fois moins de temps. Vous identifiez les problèmes plus rapidement, so, moins de temps de corrections, puis surtout on vous dira “oui, mais vous pourriez développer une autre feature pendant que le testeur fait son taff” … “C’est pas faux” … surtout quand il teste toute l’application d’un coup mais honnêtement… quand vous n’avez qu’une feature à tester, vous allez vraiment démarrer un chantier pour l’arrêter cinq minutes plus tard pour vous remettre dans un bug, le corriger et revenir trois heures plus tard pour finalement avoir oublié tout le contexte de ce que vous faisiez ? Autant prendre cinq minutes pour certifier que votre travail fonctionne et être serein pour pouvoir passer à autre chose.

Pour donner quelques chiffres, en deux ans de projet, tout environnement confondu et tout type de bug confondus, nous avons eu 117 bugs qualifiés, et souvent bien avant la production. L’application consomme des services, appelle des partenaires, est utilisé par une application mobile, etc… de ce fait quand on nous dit « il y a un bug !» on pointe en premier lieu l’application elle-même, du coup en mettant en place un tas d’outils pour les testeurs, ceux-ci sont capable d’identifier réellement d’où vient le problème et s’il est réellement lié à l’application ou à un tiers. Ainsi on constate aujourd’hui qu’en réalité 1 bug sur 3 vient d’un tiers, et sans la collaboration étroite entre qualification et développement, nous aurions dû à chaque fois creuser pour savoir d’où le problème venait réellement pour finir par nous rendre compte qu’en fait nous n’étions pas responsables.

D’expérience, le temps de projet n’a pas été doublé parce qu’on avait mis en place cette pratique, bien au contraire, je trouve ce processus plus fluide et logique pour le bien être du projet, je constate même que l’expérience humaine en est renforcée ! Je suis devenu un fan de ce mode de travail et je ne serai que vous recommander d’au moins essayer pour vous faire votre propre idée de la chose. Bien entendu (et pour rappel) vous devrez avoir une certaine ouverture d’esprit pour accepter de mettre le doigt là où ça fait mal, mais comme toute nouvelle pratique c’est le départ qui est le plus compliqué, une fois lancé vous verrez que c’est top !

En conclusion je tends à dire que tout cela fonctionne très bien mais qu’il y a tout de même des ingrédients secrets pour que tout ce goupille bien, l’envie et la motivation. C’est un réel investissement de toutes les parties prenantes du projet, plus vous aurez d’éléments freins, plus vous devrez filouter et taper dans ce fameux budget “Best effort”, c’est à ce stade que la motivation entre en jeu. Au final quand je vois le résultat, nous sommes tous allés dans le sens du projet, le but étant de livrer une application de qualité, intuitive, qui respecte l’utilisateur final. Nous y sommes arrivés et je reste persuadé que sans cette volonté de bien faire, l’ambiance ne serait pas aussi bonne qu’elle peut l’être aujourd’hui et je pense également que le projet serait sans cesse en train de repasser dans des processus long et complexe ou la correction d’un bug serait coûteuse en temps et en énergie.

Share
  • Laurent Nyffels

    Merci Geoffrey pour ce retour d’expérience. La formation des équipes de qualification à l’Agilité, l’intégration des “Testeurs” au sein des équipes de “Devs” et le “Pair testing” sont à mon sens les pratiques les plus efficaces qui ont été mises en place ces 2 dernières années au Web Center. On pourrait certainement dire la même chose des bénéfices constatés d’avoir un architecte applicatif dédié et impliqué sur l’ensemble de la chaine de fabrication.

    L’intégration d’un “Ops” au sein des équipes de devs est probablement la prochaine étape du processus d’amélioration continue. J’attend déjà ton feedback avec impatience 😉