bdd

Chapitre quatorze

Chapitre quatorze

Avec tout plein de nouveautés

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. Le résumé en fin du chapitre Plutôt court… Le test n’est pas une activité réservée à la fin des développements.
Grenoble est agile, partie 2

Grenoble est agile, partie 2

Les nouvelles tendances de l'agilité

Après mes sessions décalées du matin, celles de l’après-midi orientées sur les nouvelles tendances de l’agilité. Keynote : Les nouvelles tendances de l’agilité Aslak Hellesøy est un norvégien qui parle bien le français. Il a présenté sa keynote en début d’après-midi, dans un amphi bondé (450 personnes). Comme j’ai été un des derniers à prendre le dessert (il y a eu un goulet d’étranglement pour le repas), je suis arrivé dans l’amphi au moment où Aslak commençait et j’ai dû rester debout dans le fond.

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

Au lieu de test d'acceptation, spécification par l'exemple serait probablement plus approprié

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é.
Pilotage par les tests d'acceptation

Pilotage par les tests d'acceptation

Méta-modèle

Après le TDD, voici l’ATDD. Dans l’épisode précédent, nous avions vu qu’une story était un élément du backlog de produit. Un principe, dans toutes les méthodes agiles, est qu’une story soit réalisée en une itération. Mais comment savoir si elle est vraiment finie à la fin de l’itération ? C’est la responsabilité du product owner d’accepter ou pas une story. Pour cela, le moins qu’il puisse faire est de définir ses conditions de satisfaction.

Le retour des automates avec le BDD

La vérité sur le Behavior Driven Developement

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.

Tests d'acceptation orientés comportement

Voire même Behaviour Driven Development

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.

Formaliser les critères d'acceptation

…ou comment rendre inutile la rédaction de spécifications détaillées. 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.