[OCTO Talks] Retour sur le lancement de Culture Test
À l’occasion du lancement de la trilogie Culture Test, en partenariat avec le CNES, les auteur•rice•s Sylvie Ponthus-Violland, Christophe Breheret-Girardin et Stéphane Bedeau se sont réunis pour évoquer les racines d’un projet de plus de 3 ans co-construit par une quinzaine d’Octos et ex-Octos.
Retour en prose et en images.
Tester, c’est coder !
En écrivant ce livre nous nous sommes fait cette conviction : tester, c’est coder. En effet, la blague bien connue “tester, c’est douter” nous fatigue. Cette blague on peut la retrouver dans les bureaux, un joli poster et une promesse assumée que les développeurs en fait ne sont pas des gens sérieux. Or, coder, c’est sérieux. Tester c’est coder car tester c’est :
- construire du code ;
- défendre du code, à court terme ou moyen terme grâce aux tests ;
- oublier du code, documenter du code grâce aux libellés des tests.
C’est difficile de croire que le développeur peut mettre toute sa réflexion en mémoire. Les tests vont l’aider à construire le code, et ils vont aussi l’aider à assurer la maintenabilité du logiciel.
Il était une fois…
Nous n’allons pas “juste” expliquer nos convictions. Nous voulons raconter ce que nous voyons, nous avons décidé de raconter une histoire. Parce que dans la théorie et dans la vraie vie, il y a une différence : dans la théorie tout le monde est d'accord pour écrire des tests, et pourtant dans la vraie vie, peu d’équipes en font, peu d'applications ont des tests automatisés. Pourquoi un tel écart ?
C’est dommage, car il sera de plus en plus difficile de :
- trouver la raison d’un bug ;
- se souvenir de ce que l’on a fait.
Nous constatons que les mises en validation sont difficiles, que les mises en production sont difficiles alors que les tests peuvent nous sauver.
“On doit faire une refonte !”
Et c’est de pire en pire. Demandez à quelqu’un au début d’un projet comment il va, il répondra de manière enjouée qu’il est ravi d’ajouter des fonctionnalités. Questionnez le au bout de 6 mois, 1 an, 3 ans, s'il n'y a pas de tests, il sera de plus en plus embêté pour vous répondre. La réponse qu’il donnera est que ça ira moins bien. Ça ne peut pas être ça le génie logiciel, une industrie qui, avec le temps, assure que tout aille de moins en moins bien. Et la sentence est triste, la seule solution est de tout reprendre à zéro. On l’entend souvent. C’est accepté, comme une étape dans le cycle de vie du génie logiciel : la refonte. Elle a des dégâts cette refonte, des dégâts techniques et humains. Techniquement, il faudra tout effacer, tout remettre en cause, et tout recommencer pour retrouver la qualité. Humainement, il y aura des départs, car c’est épuisant, beaucoup d’énergie investie et beaucoup de déception, c’est difficilement supportable.
Ce qu’en disent les études et notre expérience du terrain
Souvent, les personnes disent que la qualité coûte cher. Mais si la qualité semble coûter cher, c’est la non qualité qui coûte vraiment très cher.
Prenons le cas des anomalies, car c'est un sujet qui parle à tout le monde. Il est évident que si on écrit un bout de code et que l’on voit immédiatement une petite coquille, le coût de la réparation est rapide, de l’ordre de quelques secondes. Par contre, si cette anomalie est vue en production, cela va coûter beaucoup plus cher.
Pourquoi ?
Tout d’abord, cela peut engendrer un blocage du système qui peut provoquer un manque à gagner, voire même une perte sèche.
Même dans le cas contraire, sans aspect financier direct, quelqu'un va constater l'anomalie, la consigner dans un outil, l'affecter à une équipe. Un développeur va alors l’analyser, essayer de comprendre, essayer de corriger, quelqu'un peut potentiellement valider ou invalider la correction. Si c'est invalidé, ça repart dans ce même cycle. Parfois la correction peut même déclencher une anomalie ailleurs. Dans la plupart des cas, la correction part dans plusieurs environnements avec pas mal de contrôles à chaque fois, jusqu'à la mise en production. Tout ceci coûte effectivement très cher.
Donc dans le cadre d'une détection entre le développement et la production, avec les différents environnements, cela amène un coût également, c'est la courbe grise claire du graphique ci-dessous.
Un ordre de grandeur ici : 25$ pour découverte d'un bug en développement et 16 000$ pour un bug détecté en production.
Le graphique montre que les bugs sont plus introduits en phase de développement que par la suite avec la courbe grise foncée. Mais la courbe orange de détection ne suit pas la même trajectoire. On découvre moins de bugs en phase développement que par la suite, et c’est ça qu’il faut changer ce qui va permettre de diminuer drastiquement le coût.
Le tableau, ci-dessous, est vraiment pratique pour analyser la situation de son équipe face à son produit. Par exemple, si nous livrons des fonctionnalités régulièrement en production, avec un nombre d'anomalie qui diminue, tout comme la dette technique, alors la situation est idéale.
À l'inverse totale, si le nombre de fonctionnalités livrées est en baisse, si le nombre de bug est en baisse, ainsi que la dette technique, l’application considérée comme immobilisée car nous n'apportons plus de valeur puisque nous désendettons notre application. Entre les deux, la situation est soit satisfaisante, soit sans rien de particulier à signaler, soit il y a un danger ou révélateur d’une crise de qualité.
Dans quelle situation êtes-vous ?
Ce que nous avons remarqué, c'est la tendance pour certains à être addict aux bugs. Et comme toute addiction, on ne la voit pas venir.
Cette addiction se manifeste comme ceci : 
Plus vous avez de bug, plus vous les corrigez et plus vous les corrigez, moins vous avez de temps pour investir dans la qualité, donc celle-ci diminue ou ne s'améliore pas, ce qui entraîne de nouveaux bugs.
On arrive donc au cercle vicieux où plus on a de bug, plus on a de nouveaux bugs. Et cette situation amène naturellement un dépassement de budget.
A contrario, dans ce genre de situation, admettons que nous prenions la décision contre-intuitive d’arrêter de corriger les bugs et de passer plus de temps sur la qualité. Il y a alors moins de bugs au final et donc un budget qui va tendre vers l'équilibre.
Cependant, il est préférable d’anticiper et prendre soin de la qualité, avant de se retrouver dans cette situation. undefined
So what?
“There is a better way”, tel est le motto d’OCTO Technology. Pour sortir de l’addiction aux bugs, il faut revenir aux bases et créer des boucles de feedbacks rapides. Les tests automatisés nous permettent de réussir cette prouesse.
Grâce à eux, nous pouvons nous réinscrire dans une dynamique d’apprentissage permanent qui valorise les échecs. On échoue vite, on apprend vite et on s’améliore vite pour obtenir rapidement des résultats du terrain.
Le bénéfice est double :
- nous pouvons aider des utilisateur•rice•s plus rapidement et précisément à chaque itération ;
- nous pouvons percevoir un retour sur investissement plus rapidement.
Dès lors, le cercle vicieux n’est plus et laisse place à un cercle vertueux d’enrichissement culturel et technique grâce auquel nous pouvons rendre un service numérique qui :
- s’améliore avec le temps plutôt que de se détériorer ;
- garantit son bon fonctionnement grâce à des filets de sécurité et qui peut être réparé rapidement ;
- facilite une mise sur le marché rapide et à moindre coût grâce à des correctifs au plus tôt et au plus près des problèmes.
Imaginons maintenant une startup qui propose une application de location de véhicules électriques. Cette entreprise est à la pointe de l’innovation et respecte scrupuleusement l’État de l’Art sur les tests automatisés. Les premiers retours sont encourageants et l’entreprise se développe. Tout roule alors ? Non !
Le développeur qui a réalisé les tests automatisés n'a pas pu simuler facilement : il est impossible de déverrouiller un véhicule lorsqu’il est garé dans une zone non couverte par le réseau internet et téléphonique. Le testeur manuel s'approche de la voiture, déverrouille, et constate que cela ne fonctionne pas.
Les vérifications automatisées réalisées par les devs sont différentes et complémentaires des tests manuels éventuellement automatisés réalisés par d’autres corps de métier.
Chaque intervenant a des compétences spécifiques et un rôle unique sur le terrain de jeu des tests. Ce rôle est parfois opaque entre les autres intervenants. Pourtant, il est nécessaire de travailler ensemble pour livrer un produit de qualité et créer un lien empathique fort avec les utilisateurs.
Pour travailler ensemble et créer un produit de qualité, il faut créer un changement profond au niveau organisationnel. C’est ce que nous énonce la Loi de Conway :
“Toute organisation qui conçoit un système, au sens large, concevra une structure qui sera la copie de la structure de communication de l’organisation.”
En d’autres termes, tous les services d’une organisation ont un impact sur le code produit, même le service RH et le service dédié à la finance et/ou la comptabilité.
Nous avons donc écrit Culture Test afin de proposer un support durable d’accompagnement et d’aide au changement des organisations.
La trilogie Culture Test
Le monde des tests est riche, vaste et extrêmement complexe à appréhender. Cette trilogie de livres est un voyage culturel et initiatique qui s'inspire de notre expérience du terrain, de nos rencontres et de notre propre apprentissage. Tout au long du chemin, vous découvrirez une culture qui a vocation à prendre soin des gens et à maximiser l'impact du produit.
Ces livres forment une histoire, c’est un documentaire-fiction. Nous avons utilisé toute notre expérience pour raconter l’histoire de Gaël et de ses collègues qui découvrent les tests. Gaël est fort, Gaël est fier et pourtant, il n’écrit pas de tests. Tout au long de cette histoire, nous expliquons les comportements de Gaël et les tests.
Ainsi, nous alternons histoire et explications techniques. Vous pouvez tout lire, l’histoire seulement ou les explications seulement, la mise en page vous y aide. Nous avons voulu cette alternance pour montrer ce qui se passe dans la tête de Gaël, et montrer que les tests rendent Gaël indestructible.
Cette trilogie n’est pas un manuel de tests à appliquer pour un projet parfait : la recette de cuisine unique exhaustive relève du fantasme. D’ailleurs, les cuisinières et cuisiniers les plus avertis connaissent leurs recettes et malgré tout, ils utilisent leurs sens et acceptent ainsi la perfection de l’imperfection.
Ces livres proposent une approche pragmatique, à l’image des découvertes de Gaël et de son équipe. En vrac, nous allons parler de tests automatisés, de BDD, d’égo, de la place des tests, et de bien d’autres choses. Comment savent-ils qu’ils ont réalisé assez de tests ? Ils se rappellent pourquoi ils testent : pour construire leur code, pour bâtir des défenses, pour oublier, ne plus avoir peur et vivre sereinement. Si leurs tests leur permettent ça, alors oui ils ont réalisé assez de tests.
Lien de téléchargement gratuit aux formats pdf et liseuse : https://publication.octo.com/culture-test-vol-1
Les volumes 2 et 3 arrivent bientôt !
<Roooooh ils font comme les Community Managers des services de SVOD>
A propos des auteur•rice•s
Sylvie Ponthus-Violland
Développeuse, cheffe de projet, coach agile, Sylvie se passionne pour le développement de logiciels utiles, fiables et agréables à utiliser.
Christophe Breheret-Girardin
Coach craft, formateur et conférencier, Christophe partage avec enthousiasme ses connaissances, afin d’inspirer et de guider chacun vers son plein potentiel.
Stéphane Bedeau
Développeur et formateur, Stéphane a un goût prononcé pour les approches empathiques et la réalisation de produits numériques responsables de qualité.