Je m'appelle Thierry Leriche-Dessirier. Je travaille comme consultant freelance sur des projets Web Java JEE sur de l’architecture et/ou du développement, depuis une petite douzaine d'années. A force d’aller de mission en mission, et d’atterrir trop souvent dans des équipes désorganisées, voulant bien faire mais se noyant dans les processus, avançant dans le noir et sans guide, j’ai décidé de prendre les choses en main, quitte à bouleverser certains codes. La méthode 3T que je propose est l’un des fruits de cette démarche.
Depuis quelques temps déjà, je m’investis dans la formation des plus jeunes mais aussi de ses collègues et amis. Je suis d'ailleurs professeur de Génie Logiciel et coach sur des projets de formation humaine. Entre deux biberons, je suis aussi rédacteur pour Developpez.com.
Les tests sont accusés de tous les mots ; ils coutent cher, prennent du temps à développer, sont complexes à maintenir, etc. Et il faut bien reconnaître que ce constat est souvent exact, ce qui n’encourage pas les chefs à les budgéter. Pourtant, les tests sont à la base d’une démarche qualité digne de ce nom. Des méthodes comme les TDD (Test Driven Development) placent les tests au cœur des développements et s’en servent comme d’une force pour guider les équipes ; les promesses sont nombreuses.
Toutefois, et c’est une situation que je retrouve de manière récurrente à chaque fois que je rejoins un projet, je constate que les acteurs (développeurs, chef de projet, testeurs, architectes, etc.) se demandent par quel bout prendre cette affaire. Qui fait quoi ? Quand ? Comment ? Pourquoi ? Quid de l’agilité ? Les TDD posent de nombreuses questions et imposent des pratiques délicates : c’est magique mais ça ne marche pas tout seul.
Pendant longtemps, je me suis demandé comment répondre aux attentes (budget, planning, organisation, turnover, complexité, normes, code, habitudes, etc.) spécifiques de chacun. J’ai tenté d’identifier les éléments qui me paraissaient essentiels et qui couvraient la majorité des cas. J’ai cherché une version simplifiée, facile à mettre en œuvre et à mécaniser, quitte à ne pas respecter tous les principes des TDD. Progressivement s’est alors dessinée 3T : les Tests en Trois Temps.
La méthode 3T diverge des TDD en proposant des mécanismes plus simples qui suffisent dans la plupart des cas. 3T s’adresse principalement aux développeurs mais inclue de quoi satisfaire les autres membres de l’équipe, à commencer par le chef de projet. Le point de départ de la méthode est le cahier des charges, à partir duquel on tire un jeu de règles, pouvant être présentées/pensées sous forme de fiches et/ou de post-it, et intégrables avec Scrum et/ou Kanban par exemple. L’écriture des tests et du code de production, réalisée par des personnes différentes, est ensuite guidée et mécanisée en grande partie.
Durant cette présentation, je propose de revenir rapidement sur les enjeux des tests, de comprendre ce qu’ils apportent et pourquoi ils ont mauvaise presse (tests bidons, tests de complaisance, tests non maintenus, etc.) Je passerai en revue les raisons qui rendent les équipes mal à l’aise vis-à-vis des TDD. Enfin, je présenterai les Tests en Trois Temps (3T) à travers une mise en situation simple.
A noter que 3T a déjà été présentée sur Developpez.com à travers plusieurs articles (http://icauda.com/articles.html#3t) :
* Proposition des Tests en Trois Temps ;
* Miniroman humoristique d’une équipe mariant Scrum et 3T ;
* 3T sur un cas pratique en 5 minutes.