bdd

Le chapitre 14 de mon livre Scrum s’appelle “La story et ses tests d’acceptation”. Dans cette nouvelle édition, le titre a légèrement changé, car le chapitre inclut désormais la présentation des stories.

Il a été presque entièrement réécrit, notamment pour incorporer des nouveaux outils du Product Owner, comme ceux que j’ai présentés le mois dernier lors du ScrumDay 2014.

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.

Une des réalisations dont je me souviens de ma vie de développeur, c’est l’écriture d’un générateur de code à partir de tables décrivant un automate. Plutôt un moteur d’automate, capable de lancer les actions élémentaires d’une transition suite à la réception d’un événement dans un état. A l’époque je travaillais à Telic-Alcatel dans le monde des autocommutateurs (PABX). Le comportement du poste téléphonique était décrit avec des automates à états finis. On disait simplement automate.

Attention, c’était de gros automates.

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.