Les tests, un moyen d'améliorer la communication

Les tests d'acceptation (au sens agile) remplacent une spécification fonctionnelle détaillée. Avec un bénéfice essentiel : la communication est facilitée entre le métier et le développement.

Vendredi dernier, à la conférence agile de Toulouse, il y avait un retour d'expérience sur les tests dans un projet agile. Il y a été question essentiellement des tests d'acceptation. Et de pilotage par les tests d'acceptation (ATDD).

D'abord une précision : le terme acceptation ne doit pas être compris comme dans acceptance test ou UAT, phase à la fin d'un projet pour obtenir la signature du client, comme confirmation qu'il accepte le produit livré. Ici, il s'agit de l'acceptation d'une user story pendant le sprint où elle est développée.

Dans son rôle de responsable des tests, Arielle, la présentatrice du retour d'expérience, nous a raconté qu'elle écrit les cas de test, à partir des user stories. Ces cas de test, attachés à une story et décrits avec un formalisme de type BDD, sont fournis aux développeurs avant que le développement ne soit commencé sur cette story.

Un des points positifs mis en évidence est l'amélioration de la communication. Les membres de l'équipe sont demandeurs de ces cas de test. Ils s'en servent dans les discussions avec le Product Owner et les testeurs. Ils les complètent si c'est nécessaire. Le référentiel de test est stocké dans un wiki, complété progressivement et toujours mis à jour.

Cela montre que l'ensemble des user stories avec leurs cas de tests constitue l'équivalent d'une spécification (fonctionnelle) détaillée. C'est que Grigori Melnik et de Robert C. Martin ont mis en évidence : l'hypothèse d'une équivalence entre tests et exigences.

Cela montre aussi que cette façon de faire est un moyen d'obtenir une meilleure compréhension entre le métier et le développement, ce qui est un apport absolument fondamental.

Dans façon de faire j'inclus bien plus que du test. En fait je pense que le mot test est trompeur. Au lieu de test d'acceptation, spécification par l'exemple serait probablement plus approprié.

Et si on automatise les cas de test, cela devient de la spécification exécutable.

Commentaires

1. Le mardi 23 juin 2009, 16:35 par ehsavoie

Le livre de Gojko Adzic: Bridging the communication gap (http://www.acceptancetesting.info/t...) reprend l'ensemble de ces concepts. Et nous (Rémy, Hervé et moi-même ) avons présenté le sujet lors des derniers XPDays (http://www.ehsavoie.com/2009/05/xpd...). L'article (en anglais) d'Elisabeth Keogh (à l'origine de JBehave2 et amie de Dan North) montre comment l'ATDD s'intègre dans une démarche Lean et comment les spécifications exécutables 'tirent' les développements (http://www.infoq.com/news/2009/05/p...)