Rédigez vos tests d’acceptance à la sauce BDD

aq
photo credit: woodleywonderworks via photopin cc

En tant que product owner, vous êtes à l’aise dans l’écriture de vos user stories INVEST mais avez envie de pousser plus loin vos tests d’acceptance ? Adoptez les scénarios BDD !

Avantage n°1

Une excuse de plus pour rapprocher les développeurs, les product owners (PO) et les testeurs pour discuter de la User Story et la manière de la tester. Lorsqu’il construit sa User Story, le PO sollicite un ou plusieurs développeurs et testeurs. Il partage le besoin client et présente des exemples d’utilisation, les scénarios. C’est le moment pour challenger la user story et alimenter une discussion qui aura pour effet d’en élargir la perception, y compris celle du product owner.

Avantage n°2

Disposer d’un formalisme ultra simple qui permet de modéliser un comportement. Un scénario met en évidence la réponse que doit fournir le système face à un événement compte tenu d’un contexte initial. On pourra se référer à l’article d’Arnaud Loyer pour plus de détails sur le sujet. Une User Story peut faire intervenir un ou plusieurs scénarios dont la structure respectera le langage Gherkin.

Pour la user story suivante:

En tant que client de la banque
Je souhaite pouvoir créditer mon compte
Afin d’augmenter mon solde

On pourra trouver le scénario:

Etant donné que je dispose de 20 euros sur mon compte bancaire
Quand je crédite mon compte de 10 euros
Alors mon solde devrait être de 30 euros

Super bonus

Rendre les spécifications exécutables / testables automatiquement, ce qui conduit par la même occasion à créer la documentation vivante de votre application (toujours à jour). Pour l’outillage, on pourra aller fouiller du coté de Cucumber ou Specflow par exemple.

Ça a l’air simple !

Oui, et ça doit le rester, sinon l’équipe implémentera des scénarios exécutables difficiles à maintenir, ce qui conduira tout simplement à l’abandon de la pratique.
A lire sur le blog de Blog de Jean-François Lépine: Les principales causes d’échec du BDD
Il y a vraiment des précautions à prendre, la première est de garder un bon niveau d’abstraction et d’éviter de rentrer dans des détails d’implémentations. Il faut faire en sorte que les scénarios ne soient pas impactés lorsque le code est retravaillé. Ces scénarios ne doivent illustrer que des exemples et ne font pas office de test de non régression (TNR). Les TNR, indispensables, interviennent à un autre niveau de la chaîne de test.

Comment bien démarrer ?

La voie royale passe la formation et les ateliers. On peut aussi s’orienter vers l’excellent livre de Gojko Adzic « Specification By Example » dans lequel on trouve de très bons conseils sur la rédaction et l’implémentation des scénarios.

Le blog de Liz Keogh est très complet sur le sujet. Elle propose un slideshare qui illustre bien les avantages du BDD.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s