Pour commencer, après quelques péripéties (erreur sur la gare de RER, Val de fontenay != Fontenay sous Bois ), me voila sur les lieux dans le magnifique chalet de la porte jaune. Le cadre est très sympa, très vert avec un petit lac, des oies, des canards, des chats qui se baladent…
Je récupère mon badge ainsi que mon sac de goodies. Cette année, le cadeau était un timer (style minuteur de cuisine), cool, j’en voulais justement un (très important pour timeboxer une réunion).
La journée commence par une brève présentation, cela me permet de constater que l’évènement est une réussite : plus de 250 inscrits venant de toutes la France, de Belgique, du Canada (et d’ailleurs). Décidément, l’agilité en France à de beaux jours devant elle.

Première conférence de la journée : Comment soigner sa schizophrénie MOA/MOE

Le but de cette intervention était de monter comment rapprocher ces deux entités au travers des spécifications exécutables. L’accent est principalement mis sur Fitnesse.
J’en retiens que le fait d’écrire ces tests de hauts niveaux en collaboration avec la MOA permet de structurer la phase de spécification, et de lever toute ambiguïté et interprétation.
De plus, cela structure la manière de coder tout comme le fait le TDD à un niveau plus bas.
Les spécifications sont faites sous formes de scénarii au formalisme : Given … when … then …
Je vous recrache le schéma présenté sur les tests qui permet de situer les différentes catégories :

Je trouve qu’il est pas mal.
L’outil présenté est bien évidemment Fitnesse (utilisé avec SLIM) qui est pour un eux un premier bon pas vers les spécifications exécutables. Cependant, l’aspect peu sexy du wiki peut être un frein à l’acceptation par la MOA selon eux.
Parmi les problèmes soulevés il y a également le découplage du versionning avec le versionning de l’application (deux workflow différents, un wiki, l’autre basé sur le SCM), cependant il parait que la communauté Fitnesse y travaille. En discutant avec les gens de Pyxis, nous avons constaté que le problème était similaire sur GreenPepper qui se base sur la gestion des versions par Confluence.
Enfin, deux pistes à suivre : Jbehave2 (plutôt un DSL pour écrire du test à ce que j’ai compris) et Twist, poussé par Thoughwork, qui propose une solution basée sur Eclipse RCP pour écrire et avoir une aide syntaxique à la volée des tests fonctionnels (payant cependant). A creuser…

Ceintures et brettelles, test d’une application Web puis, mon JavaScript est agile lui aussi.

Je regroupe en une seule ces deux présentations car la deuxième est la suite de la première.
Arnaud Bailly, nous détaillait la chronologie des méthodes de tests utilisés pour tester une application RIA, avant de s’arrêter sur la méthode qu’ils avaient retenu.
Tous d’abord, il nous présente le duo Selenium/WebDriver. C’est sympa, les écrans défilent, c’est facile, on peut l’enregistrer avec un mode record/play. Mais au final, c’est trop lent avec prêt de 30 secondes pour lancer 3 tests et surtout c’est très dure à lire (donc à maintenir) et très peu souple. Dès que l’on bouge un peu à la page, tout s’effondre et il faut retravailler les expressions Xpath d’accès au élément HTML.
Ils ont essayé d’améliorer la chose en créant une surcouche pour décorréler la partie métier de la partie quincaillerie de manipulation des pages. Cependant, pour lui les problèmes demeurent et surtout la lenteur d’exécutions des tests. Sur un projet 500 tests peuvent mettre une nuit entière à s’exécuter. Dans ce contexte il se pose la valeur ajoutée par ceux-ci.
La solution qu’il a choisie est de tester unitairement la partie cliente tout comme il le fait pour la partie serveur. Ce qu’il cherche à tester c’est du JavaScript fait avec une bonne dose de JQuery. Pour cela il a démontré comme se créer un DSL en JavaScript (en utilisant massivement les prototypes), afin de rendre les tests facile et très expressifs. Pour finir il a intégré le tout avec HTMLUnit et Maven.
C’est assez sexy, mais je crains que le coût d’écriture du DSL soit trop élevé. De plus, qu’est ce qui prouve que le DSL n’est pas buggé. Je suis mitigé. Sinon il parait que Google a lancé un projet similaire multi-navigateurs, je vais chercher (c’est ici ).

Rétrospectives, la clef de l’amélioration continu.

Une présentation assez rapide sur laquelle j’ai pris peu de note.
Cependant, elle m’a fait pointer l’intérêt crucial qu’apportait les rétrospectives d’itérations et de projets ainsi qu’également la complexité de garder du dynamisme autour de celles-ci. En fait au bout de quelques itérations elles peuvent devenir routinière et il devient alors intéressant de varier les approches et les exercices. A ce titre, j’ai bien aimé le jeu de carte proposé par François Bachmann et Jacques ? qui ont synthétisé dans quelques cartes assez sympas le livre « agile retrospective ». Je vous conseille d’aller voir sur leur site www.alchimiste-agile.com
En vrac les infos que j’ai noté :
Pour les rétrospective de sprint, prendre 30’ par semaine d’itération, avoir un groupe réduit (équipe + chef de projet).
Pour les rétro de projets, avoir une équipe la plus ouverte possible (inviter le management, la production voir même les commerciaux). Préparer des débriefs individuels avant et essayer de sortir la rétrospective du lieu de travail habituel (terrain neutre).
Une idée pour collecter de l’information :
Placer une pile de post-it et écrire en vrac les idées des participants, regrouper en grosse catégories et identifier ainsi les principaux problèmes et réussites. Trouver une ou plusieurs actions pour l’itération suivante.
Pour la rétrospective de projets l’aspect chronologique est préféré, on refait la liste des faits selon un axe.
Il y a un groupe yahoo pour ceux qui ont des questions.

La suite dans un prochain post…

Tests Logiciel

View more presentations from nrichand. (tags: java tdd)