Effectuer une année de travail en une seule journée

Oui, c’est peut-être un titre légèrement racoleur 😜 mais c’est vrai. Sur AXA+, par les outils et les méthodologies mises en place, lors d’une seule journée de développement, un développeur effectue l’équivalent de 208 jours de tests.

La méthode​​​​​​​

Pour expliquer la méthode que nous utilisons, nous allons partir de la correction d’une anomalie (et oui ça peut malheureusement encore arriver).

Une anomalie détectée par l’équipe de test a été qualifiée, puis priorisée par l’équipe projet. Un développeur la prend en charge. Pour notre exemple, nous prenons une anomalie simple et visuelle, mais la méthodologie reste évidemment la même sur toutes les anomalies. Là, l’anomalie est le manque d’un espace entre l’adresse et le complément d’adresse.

Sur la version en cours de développement, le développeur n’arrive pas à reproduire cette anomalie. Elle n’est pourtant pas classée « sans suite » ou « ouverte à tort », la confiance que nous avons les uns envers les autres, nous motive à pousser nos investigations… L’investigation sera rapide, nous allons poser un nouveau test.

Oui, ce bout de code est issu de nos sources … vous pouvez être surpris, il est écrit en langage naturel et en français. Paraphrasons donc, il dit simplement que pour un contrat « habitation », qui a une adresse avec un complément, nous devons avoir l’adresse et son complément séparé par un espace.

L’exécution de ce test est un succès, ce qui confirme la « non » reproductibilité du bug.

Une fois que le développeur a terminé la mise en place de ce test, il y a une phase de mise en commun de son code avec le code des autres développeurs. Lors de la mise en commun du code, les tests, les mêmes tests que celui-ci, sont automatiquement rejoués.

BINGO… Lors de ce « rejeu », l’exécution de ce test passe soudainement en erreur. L’équipe de test avait une nouvelle fois raison, nous avions bien une anomalie, sûrement une régression due à l’ajout d’une nouvelle fonctionnalité. Le développeur peut la corriger. Dans le jargon, il va passer son test du ROUGE 👎 au VERT 👍.

Voilà, une dernière remise en commun du code ; une relecture de tous les développeurs : l’anomalie a été corrigée…

NON …. MIEUX, elle est définitivement corrigée. Nous pouvons assurer que cette même anomalie ne se reproduira JAMAIS. Avoir une anomalie c’est malheureusement possible, avoir 2 fois la même anomalie est intolérable. Poser d’abord un test avant de toucher notre code, nous assure que chacune des lignes de code que nous écrivons est testée… chaque ligne de code que nous écrivons est « induite », « dictée », « commandée » par un test, donc par un besoin fonctionnel. Vous ne trouverez pas dans AXA+ une seule ligne de code qui ne répond pas une Business Value, à une ligne budgétaire : aucun over-engineering.

Cette méthodologie de développement est appelée BDD pour Behavior Driven Development.

Vous aurez compris la démarche, à la base des exemples que nous avons identifiés ensemble lors du 3 AMIGOS et de l’EXAMPLE MAPPING,

nous posons un test, puis nous codons,

puis nous posons un deuxième test, puis nous codons

etc…

Entre-deux, nous « refactorons ». Nous parlerons donc plutôt d’émergence que de conception logiciel.

Pour l’équipe, c’est le 2ème projet (après feu application AXA Banque by Guilde de DEV) développé à 100% en BDD. Actuellement nous avons 1000 tests de ce type.

En moyenne dans une journée, un développeur va exécuter sur son poste 20 fois les 1000 tests, ce qui lui permet d’écrire son code. Ils sont rapides à exécuter moins de 5 secondes pour les 1000. Ces tests sont également automatiquement exécutés lors de la mise en commun du code entre les développeurs et lors de toutes les livraisons.

Si nous exécutions nos tests par l’interface (en ouvrant l’application), il nous faudrait en moyenne 3 à 5 minutes par test.

Et donc, nous y arrivons, 20 exécutions * 1000 Tests * 5 min = nous économisons 100 000 min par jour, soit plus de 220 JH, une année ouvrée. CQFD 😜

Anticipons quelques questions :

Avons-nous encore besoin d’une équipe de testeurs ?

Évidemment, la preuve est dans l’exemple que nous avons choisi… mais pourquoi ?

Déjà nos 1000 tests ont permis d’écrire 95% de nos lignes de code… (la bonne manière de parler de la couverture de code). C’est énorme, mais de manière surprenante ce n’est pas le 100% promis par la méthodologie. Nos tests dictent le « moteur », la partie « intelligente » et « métier » de l’application. Pour nous permettre de tester cette partie, nous avons dû nous aménager des « trappes » permettant d’injecter des données et de vérifier les attendus. Même si ces trappes sont positionnées de manière a couvrir au maximum la machinerie, il reste une fine couche de code non couvert. Nous nous assurons que ce code soit « bête » : aucun métier, aucun contrôle, juste du câblage.

Mais il peut-être, malheureusement, source d’anomalie. Ce code ne peut être vérifié que dans les conditions réelles, avec des tests d’interface exécutés par l’équipe de testeurs manuellement ou automatiquement. Nous préconisons d’automatiser à minima tous les parcours clés.

Nos tests sont « unitaires », ils couvrent plus difficilement des workflows complexes.

Nos tests sont « métiers ». Ils doivent être complétés par des tests aux limites, exploratoires, sous contraintes etc…

Le cerveau et l’œil humain sont indispensables car malheureusement, il peut y avoir des « trous dans la raquette » : une règle mal comprise, oubliée… L’exemple en est une preuve…

L’équipe de test et de développement doivent travailler en totale complémentarité. Ça va même plus loin, comme le code est directement issu du besoin exprimé (les exemples), la complémentarité doit aller du METIER/PRODUIT/DEV/TEST/OPS.

Ces économies sont-elles applicables à mon projet ?

Mieux, elles sont obligatoires…. Le BDD a été désigné incontournable depuis 2016 : toutes les lignes de code produites par la GUILDE de DEV doivent être produites de cette manière. Exigez l’excellence 😜

Mais nous sommes sur un progiciel, ce n’est pas possible ?

Une instance appelée « Radar des technologiques » évalue et valide l’ensemble des technologies pouvant être utilisé dans la maison. Un des critères d’évaluation est la « testabilité » : Est-ce que la technologie permet bien de tester du code avec du code ? Par exemple, sur le projet AXA+ l’équipe a dû prouver que KOTLIN, langage utilisé sur ANDROID, était conforme.

Donc oui, c’est possible, sinon vous n’auriez pas pu utiliser votre technologie.

Comment suivre la mise en place de cette méthodologie sur mon projet ?

Comme nous avons vu, les tests sont en langage naturel et dans la langue du métier, donc exposés à tous dans un document appelé « LiveDoc ». Il suffit de vérifier son existence et de suivre son évolution. La « LiveDoc » sera la seule documentation qui ne mentira jamais, qui ne sera jamais obsolète, qui ne coûte rien à maintenir : Pour cause, elle est directement connectée au code de votre projet.