Je reviens sur ma première expérimentation du BDD en mission d’accompagnement agile de 2 équipes.

Le point de départ est un certain nombre d’incidents survenus en production avec comme principal suspect un composant majeur et historique dans l’architecture logicielle.

Sans environnement de test disponible pour reproduire le problème, aucun développeur n’osait s’engager sur une correction au caractère à la fois urgent et important. Celui qui y parviendrait deviendrait le héros de l’équipe, mais à trop tarder ou mal corriger, il en perdrait probablement tout son honneur, malgré tous ses efforts. Là où réussir est obligatoire, l’échec n’est pas permis.

Dans ce contexte, comment faciliter la résolution du problème entre ses parties prenantes ?

Il a fallu plusieurs actions à différents niveaux:

• Faire accepter collectivement la situation présente
• Inciter à collecter et partager des informations factuelles avec les bonnes personnes
• Assumer une responsabilité collective pour le passé comme pour les futures actions afin de limiter le sentiment de culpabilité aussi par anticipation de ceux qui sont en capacité de faire quelque chose.
• Donner les moyens de bien faire les choses, en co-construisant un plan de bataille pour augmenter les chances de résolution technique et éviter la noyade.

Le plan de résolution de l’équipe technique:

1. Représenter l’architecture du système de production actuelle avec ses sous-systèmes et interfaces pour identifier la stratégie et l’environnement technique le plus adapté pour assurer une correction. Cette étape a révélé la nécessité de créer un nouvel environnement spécifique aux tests d’intégration de plusieurs composants.

2. Monter un environnement de test du système “minimal” en terme d’effort qui permette de reproduire le problème et de s’y pencher à plusieurs.

3. Créer un scénario de test avec des données d’entrée représentatives des cas d’incidents relevés en production

Ce plan d’équipe a bien fonctionné à part l’aspect “collectif” dans un premier temps. Si une seule personne s’est vraiment concentrée sur la correction “rapide”, l’équipe a souhaité poursuivre l’effort d’amélioration de la testabilité des cas d’utilisation les plus pertinents afin de diminuer les risques de problèmes du même type.

BDD, une pratique technique pour coder les tests métier

En complément de la facilicitation de ces événements critiques, je suis aussi intervenu sur la définition et l’implémentation même de la stratégie de tests du workflow de gestion. Ma proposition retenue a été d’outiller les tests d’API avec l’approche BDD Behavior Driven Development.

Le framework de tests que j’ai utilisé est Cucumber-Java, avec quelques bibliothèques complémentaires forts utiles comme rest-assured, pour faciliter les appels REST et les assertions sur le résultats.

Une fois un premier inventaire fonctionnel macro pour structurer les tests, les premières difficultés sont

• de monter un environnement de test avec ce qui est commun à tous les tests et ce qui est propre à suite ou cas de test
• d’identifier le référentiel et les jeux de données de test et faciliter leur gestion de configuration

L’attention continue a été de veiller à l’adoption collective du framework, en proposant d’implémenter en pair programming un test sur un incident en cours.

Après 2 sprints, la définition de fini de l’équipe incluait modestement:

• chaque incident a fait l’objet d’une réflexion et si opportun d’une implémentation du cas nominal sur cucumber
• les cucumbers sont verts

Après cette mission, j’ai continué à revoir l’équipe pour des restos très convivaux. Les meilleurs comportements persistent pour peu que l’on y fasse attention.

REX à froid

Depuis, j’ai rencontré des équipes qui avaient essayé plusieurs choses sur différents projets avec toujours les mêmes écueils : l’utilisation de mocks et des tests d’interface utilisateur laborieux.

Il n’y a pas de vérité absolue dans le domaine des tests logiciels. Si les grands principes sont maintenant connus (pyramide des tests), la mise en pratique reste un art. Il reste un principe qui me semble résister au temps: Même si les outillages de tests ne cessent de progresser, la complexité des tests croit inévitablement avec la complexité des applications et celle des organisations.

Le BDD en formalisant le TDD pour concevoir et tester l’intégration des systèmes et sous-systèmes, fait gagner en qualité la documentation en même temps que la fiabilité des interfaces (API)

Ce que j’apprécie des missions mixtes, multi-casquettes, c’est l’alignement et la complémentarité des activités qui servent les unes aux autres.

Cette mission de coaching agile et BDD a permis de relancer l’équipe à partir d’une base qui lève les freins et croyances limitantes jusque là.

Behavior Driven Development ne porte ainsi pas que sur la modélidation et le test des comportements du système informatique. Ajouter cette pratique dans un contexte d’équipe c’est aussi faire évoluer les comportements de chacun dans l’équipe pour s’assurer de bien faire les choses.

Le système construit hérite des qualités (et défauts) de l’équipe créatrice. Cela rappelle la loi de Conway et son inverse. J’appele ça plus largement l’auto-similarité.

Références

• Coaching humain : Echelle de responsabilité de Christopher Avery

• Mentoring technique : Cucumber & rest-assured