Qu’est-ce que le Behavior Driven Development (BDD) ?

Points clés à retenir

• Le développement piloté par le comportement (BDD) est un processus de développement qui privilégie la collaboration entre les équipes techniques et non techniques.
• Avec le BDD, les cas de test sont rédigés en langage naturel et prennent en compte vos objectifs commerciaux ainsi que la fonctionnalité utilisateur. LoadView peut être un outil utile dans la boîte à outils du développement BDD car il offre une plateforme accessible avec des rapports que les utilisateurs techniques et non techniques peuvent comprendre rapidement.

Les développeurs jouent un rôle essentiel dans le lancement d’un site web, d’une application ou d’une API, mais ils ne sont pas les seuls impliqués. De tous les profils, du chef de produit à l’analyste commercial, chacun a un enjeu dans le développement et le maintien d’une forte présence web. Les différentes équipes ont des forces, des connaissances et des compétences différentes. Un collaborateur marketing n’est peut-être pas aussi expert en développement qu’un ingénieur logiciel, alors comment s’assurer que tous les membres de votre équipe soient sur la même longueur d’onde ? C’est là que le développement piloté par le comportement intervient.

Le développement piloté par le comportement (BDD) est un processus de développement qui privilégie la collaboration entre les équipes pour vous aider à construire un site, une application ou une API d’une manière qui profite à tous les acteurs impliqués. En mettant en œuvre un processus BDD, une équipe peut former un langage cohérent et accessible, compréhensible aussi bien par les programmeurs que par les non-programmeurs. Les cas de test sont rédigés en langage naturel et prennent en compte vos objectifs commerciaux, la fonctionnalité utilisateur et les résultats attendus.

Chez LoadView, nous sommes engagés à aider votre entreprise à prospérer dans chaque département, alors apprenons un peu plus sur le BDD et voyons comment il peut aider votre équipe à travailler ensemble.

Une brève histoire du BDD

En 2006, le développeur logiciel Dan North a constaté qu’il existait des lacunes dans la communication entre les départements au sein de l’entreprise où il travaillait. Il semblait que des équipes moins techniques comme les chefs de produit et les responsables marketing étaient tenues à l’écart des développements clés, tandis que les développeurs logiciels n’étaient pas informés des principales préoccupations des utilisateurs lors de leur navigation sur le site.

À partir de ces lacunes, North a pu développer un nouveau système. Dérivé du développement piloté par les tests (TDD), le BDD se concentre sur le comportement humain réel, un anglais simple, et un modèle logique clair. Ce processus prend en compte les préoccupations commerciales ainsi que les exigences techniques. Il a transformé des modèles auparavant complexes en un nouveau langage spécifique au domaine (DSL) qui se rapproche autant que possible de l’anglais courant et conversationnel.

Ce DSL est devenu le facteur déterminant du BDD, le modèle given/when/then.

Le modèle Given/When/Then

Dans le modèle given/when/then, chaque partie définit une étape d’une transaction ou d’une interaction en ligne.

• Given : Fait référence à la condition de départ avant que l’interface soit utilisée par un utilisateur.
• When : Fait référence à l’action effectuée par l’utilisateur qui déclenche l’interaction. Un clic, une transaction ou un mot-clé saisi dans une barre de recherche sont autant d’exemples d’actions “when”.
• Then : Fait référence au résultat attendu après que l’action s’est produite.

Voici un exemple de scénario given/when/then :

• Given que le Compte 1 a 0 $ et le Compte 2 a 100 $
• When le Compte 2 transfère 50 $ au Compte 1
• Then le Compte 1 a 50 $ et le Compte 2 a 50 $

Ce modèle en anglais courant facilite le partage des situations de programmation entre les départements. Le DSL peut être compris par n’importe qui, qu’il soit développeur ou non. Lors de l’exécution de tests fonctionnels et non fonctionnels, utiliser un modèle given/when/then aide à réduire les lacunes de communication.

C’est la fonction essentielle du BDD : utiliser l’anglais simple pour développer un DSL compris de tous. Il y a de nombreux avantages à utiliser le BDD pour développer votre site web, application ou API, et développer un DSL n’en est qu’un parmi d’autres.

Avantages du développement avec le BDD

Le BDD offre de solides avantages si vous travaillez avec une équipe diversifiée. Son accent mis sur la fonctionnalité, une communication claire et l’expérience utilisateur en fait un processus utile pour les entreprises en ligne et les services numériques avec des parties prenantes non techniques. Le BDD est :

