Appliquer les principes et les bonnes pratiques du développement piloté par le comportement (BDD)

Qu’est-ce que le développement guidé par le comportement (BDD) ?

Le comportement attendu d’un utilisateur lorsqu’il interagit avec une application est documenté et conçu dans l’application à l’aide de la méthodologie de développement logiciel agile connue sous le nom de développement axé sur le comportement (BDD). BDD permet d’éviter le gonflement, le code excessif, les fonctionnalités inutiles et le manque de concentration en conseillant aux développeurs de se concentrer uniquement sur les comportements souhaités d’une application ou d’un programme. Cette approche combine les meilleurs aspects du développement piloté par les tests d’acceptation (ATDD) et du développement piloté par les tests (TDD).

Un projet typique de développement axé sur le comportement commence par une conversation entre les responsables, les clients et les développeurs afin de comprendre comment le produit est censé fonctionner. Lorsque chaque test de comportement est réussi, le produit satisfait à toutes les spécifications et est prêt à être livré au client. Les objectifs des développeurs sont alors fixés en fonction des attentes en matière de comportement pour le produit.

La raison d’être du développement guidé par le comportement

Dan North, consultant en technologie et en organisation basé à Londres, a développé le BDD il y a plus de dix ans pour éliminer les malentendus entre les développeurs, les testeurs et les professionnels de l’entreprise. Malgré des débuts modestes en tant que simple modification du développement piloté par les tests, BDD est aujourd’hui une méthodologie de développement logiciel à part entière.

Les deux principales composantes de l’approche BDD sont souvent séparées :

• Dans la première section, des exemples sont rédigés dans un langage commun pour illustrer des comportements ou la manière dont les utilisateurs interagissent avec le produit.

• La deuxième étape consiste à utiliser ces exemples comme base pour les tests automatisés. Il permet aux développeurs de tester la fonctionnalité de l’utilisateur et garantit que le système global fonctionne comme prévu par l’entreprise pendant toute la durée de vie du projet.

Le développement guidé par le comportement a été créé pour combler le fossé et simplifier la collaboration et la communication entre les services. En conséquence, les projets de développement de logiciels sont gérés et livrés avec plus de succès. Elle garantit que les projets se concentrent sur les besoins réels de l’entreprise tout en répondant aux besoins des utilisateurs.

Le développement piloté par le comportement dans le cadre du développement agile

Les équipes utilisent la méthodologie de développement agile itérative pour le développement de logiciels. Les équipes transversales et auto-organisées adaptent fréquemment les projets en analysant l’environnement et les besoins des utilisateurs. Voici comment le développement guidé par le comportement joue son rôle dans le développement agile :

• Se concentrer sur le comportement et les résultats souhaités

Pour assurer une qualité intégrée, le développement guidé par le comportement (BDD) définit (et éventuellement automatise) des tests avant ou dans le cadre de la spécification du comportement du système.

• Collaboration entre les parties prenantes

Une compréhension commune des exigences entre l’entreprise et les équipes agiles est créée grâce au BDD, un processus collaboratif. Ses objectifs sont d’améliorer les flux, de réduire les reprises et d’orienter le développement.

• Rédiger des tests dans un format lisible par l’homme

BDD encourage une communication fréquente entre les trois principales parties prenantes. Contrairement aux tests traditionnels utilisant le code, où l’équipe d’assurance qualité peut ou non communiquer régulièrement avec les autres parties prenantes, cette méthode permet de développer les tests dès le début.

• Utilisation d’un format “Given-When-Then” pour les scénarios de test

La technique Given-When-Then est un guide de style pour l’écriture des cas de test d’acceptation pour une histoire d’utilisateur. t, créateurs de la technique BDD, ont développé cette approche d’écriture de cas de test pour le développement guidé par le comportement.

La nécessité d’un cadre de test BDD

Les processus agiles et DevOps visent avant tout à fabriquer des produits dans les plus brefs délais. D’autre part, les entreprises se méfient de la diffusion de produits qui ne répondent pas entièrement aux besoins des clients ou qui ne sont pas en phase avec les objectifs stratégiques de l’entreprise. C’est pourquoi,

• BDD renforce la méthodologie Agile en permettant à l’utilisateur final d’intervenir en continu pour valider le processus de développement et s’assurer que le “bon produit” est déployé.

• Il permet également une meilleure coordination entre les principaux acteurs du processus de développement de logiciels, à savoir l’équipe commerciale, l’équipe de développement et l’équipe d’ assurance qualité. Comme chaque équipe a un point de vue différent, ce qui peut conduire à des remaniements inutiles, l’approche BDD garantit que tout le monde reste sur la même longueur d’onde et place la nécessité du comportement souhaité au premier plan.

Où se situe BDD dans la pyramide de l’automatisation des tests ?

