Tdd

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.

Après le TDD, voici l’ATDD.

Trouvé via le blog de Karl, un article publié dans le très sérieux magazine IEEE Software qui fait l’hypothèse d’une équivalence entre les tests et les exigences.

Un test, c’est une expérimentation menée pour révéler des informations, ou en réponse à une question précise sur un logiciel ou un système. Dans le cadre d’une approche agile basée sur les histoires d’utilisateur (user stories), un test d’acceptation est un test qui permet au client (ou au Product Owner) de dire s’il accepte, en fin d’itération, une histoire d’utilisateur développée par l’équipe. Un test est accroché à une story, qui en possède généralement plusieurs. Pour décrire les tests d’acceptation, ma préférence va à une technique orientée comportement, le BDD.

Des spécifications exécutables écrites par le métier ! Hier soir, j’ai fait une web conférence avec François Beauregard, qui m’a présenté GreenPepper. L’idée est assez géniale : permettre aux spécialistes du métier d’écrire les tests associés aux histoires d’utilisateur dans un langage simple et faire en sorte que ces tests soient exécutables. Tout cela dans un environnement collaboratif basé sur un wiki[1] et pouvant être intégré à Jira et Eclipse. Les tests d’acceptation sont décrits avec des exemples, de façon analogue à ce que j’ai présenté dans ce billet. Le langage de GreenPepper est basé sur 3 constructions : do with pour la séquence d’actions, list of pour les ensembles et rule pour définir des règles entre les données en entrée et les données en sortie.

Un des gaspillages les plus spectaculaires dans le développement de logiciel est l’écriture de spécifications détaillées suivie de la rédaction d’un cahier de recette, plus ou moins à partir de ces spécifications. Plutôt moins parce qu’en général le cahier de recette est écrit à la fin, à un moment où les specs, écrites au début, ne sont plus à jour depuis longtemps.

Aujourd’hui j’ai défini des tests d’acceptation [1] pour des histoires d’utilisateur[2]. C’est mon boulot de directeur de produit[3] de préciser les critères qui permettront de s’assurer qu’une histoire est complète. C’est un exercice indispensable si on veut automatiser les tests d’acceptation. Si on n’automatise pas cela reste tout de même très important. Par exemple pour l’histoire “En tant que participant à un projet, je démarre une tâche du plan”, des critères de test que j’ai identifiés sont :

Je viens de lire les prévisions de Fred Cavazza sur le Web2.0 et les anticipations de Louis Naugès sur la bureautique2.0. Et si on faisait l’exercice pour le domaine des méthodes Agiles ?

Cette année, mes questions étaient ouvertes et la correction n’est pas facile. Il me faut lire entre 5 et 8 pages bien remplies par étudiant. Avec une trentaine d’étudiants, ça doit faire dans les 200 pages. Le plus souvent c’est plein de fautes d’orthographe. Dans la seule copie où je croyais ne pas en trouver, il est écrit à 2 lignes de la fin : “il … est choisit…”. Dommage, mais cela ne me gêne pas. Plus embêtant pour ma lecture, c’est que ce n’est pas toujours bien présenté ni bien écrit. Mais j’y trouve quand même du plaisir à voir que ce que j’ai présenté a été bien compris. Et puis je découvre toujours quelques perles amusantes.

Benoît a fait des investigations sur un projet que j’ai initié aux méthodes agiles. Un des constats qu’il fait est que de nombreuses user stories ne sont pas finies en une itération. Quelques unes durent même 5 itérations ! Ce problème est souvent dû à l’accostage développeurs-testeurs. Quand le testeur reçoit le logiciel à tester en toute fin d’itération, au mieux il découvre des erreurs qui ne sont pas corrigées dans l’itération, au pire il diffère ses tests à l’itération suivante. Cela n’est pas spécifique à cette équipe, comme le montrent des billets récents de Kane Mar et Ed Gibbs. C’est un dysfonctionnement sérieux auquel il faut s’attaquer.

Dans le numéro de juin de Software Test & Performance : un article (et la couverture) sur l’utilisation de Scrum pour les activités de test et surtout une excellente présentation des différents tests dans un cadre agile par Dean Leffingwell “Take the Agile Path to true Balance”. Il présente bien la problématique des tests dans un développement agile. Il suggère notamment qu’une itération de “durcissement” est bien souvent nécessaire à la fin d’une release, après les itérations “normales”. C’est une évidence pour les projets débutant dans l’agilité auxquels je participe : tant qu’on n’a pas complètement automatisé, tous les tests concernant une user story ne peuvent pas être passés dans l’itération où elle est réalisée. Cela nécessite déjà un gros changement dans les habitudes pour y commencer les tests fonctionnels.