Deutsch English Swedish French
CONTACTEZ-NOUS
CONTACTEZ-NOUS
Deutsch English Swedish

Qualité logicielle et IA

Test logiciel

Assurance qualité pour SAP

Cybersécurité

Banque & Finance

QESTIT Cybersecurity

QESTIT Academy

QESTIT Systems

Blog

Études de cas

Webinars

Livres blancs

Actualités

Qui sommes-nous

Nos partenaires

Nos références
Solutions

Travailler chez QESTIT

Offres d'emploi
CONTACTEZ-NOUS
move-left Back
🌍 All Regions
Quality Assurance Engineering

BDD : des bonnes pratiques à ses dérives

Le BDD (Behaviour Driven Development, ou développement piloté par le comportement) est une pratique popularisée par Dan North en 2003, dérivée du TDD (Test Driven Development, ou développement piloté par les tests), dont elle est complémentaire.

Pourquoi utiliser le BDD ? Précisément pour remédier aux problèmes courants liés aux spécifications en mode Agile :

  • Absence d’explication formelle du contexte,
  • Des spécifications pouvant être interprétées différemment selon les profils ou les acteurs,
  • Des spécifications qui ne sont pas nécessairement à jour.

Le BDD est donc une pratique agile visant à synchroniser les différents acteurs développant une fonctionnalité avec ce qu’elle est censée faire. L’objectif du BDD est de concevoir des tests d’acceptation illustrant le comportement de la fonctionnalité, à l’aide de méthodes telles que les « 3 amigos » ou le « example mapping ». L’approche BDD se déroule généralement en trois étapes : découverte, formulation et automatisation.

La bonne application

Les acteurs sont alignés à l’aide d’exemples co-conçus qui illustrent le comportement de la fonctionnalité : il s’agit de la découverte des cas d’utilisation, souvent réalisée grâce à la réunion des « 3 amigos » (profils client, développeur et testeur), qui permet d’établir une compréhension commune du besoin et de rédiger des scénarios d’acceptation pour valider les critères d’acceptation.

Ces exemples sont formulés à l’aide d’un langage commun, Gherkin, facilement compréhensible par les différents profils des « 3 amigos ». Ce langage Gherkin est conçu pour rédiger des tests structurés en langage naturel, et a priori compréhensibles par tous. Les tests Gherkin s’écrivent à l’aide de quatre éléments de base : GIVEN / WHEN / THEN … AND (GIVEN un certain contexte, WHEN j’effectue une action, THEN j’obtiens un résultat 1 AND un résultat 2).

À partir de cette formulation structurée (et formatée) du comportement de la fonctionnalité, il est possible d’intégrer ces exemples dans un outil logiciel, tel que Cucumber par exemple, qui interprétera ce langage Gherkin pour exécuter des tests d’acceptation automatisés, adaptés à ces exemples. C’est l’étape de l’automatisation.

Ses dérives

Le BDD est désormais utilisé dans de nombreuses entreprises pour tester le comportement de certaines fonctionnalités en étroite collaboration avec les utilisateurs. Mais même si le BDD sert à parvenir à une compréhension commune des besoins, il subsiste un certain nombre de malentendus autour de cette pratique Agile, qui peuvent conduire à certains abus. Quels sont-ils ?

Le BDD est considéré uniquement comme une forme d'automatisation

  • Dans ce cas, on passe à côté de l'apport essentiel du BDD : la capacité pour chacun d'avoir la même compréhension de ce qui est attendu.

Les scénarios sont rédigés et conçus uniquement par le Product Owner ou le testeur.

  • Dans ce cas, des exemples existent bel et bien. Malheureusement, leur qualité est souvent insuffisante, car ils n’ont pas été examinés par des profils différents.

Absence de rédaction de scénarios d'acceptation

  • Il arrive parfois que des réunions de synchronisation soient organisées, mais qu’au final, aucun scénario n’en ressorte. Cela pose problème dans la mesure où une grande partie des informations est perdue parce qu’elle tombe dans l’oubli. Cela oblige également davantage de personnes à assister à ces réunions, ce qui nécessite un investissement plus important.

Des tests qui ne sont pas compréhensibles par tous les profils

  • Un test BDD doit être compris par tous les membres de l’équipe (et parfois au-delà). Rédiger des tests qui ne sont pas compris par tout le monde ne garantit pas que chacun comprenne la même chose. En général, cela ne permet pas non plus à l’entreprise de valider réellement ce qui va être développé.

Le BDD est créé au cours du sprint

  • « Au cours d’un sprint » ne signifie pas « pendant le développement ». Mais même lorsque le BDD est réalisé avant le développement, ce processus a un impact sur l’équipe, qui a dû s’engager à livrer un cas d’utilisation (US) qu’elle n’avait peut-être pas entièrement compris.

Utilisation de Gherkin comme BDD

  • Gherkin est un langage. Le BDD peut prendre d’autres formes… tout comme il est possible d’exécuter en Gherkin des tests qui ne relèvent pas du BDD (par exemple : l’outil Karaté propose des tests en Gherkin qui ne peuvent pas être interprétés par des profils fonctionnels).

Avant le sprint, la pratique BDD consiste, par le biais de la découverte, à valider une compréhension commune de l’exigence par tous les acteurs impliqués. Cette compréhension est formulée à travers des exemples, des critères d’acceptation et des scénarios d’acceptation, qui sont ensuite implémentés dans un outil de conception et d’exécution de tests automatisés.


La mise en œuvre des différentes étapes de cette approche permettra de lutter contre la dérive du BDD et, surtout, contre la confusion qui règne actuellement autour des différents termes liés au concept de BDD.

Tags

Quality Assurance Engineering All Industries All Business Units