Les tests unitaires, les tests d’intégration, les tests d’interface utilisateur (UI) et bien d’autres font partie du développement piloté par les tests. Il existe de nombreuses méthodes pour créer et gérer ces tests, mais ces dernières années, les équipes de développement Agile ont privilégié l’idée d’une pyramide de tests, considérée comme l’une des plus efficaces. Voici les différents niveaux du test, de haut en bas :

1. Intégration de l’utilisateur ou test UT
2. Test d’intégration du système
3. Test d’unité
4. Test manuel

Il existe plusieurs niveaux dans la pyramide de l’automatisation des tests, et comme l’a expliqué M. John Ferguson Smart, “BDD peut être mis en œuvre partout où une règle métier est appliquée”. Un scénario BDD est un moyen d’exprimer des critères d’acceptation ou une règle de gestion. Un scénario BDD est un moyen d’exprimer des critères d’acceptation ou une règle de gestion. Un exemple de règle de gestion sous une forme lisible par l’entreprise et dont vous convenez avec votre client ou votre partie prenante. Lorsque vous décidez d’automatiser certaines règles, celles-ci sont testées à ce que l’on appelle le niveau de test le plus bas, qui peut être n’importe quel niveau de la pyramide des tests d’automatisation”.

Étapes nécessaires à la mise en œuvre d’une stratégie de développement axée sur le comportement

Un processus itératif en cinq étapes, comprenant la définition des comportements, l’écriture des tests, l’automatisation des tests, l’exécution des tests et la répétition, est nécessaire pour mettre en œuvre le BDD. Ces exemples documentés deviennent des atouts au fil du temps, ce qui permet à votre équipe de modifier rapidement le système en toute confiance. Le code reflète la documentation, qui reflète la compréhension partagée par tous de l’espace du problème dans cette compréhension partagée et en constante évolution.

Étape 1 : Définir le comportement

L’objectif réel est d’obtenir un logiciel utile et opérationnel pour l’entreprise. Le moyen le plus rapide d’y parvenir est d’avoir des conversations avec toutes les personnes impliquées dans la conception et la livraison du logiciel.

À cette fin, la première étape consiste à prendre un changement de système en attente, connu sous le nom de “user story”, et à discuter d’exemples concrets de nouvelles fonctionnalités à étudier. Utilisez des outils de marketing par courrier électronique pour sonder vos utilisateurs et recueillir leurs suggestions avant de prendre des décisions.

Étape 2 : Écrire les tests

L’étape suivante consiste à automatiser la documentation de ces exemples. Vous pourrez alors voir s’il y a un accord. Une fois qu’un exemple valable a été identifié au cours des sessions de découverte, chaque exemple peut être formulé sous la forme d’une documentation structurée. Il permet à toutes les personnes impliquées de confirmer rapidement qu’elles ont une compréhension commune de ce qui doit être construit.

Étape 3 : Automatiser les tests

La troisième étape consiste à mettre en œuvre le comportement de chaque exemple documenté, en commençant par le test automatisé pour guider le développement du code. Une fois que l’équipe l’a créée, une spécification exécutable peut être utilisée pour guider le développement de la mise en œuvre. Sans le système, chaque exemple peut désormais être utilisé comme un test. Ce test n’est pas valable car le comportement décrit n’a pas encore été mis en œuvre.

Étape 4 : Exécuter les tests

Vous pouvez créer un ensemble de tests et exécuter les tests de votre projet dans l’ordre que vous souhaitez avec des éléments de test. Les tests BDD peuvent être inclus dans les éléments de test pour devenir une partie intégrante de l’exécution des tests de votre projet.

Étape 5 : Répéter

Vous pouvez exécuter les scénarios BDD pour vérifier le comportement de votre système après avoir défini vos scénarios et mis en pratique les définitions d’étapes. Idéalement, les scénarios peuvent être exécutés manuellement ou automatiquement à l’aide d’un cadre de test BDD.

Il est facile de comprendre le concept de développement guidé par le comportement lorsque nous prenons l’exemple suivant dans le modèle Given-When-Then :

Cet exemple représente un étudiant qui n’a pas terminé certains cours et qui souhaite demander une révision de son emploi du temps. Pour ce scénario, l’étudiant doit être connecté au site web. Le DONNÉ décrit la situation, tandis que le QUAND décrit l’action qui déclenche le scénario. Le résultat est ensuite décrit : le plan de formation personnalisé est consultable.

Ainsi, la technique du “Given-When-Then” permet aux personnes non techniques de décrire parfaitement ce qu’elles attendent du produit ou de la fonctionnalité.

Meilleure pratique pour la mise en œuvre de BDD

Voici quelques bonnes pratiques BDD que vous devriez suivre.

• Évitez les descriptions trop longues

