vendredi 23 mai 2014

Chapitre quatorze

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.

Lire la suite...

jeudi 25 novembre 2010

Grenoble est agile, partie 2

Après mes sessions décalées du matin, celles de l'après-midi orientées sur les nouvelles tendances de l'agilité.

Lire la suite...

dimanche 21 juin 2009

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.

Lire la suite...

mardi 03 février 2009

Pilotage par les tests d'acceptation

Après le TDD, voici l'ATDD.

Lire la suite...

dimanche 30 novembre 2008

Le retour des automates avec le BDD

La vérité sur le Behavior Driven Developement.

Lire la suite...

mardi 22 avril 2008

Exigences et tests, tests et exigences : un ruban de Möbius

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. L'article Tests and Requirements, Requirements and Tests: A Möbius strip, est signé de Grigori Melnik et de Robert C. Martin, le célèbre Uncle Bob.

La référence au ruban de Möbius illustre comment les 2 disciplines (exigences et tests) en deviennent une seule lorsque le formalisme augmente.

Dans l'article, les exemples sont en FIT qui propose une représentation tabulaire des tests exigences. FIT est bien adapté aux tests sur les données [1].

Je suis convaincu de cette hypothèse d'équivalence. L'écriture de tests d'acceptation est une technique de spécification, d'autant plus pertinente que les tests sont associés à des histoires d'utilisateur. Je l'applique maintenant sur tous les projets auxquels je participe, mais en utilisant le formalisme BDD plutôt que FIT. J'en ai déjà parlé ici et .

Notes

[1] je vois dans le dernier exemple que FIT permet aussi de spécifier des scénarios d'accès concurrents à une ressource, il va falloir que j'approfondisse l'utilisation du temps dans FIT

lundi 10 mars 2008

Tests d'acceptation orientés comportement

Voire même Behaviour Driven Development...

Lire la suite...

mercredi 23 mai 2007

Formaliser les critères d'acceptation

...ou comment rendre inutile la rédaction de spécifications détaillées.

Lire la suite...