Une équipe s'est présentée avec comme problématique une forte augmentation du nombre de bugs en phase de test.

L'équipe s'appuyait uniquement par le passé sur des tests lourds en terme de temps d'exécution et fragiles car très couplés au détail d'implémentation. Cette stratégie impliquait une frustration importante et l'équipe a ainsi décidé d'arrêter complètement de tester l'application de manière automatique, déplaçant cette responsabilité à l'équipe de test.

Pour leur permettre de réintroduire sereinement des tests automatiques, nous avons ensemble travaillé à identifier les composants de leur solution qui centralisaient la logique métier. Nous avons organisé un premier atelier pour retirer des use cases toute dépendance forte à de l'infrastructure. Une fois fait, plus aucun élément n'entravait la testabilité de la solution sur ces composants critiques. L'atelier a permis de mettre en avant l'importance de l'inversion de dépendances que ce soit dans le code de production ou dans les tests.

La deuxième étape a consisté à prendre en main une stratégie de tests rapides et indépendants les uns des autres (tests F.I.R.S.T.). Nous avons ensemble pris un premier use case puis l'avons petit à petit dupliqué en utilisant une approche TDD et Golden Master. Lorsque nous avons terminé, les deux use cases couvraient le même comportement et le plus ancien a été tout simplement supprimé.

Tout au long de ce coaching, des notions clean code ont été abordées par petit bout pour sensibiliser l'équipe à l'importance du principe simple de boyscout.

L'équipe continue maintenant d'évoluer seule et des petits ateliers sont de temps en temps organisés pour s'assurer que les pratiques sont bien suivis et que cette responsabilisation est bien adoptée par l'équipe et non quelques individus.

--------

Icon credit goes to surang (https://www.flaticon.com/free-icons/testing)