Seuls un titre et une description logiques et concis doivent être utilisés pour chaque élément. Les longues descriptions des fonctionnalités sont souvent fastidieuses à lire et rebutent souvent les parties prenantes. En règle générale, une caractéristique doit être une brève phrase résumant sa portée et son contexte.

• Choisissez un format unique pour vos caractéristiques

Le choix des formats que vous utilisez pour écrire des fonctionnalités est une autre excellente caractéristique du développement axé sur le comportement. Tous les fichiers de caractéristiques doivent respecter le format que vous avez choisi. Par conséquent, toute personne découvrant le projet pourra facilement en comprendre les caractéristiques et le contexte.

• Faites en sorte que l’arrière-plan soit court

Dans la mesure du possible, utilisez un arrière-plan pour les étapes partagées de chaque scénario dans votre fichier de caractéristiques. L’arrière-plan élimine de nombreuses tâches répétitives et vous pouvez éviter les doublons dans les fichiers de caractéristiques en les utilisant correctement. Présentez brièvement vos antécédents, idéalement en quatre lignes maximum.

Avantages de l’application de BDD dans les tests de logiciels

Les tests d’acceptation constituent la première étape de la conception d’un logiciel BDD. Ils offrent une base de communication solide à l’équipe de développement et aux parties prenantes. Les principaux avantages offerts par BDD dans les tests de logiciels sont les suivants :

• Éliminer les déchets

Il est moins probable que les exigences et les critères d’acceptation soient mal compris car BDD vous permet de communiquer les exigences.

• Atteindre les objectifs de l’entreprise

Chaque développement peut être lié à des objectifs commerciaux spécifiques à l’aide de BDD.

• Suite de tests BDD

Lorsque votre équipe adopte le BDD, tout comme le TDD, elle acquiert de la confiance sous la forme d’une suite de tests.

• Se concentrer sur les besoins des utilisateurs

Les besoins des utilisateurs peuvent être satisfaits par le développement de logiciels grâce à la méthodologie BDD, ce qui rend les utilisateurs heureux, ce qui est bon pour les affaires.

• Facile à intégrer

Les codes BDD sont faciles à intégrer avec tous les serveurs de tests automatisés, comme cucumber. L’exécution des tests peut facilement fonctionner sur Jenkins, un serveur d’automatisation open-source supportant des centaines de plugins pour la construction, le déploiement et l’automatisation de n’importe quel projet.

• Améliorer la qualité du code

L’avantage le plus important du développement guidé par le comportement est l’amélioration de la qualité du code, ce qui réduit les risques du projet et les coûts variables tels que la maintenance.

• Aide à la génération de code

Dans le cadre du BDD, les interactions entre les utilisateurs et les développeurs sont utilisées pour générer du code. Cela signifie que les utilisateurs génèrent et évaluent des exemples de comportement des logiciels.

Les défis de l’application de BDD dans les tests de logiciels

Les défis de la mise en œuvre de BDD dans les tests de logiciels peuvent être décrits comme suit :

• La BDD a donné lieu à des comportements excessivement étroits en raison de réunions prolongées avec les parties prenantes et de la nécessité d’inclure toutes les parties prenantes clés dans le processus de BDD.

• En tant que M. John Ferguson Smart est un conférencier, consultant, auteur et formateur international réputé, expert en automatisation des tests agiles, BDD et bien plus encore.

• Le BDD nécessite un logiciel méticuleusement préparé pour que les scripts Gherkin articulent efficacement les exigences commerciales. Elle peut parfois s’opposer au rythme rapide des équipes Agile qui travaillent sur la base de spécifications succinctes.

• L’un des principes de BDD part du principe qu’il est difficile de connaître toutes les exigences dès le départ et qu’il n’est pas nécessaire de les définir toutes au cours de la première phase d’un projet, mais plutôt que les connaissances des parties prenantes évolueront tout au long du projet.

• BDD nécessitera une expérience dans la conception et l’écriture de tests d’acceptation automatisés pour certaines applications complexes.

Emballer:

Le développement guidé par le comportement est une stratégie très intelligente dans le cadre de la méthodologie agile. BDD offre une plateforme permettant de travailler de manière indépendante avec différentes technologies, il est donc toujours conseillé de commencer votre développement ou vos tests avec.

En encourageant une collaboration efficace entre les parties prenantes, en favorisant une communication claire et en mettant l’accent non plus sur les tests en tant qu’activité isolée, mais sur une compréhension partagée des comportements souhaités, le développement guidé par le comportement (BDD) a le potentiel de révolutionner les tests de logiciels.

Lectures associées :

• Changement efficace à gauche avec BDD
• Mise en place d’un cadre d’automatisation des tests évolutif pour une société leader dans le domaine des solutions technologiques d’investissement.
• Le fournisseur de solutions de marketing basé aux États-Unis réalise une amélioration de 95 % de la couverture des tests