Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui je suis avec J.P. Lambert, J.P. Bonjour.
Bonjour.
J'avais envie de te proposer qu'en parlant d'un sujet, j'ai vu un article qui parlait de
pourquoi l'automatisation des tests échoue.
Tu t'imagines bien qu'un sujet pareil est venu me gratter l'oreille.
Qu'est-ce que tu entends par là exactement ?
En fait, globalement, c'est un sujet qui est carrément à la mode et c'est normal
puisque finalement, ça devient inévitable.
Voilà, c'est du développement à l'ancienne, de ne pas faire d'automatisation de tests.
Mais c'est très compliqué de réussir à le faire et de bien le faire, c'est pas simple du tout.
Donc effectivement, la conclusion, ça marche pas.
Ils font des tests, ils y arrivent pas.
Alors quand ils sont un peu motivés, ils font plusieurs tests et puis éventuellement ils y arrivent.
Mais il y a aussi pas mal d'équipes où la situation, effectivement, on va les voir et puis ils te disent
« Ah non, mais ça, c'est de la merde, ça marche pas ».
Et ce qui est intéressant, c'est quand tu arrives un peu en extérieur et tu creuses et tu te remontes.
« Ah mais oui, mais là, ça, c'était pas ça, ça vous y êtes mal pris ou ça, machin ».
Et on s'en compte qu'il y a un peu des règles de base qui sont souvent oubliées,
qui font que ça marche pas ou ça marche hot.
C'est que finalement, on investit énormément pour peu de gains alors que non, il faudrait rentabiliser à fond.
C'est un peu ça, l'idée.
Mais après, tu parles de quel type d'automatisation ?
Moi, quand je t'écoute parler, pour moi, on va rentrer un peu dans les nuances peut-être,
mais il y a l'automatisation de type Test First, TDD, tout ce qui va être pris en charge par le développeur.
Et ça, je suis bien d'accord avec toi, c'est difficile.
Mais je vois pas tellement de résultats en demi-teinte, soit tu y arrives, soit tu y c'est un peu binaire le TDD,
soit tu y arrives, soit tu n'y arrives pas.
D'ailleurs, ça se voit bien, soit il y a des tests, soit il n'y en a pas sur un projet en général,
il y en a rarement un peu, à moitié.
Ou alors, est-ce que tu parles de tests à posteriori ?
Parce qu'il y a aussi ce truc-là, d'attaquer l'angle QA, et de dire, aujourd'hui faire du run de non-reg, ça coûte trop cher.
Comment est-ce qu'on automatise ça ?
Ce qui est une démarche que je trouve sur le principe intelligente.
Mais dans les faits, ce que je vois être difficile à mettre en œuvre.
Et souvent, on perçut comme quelque chose d'assez coûteux.
De quoi est-ce que tu parles exactement quand tu dis que l'automatisation des tests est chou
ou est perçue comme quelque chose qui est chou dans les entreprises ?
Effectivement, je parle plutôt du deuxième sujet, plutôt au sens QA.
Ce n'est pas forcément que du posteriori, puisqu'il y a aussi tout le sujet des tests d'acceptation automatisés.
Acceptance.
Là, on n'est pas non plus au niveau unitaire, mais qui est là aussi un sujet pas forcément simple à mettre en place.
Après, il y a quand même un lien avec tout ce qui est test unitaire et TDD.
Et si on va dans le concret, d'ailleurs, c'est une des manières de se rater.
C'est de faire des automatisations de tests bout en bout, très haut niveau, qui coûtent cher à mettre en place,
qui coûtent encore plus cher à maintenir.
Et pourtant derrière, on a un covrel, je parle de test unitaire, qui est inexistant ou faible, trop faible.
C'est typiquement...
Et là, le problème, ce n'est pas tant qu'on s'y est mal pris pour implémenter le test de niveau.
Le problème, c'est que ces tests-là sont forcément coûteux, sauf que le jour où il échoue, on est content.
Ça nous a dit qu'il y avait un problème, mais il faut investiguer derrière.
Et quand on investigation et commence par...
L'ensemble du code derrière, il n'est pas testé, donc on ne sait pas où est-ce qu'il est le problème.
Oui, tu en investigues avant de prendre une semaine, et forcément dans les deux mois qui suivent,
on va arrêter de maintenir ce test, parce qu'il coûte trop cher.
Et c'est un fait, il coûte trop cher.
Donc voilà, ça va.
Donc ça, c'est un exemple de comment on peut se rater.
On se lance dans ces tests de niveau, alors qu'on n'a pas déjà un bon coverage de bas niveau, en fait, par le test unitaire.
Oui, ce que tu dis, c'est que juste d'avoir le filet de sécurité, ne suffit pas, c'est mieux.
Mais ça ne suffit pas.
Et du coup, on se retrouve dans des situations où l'effort à fournir pour prendre en compte cet info,
elle est difficile à...
L'effort à fournir est trop élevé.
C'est vraiment...
Quand le test échoue, il faut faire une investigation.
En gros, soit s'il y a un problème, parce qu'on s'est effectivement raté,
c'est une régression, maintenant il faut trouver où.
Parfois, c'est même juste l'outillage ou la mise en place, parce que c'est des choses qui sont assez complexes, en fait, à mettre en place et à maîtriser.
Donc si déjà, on ne commence pas par...
Voilà, en gros, on trace une carte de tous les coupables possibles et on coche au fur et à mesure.
C'est pas lui, c'est pas lui.
Forcément, si d'un côté on a de la test unitaire, il me dise,
déjà, ce n'est pas tous ces gens-là.
Là maintenant, voilà.
Ça réduit beaucoup l'éventualité des coupables.
Donc du coup, on arrive à comprendre pourquoi le test échoue relativement rapidement.
Quand en plus, on commence par avoir l'intérêt d'être du produit qui peut être fautif
et on ne sait pas l'investiguer directement parce qu'on n'a pas ces tests unitaires,
bah voilà, l'investigation, elle va forcément être énormément coûteuse et...
Voilà, ça, c'est une recette pour l'échec.
Mais finalement, c'est quoi la différence avec des tests,
par exemple, une non-reg qui serait pas automatique, donc qui serait manuelle ?
Est-ce qu'on aurait plus les moyens d'investiguer ?
Non, t'as raison.
T'as raison, la différence, c'est juste que le coût de maintenance entre guillemets et palme même,
c'est que d'un côté, ça te coûte quasiment rien de mettre une personne en place qui déroule,
après, ça te coûte cher sur le long terme, puisqu'il va utiliser des heures à chaque fois,
que ton automatisation, c'est une autre forme de maintenance,
et puis ce n'est pas les mêmes personnes.
Mais l'aspect, maintenant, c'est juste essentiel, c'est que écrire des tests mais qui coûtent cher à maintenir,
naturellement, le test va mourir en fait, et du coup, il ne sert plus à rien.
Oui, t'as raison, et sous cet angle-là, c'est vachement intéressant,
parce qu'en t'aider, les tests coûtent assez peu cher à mettre à niveau.
Alors qu'effectivement, quand tu es dans une logique du QA posteriori de non-reg à posteriori,
que je parle toujours à posteriori par rapport au dev,
ce sont des tests qui vont être assez potentiellement assez coûteux, faire à mettre en place.
Je pense que tu connais ça, c'est la pyramide des tests, la pyramide de Cone,
qui nous dit qu'il y a différents types de tests,
en bas on va détester assez bas niveau, typiquement les tests unitaires,
un peu plus haut des tests d'assemblage, etc.
Puis on monte, on monte en gamme, et quand on arrive tout en haut,
on est sur des tests de bout en bout qui passent par la UAE, etc.
Et pourquoi c'est une pyramide ?
Parce que plus on monte, plus c'est des tests qui sont coûteux à mettre en place, coûteux à maintenir,
donc il en faut moins.
Donc effectivement, la bonne stratégie de test, c'est que les tests en bas qui ne coûtent pas cher,
on en fait le plus possible.
Oui, parce que là tu parles du coût de maintenance,
et je te rejoins, mais il y a aussi un autre coût qui est le coût de run.
Aussi, tout à fait.
Un test cucumber, moi je travaille sur une stack Roar, donc je suis avec Airspec et cucumber,
un test cucumber, il est vachement plus lent,
tu instances un browser, tu fais des trucs, tu as un serveur complet,
c'est mou quoi. Alors qu'un test unitaire, c'est quelques games de secondes.
Donc tu as aussi le coût au run, et c'est pas négligeable,
quand tu lances la batterie de test plusieurs fois dans la journée,
si ta batterie de test elle met une heure ou elle met cinq minutes,
ou même un quart d'heure vers cinq minutes, tu as une vraie différence.
Ce qui est intéressant dans cette vision là, c'est que c'est exactement ce pourquoi
on veut un QA ou un testeur dans l'équipe.
Quelqu'un dont une décompétence de base, c'est de la gestion de risque,
c'est savoir faire un calcul de ROI.
Est-ce que ce test là, on doit l'implémenter ou pas,
est-ce qu'on doit l'automatiser, est-ce qu'on doit le faire tout court,
si on a un temps limité, est-ce qu'on le fait ou pas ?
Et c'est ça en fait, c'est effectivement,
le ROI nous dit que globalement on va essayer de viser les 100% de coverage,
et ça ne coûtera pas cher, que par contre en haut,
il va falloir être assez smart sur qu'est-ce qu'on teste,
parce qu'on ne peut pas tester stigmatiquement tout.
Eh bah écoute, je t'en remercie, je te propose que ce soit le mot de la fin.
C'est un marche.
Merci J.P.
Avec plaisir.
Quand t'as toi cher auditeur, j'espère que tu as kiffé cet épisode.
Si c'est le cas, je t'invite à venir découvrir le travail de J.P.
Un travail incroyable, tu tapes Scrum Life dans YouTube,
et tu vas trouver tout ça,
ou alors tu peux aller aussi sur son blog jp-lambair.me
si ma mémoire est bonne, c'est ça J.P.
Tout à fait, tout à fait.
Et je te dis à demain, salut.