• Efficace : Avoir une fonctionnalité clairement définie et un langage accepté par toutes les parties prenantes est un avantage clé du BDD. Avec tout le monde sur la même longueur d’onde, le développement tant du point de vue commercial que technique peut prendre forme en temps voulu. Avec toutes les équipes travaillant ensemble, il y a moins besoin de revenir en arrière et de retravailler les éléments non fonctionnels.
• Rentable : Le BDD est non seulement bénéfique pour vos valeurs commerciales, mais il peut aussi aider à réduire le gaspillage dans le processus de développement. Un langage bien défini facilite la création et la validation des cas de test. Ces cas peuvent être automatisés avec une compréhension claire de ce qui est attendu et quand. Automatiser ces tests peut aider à réduire le coût des tests applicatifs.
• Haute qualité : Avec l’aide d’équipes non techniques, les concepteurs et programmeurs reçoivent un retour sur l’expérience utilisateur plus tôt dans le processus. Cela encourage les équipes à penser et développer du point de vue de l’utilisateur. Développer du point de vue de l’utilisateur aide aussi les développeurs à écrire un code stable, scalable et testable. Cela aide à prévenir les problèmes utilisateurs avant qu’ils ne surviennent.

Inconvénients du développement avec le BDD

Bien que le BDD puisse être un excellent processus dans certaines situations, il n’est pas universel. Le BDD a été créé pour résoudre des problèmes et combler des lacunes dans l’approche TDD. Si les programmeurs sont moins expérimentés, peu familiers avec le processus de développement TDD ou fortement liés à des outils et langages de programmation spécifiques, mettre en œuvre le BDD efficacement peut demander un effort supplémentaire.

Le BDD repose sur une bonne communication. Cela signifie avoir une équipe de développeurs dédiés, de propriétaires de produit, d’équipes QA et de parties prenantes commerciales capables de communiquer efficacement avec les clients, les utilisateurs et les représentants d’autres équipes. Cela peut créer une surcharge supplémentaire si l’équipe ne dispose pas d’un processus clair en place.

Outils BDD populaires

Le BDD s’est avéré populaire dans la communauté des développeurs. De nombreuses équipes ont adopté cette approche et utilisent une variété d’outils pour la soutenir. Voici quelques outils BDD populaires.

• Cucumber : Cucumber est une plateforme open-source populaire pour la collaboration BDD. Elle aide les équipes à construire des fonctionnalités en texte clair et fournit une cohésion grâce à un DSL facile à partager avec toute l’équipe. Il implémente la syntaxe Gherkin.
• Lettuce : Lettuce est construit sur Cucumber et fonctionne bien pour les applications basées sur Python.
• SpecFlow : SpecFlow est une autre plateforme BDD open-source qui utilise la syntaxe Gherkin. Elle est conçue pour la plateforme .NET.

Développement piloté par le comportement avec LoadView

Le BDD est un processus, et les tests de performance peuvent en être une partie importante. Au fur et à mesure que les équipes connectent les workflows BDD avec les pipelines CI/CD et les tests automatisés, les attentes en matière de performance peuvent aussi être définies plus tôt dans le cycle de développement. Par exemple, les équipes peuvent créer des attentes partagées autour de la vitesse de connexion, de la fiabilité du paiement, des temps de réponse API, ou du comportement d’une application sous une charge utilisateur attendue.

LoadView exécute des tests de performance qui simulent le comportement réel des utilisateurs avec des scripts simples pour que vous puissiez soutenir votre processus BDD avec des données de performance réalistes. Pouvoir tester comment votre site web fonctionne sous différentes charges utilisateurs, emplacements des utilisateurs et niveaux de stress peut aider chaque département impliqué dans le développement piloté par le comportement à comprendre si l’application répond aux attentes techniques et commerciales.

LoadView est une plateforme accessible qui ne nécessite aucune connaissance préalable en codage, ce qui en fait un excellent choix pour une équipe travaillant à travers plusieurs départements techniques et non techniques. LoadView est conçu pour tester :

• Pages web
• Applications mobiles natives
• APIs

Essayez LoadView dès aujourd’hui

Le BDD est conçu pour mettre au centre le valeurs commerciales durant le processus de développement tout en gardant le résultat final utilisateur à l’esprit. LoadView peut vous aider à ajouter des tests de performance à ce processus avec des tests et des rapports plus faciles à comprendre pour les équipes techniques et non techniques. Essayez LoadView gratuitement ou planifiez une démo aujourd’hui pour voir comment vous pouvez intégrer les tests de performance dans le processus BDD de votre entreprise.