Genchi Genbutsu

J'eus l'occasion de rencontrer à nouveau M. K. dans des circonstances différentes de la première fois. Et bien qu'il n'eut guère l'occasion de l'expliquer, j'en appris plus sur sa philosophie.

Nous participions tous les deux au comité de pilotage hebdomadaire réunissant tous les chefs de projets du département. M. K. n'était pas un chef de projet, et je ne sais pas à quel titre précisément il participait au comité. En ce qui me concerne, je remplaçais mon responsable, alors en congés prolongés pour raison de santé.

M. K parlait très peu durant ces réunions, et il restait impassible, ce qui tenait pour moi de l'exploit. Le Chef de Département semblait ne pas beaucoup l'apprécier, et ne s'adressait jamais à lui. Lors d'un comité, il le prit tout de même à partie, à propos d'un indicateur sur un projet très critique. La discussion s'échauffait entre le Chef de Département et le responsable du projet :

- Ne dis pas que ton équipe tiendra les délais pour la livraison de décembre, alors que la couverture de tests est de seulement 15% !
- La couverture est basse, mais on suit le rythme, au moins.
- Mais tu sais qu'il faudra la remonter avant de passer en qualification !

Il réfléchissait en relisant tous les chiffres. Je ne savais pas ce que signifiait ce pourcentage, mais ça avait l'air préoccupant, grave même. Il reprit :

- Ou alors le chiffre est tronqué, peut être. K! Qu'en pensez vous, de sa couverture ?

M. K examina la copie des rapports dont il disposait. Puis il déclara :
- Je ne sais pas. Il faudrait descendre sur le plateau pour...
- Pas le temps! J'ai des contraintes, moi.
Et s'adressant à nouveau au chef de projet :
- Tu me montes cette converture de 10 points pour la semaine prochaine s'il te plaît, Robert.
- Entendu.
- "Next !"

Que Robert ait entendu ne pouvait faire aucun doute. C'est la façon dont il s'y prendrait qui restait un mystère.

La semaine suivante, le ton monta à nouveau entre le patron et le responsable de projet:
- Je t'ai demandé 25, et c'est 12 ! Explique moi !
- J'ai contacté le support Outils et Méthodes; le chiffre leur paraît normal.
- Normal ?! Mais il baisse ! Qu'est-ce qui se passe exactement ?
- Le développement avance vite, sur des parties que l'analyseur de code ne mesure pas correctement.
- Tu veux dire que l'outil n'est pas fiable ?
- Je ne peux pas l'affirmer, mais on réfléchit à une façon de le vérifier.
- A quoi travaillent les deux prestataires en plus que je t'ai affecté il y a quinze jours ?
- A l'IHM. Et je pense que le code de l'IHM fausse l'analyse de couverture.

Le Chef de Département interrogea M. K. du regard, et M. K répondit par un signe affirmatif.
- K. descendra chez toi pour voir ce qu'on peut faire. "Next !".

Robert souriait cordialement à M. K. en rassemblant ses rapports. Ses mains tremblaient légèrement.

Le comité suivant fut plus long que prévu, mais très instructif. La semaine passée, M. K était descendu sur le plateau. Quand le tour de Robert arriva, le Chef de Département ne lui donna pas la parole, mais se tourna vers M. K:
- La couverture est de 32% maintenant ! C'est mieux ! Peut-on savoir ce qui s'est passé ?
- Certainement. Je me suis permis d'observer et de discuter avec les développeurs sur le plateau.
- Ah. Le problème est-il dans leur code ou dans l'outil ?
- Disons que les développeurs et vous n'utilisez pas l'outil de la même manière.
- C'est à dire ?
- L'outil calcule le nombre de lignes de code exécutées lorsque les tests sont lancés, par rapport au nombre de lignes total du projet. Si ce pourcentage est faible, c'est qu'une grande partie du code n'est exécutée par aucun test.
- OK; nous savons tout ça. Où voulez vous en venir ?
- Ici, dans ce comité, vous utilisez l'outil pour connaître ce pourcentage. Sur le plateau, les développeurs utilisent l'outil pour l'augmenter. C'est différent. Ils surveillent le chiffre, et lorqu'ils estiment qu'il est insuffisant, il font en sorte de l'améliorer.
- Oui. C'est exactement ce qu'on attend de l'outil d'analyse de couverture !
- Sans doute. Mais certaines parties du code ont une couverture très basse, alors que d'autres sont à 90%.
- Et alors ? C'est la moyenne que nous utilisons.
- Et c'est aussi la moyenne, que les développeurs essaient de modifier.

Cette réponse sembla déconcerter le Chef de Département, qui fit une moue dubitative. M. K reprit son explication :
- Les développeurs m'ont montré comment il travaillent. La plupart du temps, ils écrivent du code neuf sans écrire les tests associés, ce qui se traduit par une baisse de l'indicateur. Lorsque celui-ci est trop bas, il écrivent des tests, mais pas forcément sur le code qu'ils viennent de créer.
- Ah bon ?
- Non. Le plus souvent, ils ouvrent les modules qui possèdent déjà une bonne couverture, et ils ajoutent des tests à ces modules.
- Pourquoi font-ils cela ?
- Parce que ces modules sont plus faciles à tester. Ils ne contiennent que de la logique, et non du code d'entrée/sortie ou d'IHM. Le résultat est que certains modules sont bien testés tandis que d'autres ne sont presque pas testés.

Le Chef de Département réfléchit un instant.
- Vous affirmez que l'indicateur manque de précision ?
- Oui, tant que l'on considère uniquement la moyenne; car on ne sait pas si cette moyenne indique que la plupart des modules ont une bonne couverture, ou que certains modules bien testés compensent pour ceux qui ne sont pas testés.
- Je vois. Et comment expliquez-vous les variations de ces dernières semaines ?
- Oh, c'est très simple. Les programmeurs chargés de l'IHM me l'ont expliqué : ils ont négligé pendant un temps les indicateurs, et n'ont pas corrigé la moyenne. Quand Robert a demandé qu'elle soit augmentée de 10 points, ils ont ajouté plus de tests sur un ancien module qui leur sert de "réserve" de tests.

Le Chef de Département émit tout bas un vilain juron, et reprit :
- Et pourquoi ont-ils négligé les indicateurs ?
- Parce qu'ils étaient trop occuppés sur le code de l'IHM. Ils ne s'occuppent de la couverture que lorsqu'ils en ont le temps.
- Et pourquoi manquaient-ils de temps cette fois là ?
- Parce que le module IHM contenait beaucoup de défauts, et que ces problèmes étaient plus urgents que celui de la couverture.
- Et pourquoi ce module contenait-il des défauts ?

M. K. dévisageait son interlocuteur. A cette seconde, on aurait pas su dire s'il lui offrait une chance de deviner, ou bien s'il refusait simplement de répondre.

Il déclara presque brutalement :
- Pour une raison simple: parce qu'il ne contient pas assez de tests. Les tests automatisés préviennent les défauts. Lorsqu'il n'y a pas de tests, les défauts surgissent.

M. K. se tut, et contempla rêveusement l'illustration qui pendait au mur de la salle de réunion. C'était une reproduction d'Escher représentant des fourmis rouges qui défilaient sur un anneau de Moebius.

Tout le comité restait abasourdi par cette explication. Le Chef de Département rompit le silence:
- Robert, tu fais en sorte que la couverture augmente de 10 points pour CHAQUE code source et tu surveilles de près tes prestataires. "Next!".