Le Behavior Driven Development

La méthode agile qui teste son produit par le comportement de l’utilisateur.

BDD-Behavior-Driven-Development-Agilaction

Descriptif :

Le BDD ou Behavior Driven Development est une méthode agile conçue par Dan North en 2003. Elle intervient en réponse à une autre méthode qui est le TDD : Test Driven Development. Cette dernière est comme son nom l’indique une technique de développement qui consiste à réaliser les tests avant même de commencer à coder. C’est le concept « Test First », pour en savoir plus pour le TDD voir ici .

Si la méthode TDD peut être parfaitement maitrisée par l’équipe de développement, ce n’est pas le cas pour les autres parties prenantes du projet, notamment le Product Owner. Or celui ci est responsable de la qualité de son produit, il paraît donc essentiel qu’un PO puisse lui aussi utiliser une technique permettant de tester ses fameuses Users Stories.

C’est là qu’intervient le BDD. En effet il est le point de rencontre entre le PO, les développeurs, les testeurs mais aussi tous les autres corps de métier liés au projet. Grâce à un langage naturel et intuitif, les tests fonctionnels peuvent s’écrire de façon simple et deviennent donc accessibles à tous les intervenants « non-techniques » du projet. Le BDD va permettre de piloter la façon de développer par le besoin utilisateur.

En résumé, avec le TDD on teste le code directement alors que le BDD va tester les différents scénarios d’utilisation directe de l’interface.

La pratique : les scénarios fonctionnels :

En pratique c’est ce qu’on appelle les scénarios fonctionnels. Pourquoi scénario ? Car il va falloir anticiper tous les cas possibles de scénario de l’utilisateur lors de son utilisation d’une fonctionnalité. Il va falloir rédiger autant de scénarios qu’il faut afin de couvrir toutes les possibilités.

Par exemple, si le but est de tester une fonctionnalité de connexion, nous auront 6 scénarios possibles :

  • Le cas où l’utilisateur est sur la page de connexion rentre le bon login, le bon mot de passe et qu’il valide : il arrive à se connecter et accède à l’interface.
  • Le cas où l’utilisateur est sur la page de connexion rentre le bon login, le mauvais mot de passe et qu’il valide : un message d’erreur doit apparaître avec le texte suivant « Mauvais mot de passe »
  • Le cas où l’utilisateur est sur la page de connexion rentre le mauvais login, le bon mot de passe et qu’il valide : un message d’erreur doit apparaître avec le texte suivant « Nom d’utilisateur inconnu »
  • Le cas où l’utilisateur est sur la page de connexion rentre son login, ne rentre pas de mot de passe et qu’il valide : un message d’erreur doit apparaître avec le texte suivant « Veuillez renseignez votre mot de passe »
  • Le cas où l’utilisateur est sur la page de connexion ne rentre pas son login, rentre son mot de passe et qu’il valide : un message d’erreur doit apparaître avec le texte suivant « Veuillez renseignez le nom d’utilisateur»
  • Le cas où l’utilisateur est sur la page de connexion ne rentre ni son login, ni son mot de passe et qu’il valide : un message d’erreur doit apparaître avec le texte suivant « Veuillez renseignez vos identifiants de connexion»

Dans le principe, les scénarios sont assez simples à réaliser, mais le tout est de savoir anticiper chacun d’entre eux, il faut veiller à couvrir le maximum de possibilités. Ce processus peut paraître long voir rébarbatif car couvrir tous les cas de l’utilisation d’une fonctionnalité peut représenter une infinité de scénario. Pour pouvoir s’en sortir il faut veiller à tester une fonctionnalité et seulement une seule. Par exemple si une fonctionnalité d’envoi de message nécessite d’être connecté, on écrira que les scénarios concernant l’envoi de message en considérant que l’utilisateur est déjà connecté.

Le langage : Gherkin

En première partie nous parlions d’un langage « naturel » de rédaction de ces scénarios. C’est le langage Gherkin. En effet il est assez intuitif c’est ce qui lui permet d’être assimilé rapidement et maitrisé par les  « non-techniques ».

C’est très simple : chaque scénario bénéficie de la syntaxe suivante :

Fonctionnalité : Descriptif de la valeur métier de cette fonctionnalité (cette partie du BDD ne sera pas testée)

« Étant donné que …

Lorsque …

Et que …

Alors … »

Le « Étant donné que » définira le contexte, le « Lorsque » détermine l’action ou l’évènement, le « et » peut compléter l’action (facultatif), le « alors » lui permet de vérifier ce qui est attendu après cette action. Précisons que ce sont les termes communs traduits et utilisés en Français mais pour cette méthode initialement les termes sont : « Given, When, Then« . 

Reprenons notre exemple de connexion, un des scénario pourrait être le suivant :

« Étant donné que je suis déjà inscrit sur le site,

Lorsque je rentre mon login et mon mot de passe,

Et que je clique sur valider,

Alors j’accède à mon espace personnel. »

Une fois le test réalisé, c’est aux développeurs de l’implémenter.

Sources : Dan North, Poum, Wikipédia, Coding In, Thiga

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *