Vers l’époque où le terme “software engineering” a été inventé, cette blague circulait :

À une assemblée de consultants spécialisés dans le développement de logiciel, un journaliste demande : à main levée, qui d’entre vous accepterait de monter à bord d’un avion dont le pilote est un programme ?

Personne ne lève la main. Silence.

Au bout d’une minute, une main se lève :

— Je monte sans hésiter. L’avion ne pourra même pas se déplacer vers la piste.

Clara est testeuse. Son métier consiste à questionner un produit afin d’y trouver des problèmes. De son propre aveu, la difficulté dans son travail, ce n’est bien sûr pas quand elle en trouve. C’est quand elle monte à bord d’avions qui ne décollent pas.

Clara

  • aime explorer des contextes nouveaux
  • possède une intuition remarquable pour “casser” un produit
  • ne ménage pas ses interlocuteurs

Jérémie est technical lead. Son métier consiste à répondre aux défis que représente le développement d’un logiciel qui va changer la face du monde, ou au moins disrupter l’éco-système.

Jérémie

  • a des idées géniales et comprend vite
  • maîtrise à fond plus d’une douzaine de technologies
  • ne vérifie pas son code

Entre Clara et Jérémie, c’est le clash. On parle de “conflit de personnalité”. Il y a eu des mots durs, de part et d’autre. Mais en décortiquant un peu les échanges, on décèle un conflit d’idées :

Clara considère que les vérifications “de base”, celles qui consistent à s’assurer que le comportement du code d’une classe ou d’une fonction est conforme à l’intention de son développeur, sont la responsabilité de ce développeur.

Jérémie, comme la majorité de ses collègues, pour qui il est un modèle, considère que les vérifications et la conformité aux besoins sont l’affaire des testeurs et de la QA en général, dont le rôle est de valider en aval le travail qui a été fait en amont.

Xavier, le CTO, assis à son bureau à les écouter depuis 30 minutes, réalise au détour d’une remarque qu’il se trouve en fait face à un conflit de ressources : Clara n’a pas le temps de rechercher a posteriori des défauts complexes et subtils du produit parce qu’elle le passe à remonter des défauts évidents et décelables a priori. Et elle est maintenant débordée.

Xavier sait grâce à des échanges avec d’autres CTOs que les problèmes de pointeur nul, de calcul incorrect, d’erreur aux limites, de conditions manquantes, pourraient être détectés en un temps record au moment du build par un harnais de vérifications automatisées. Et que les DEVs sont les mieux placés pour créer ce harnais et le faire évoluer au plus près du code en train de s’écrire.

Il paye Clara à vérifier manuellement le code des DEVs et à relever leurs erreurs de programmation.

Son budget de test, qui devait plutôt servir à prévenir des problèmes subtils dans le produit, y passe tout entier, et n’y suffira pas.

Il dit : “Merci à vous deux. Jérémie, si tu peux rester, j’ai une demande à te faire…”

regulateur-8

Stay Tuned!

Publié sur Linked In le 30/10/2024