BDD - Spécifications par exemple

Selon Gojko Adzic, l'auteur de «Spécification par l'exemple», la spécification par l'exemple est un ensemble de modèles de processus qui facilitent le changement des produits logiciels pour garantir que le bon produit est livré efficacement. »

La spécification par l'exemple est une approche collaborative pour définir les exigences et les tests fonctionnels orientés métier pour les produits logiciels basés sur la capture et l'illustration des exigences à l'aide d'exemples réalistes au lieu d'énoncés abstraits.

Spécification par exemple - Aperçu

L'objectif de la spécification par l'exemple est de se concentrer sur le développement et la livraison d'exigences commerciales hiérarchisées et vérifiables. Bien que le concept de spécification par l'exemple en soi soit relativement nouveau, il s'agit simplement d'une reformulation des pratiques existantes.

Il prend en charge un vocabulaire très spécifique et concis connu sous le nom de langage omniprésent qui -

  • Active les exigences exécutables.

  • Est utilisé par tout le monde dans l'équipe.

  • Est créé par une équipe interfonctionnelle.

  • Capture la compréhension de chacun.

La spécification par l'exemple peut être utilisée comme entrée directe dans la création de tests automatisés qui reflètent le domaine métier. Ainsi, l'objectif de la spécification par l'exemple est de créer le bon produit et de créer le bon produit.

Objectif de la spécification par exemple

L'objectif principal de la spécification par l'exemple est de créer le bon produit. Il se concentre sur une compréhension partagée, établissant ainsi une source unique de vérité. Il permet l'automatisation des critères d'acceptation afin que l'accent soit mis sur la prévention des défauts plutôt que sur la détection des défauts. Il favorise également un test précoce pour trouver les défauts tôt.

Utilisation de SbE

La spécification par l'exemple est utilisée pour illustrer le comportement attendu du système qui décrit la valeur métier. L'illustration se fait au moyen d'exemples concrets et réels. Ces exemples sont utilisés pour créer des exigences exécutables qui sont -

  • Testable sans traduction.

  • Capturé dans la documentation en direct.

Voici les raisons pour lesquelles nous utilisons des exemples pour décrire des spécifications particulières -

  • Ils sont plus faciles à comprendre.

  • Ils sont plus difficiles à mal interpréter.

Avantages de SbE

Les avantages de l'utilisation de la spécification par l'exemple sont:

  • Augmentation de la qualité

  • Réduction des déchets

  • Réduction du risque de défauts de production

  • Un effort ciblé

  • Les modifications peuvent être effectuées de manière plus sûre

  • Meilleure implication des entreprises

Applications de SbE

Spécification par exemple trouver des applications dans -

  • Soit une entreprise complexe, soit une organisation complexe.

  • Ne fonctionne pas bien pour les problèmes purement techniques.

  • Ne fonctionne pas bien pour les produits logiciels axés sur l'interface utilisateur.

  • Peut également être appliqué aux systèmes hérités.

SbE et tests d'acceptation

Les avantages de la spécification par l'exemple en termes de tests d'acceptation sont:

  • Une seule illustration est utilisée pour les exigences détaillées et les tests

  • L'avancement du projet est en termes de tests d'acceptation -

    • Chaque test consiste à tester un comportement.

    • Un test passe pour un comportement ou il ne l'est pas.

    • Un test de réussite indique que le comportement particulier est terminé.

    • Si un projet qui nécessite 100 comportements pour être achevé a 60 comportements terminés, alors il est terminé à 60%.

  • Les testeurs passent de la correction des défauts à la prévention des défauts et contribuent à la conception de la solution.

  • L'automatisation permet une compréhension instantanée de l'impact d'un changement d'exigence sur la solution.

Spécification par exemple - Ce que cela signifie pour différents rôles

L'objectif de la spécification par l'exemple est de promouvoir la collaboration de tous les membres de l'équipe, y compris le client tout au long du projet, pour offrir une valeur commerciale. Tout le monde pour une meilleure compréhension utilise le même vocabulaire.

Rôle Utilisation de SbE
Analyste d'affaires
  • Les exigences sont claires et sans lacunes fonctionnelles.

  • Développeurs, lisez les spécifications.

Développeur
  • Les développeurs comprennent mieux ce qui est développé.

  • La progression du développement est mieux suivie en comptant les spécifications qui ont été développées correctement.

Testeur
  • Les testeurs comprennent mieux ce qui est testé.

  • Les testeurs sont impliqués dès le début et ont un rôle dans la conception.

  • Les testeurs travaillent à la prévention des défauts plutôt qu'à la détection des défauts.

Toutes les personnes
  • Le temps est gagné en identifiant les erreurs depuis le début.

  • Un produit de qualité est fabriqué dès le départ.

SbE - Un ensemble de modèles de processus

Comme nous l'avons vu au début de ce chapitre, la spécification par l'exemple est définie comme un ensemble de modèles de processus qui facilitent le changement des produits logiciels pour garantir que le bon produit est livré efficacement.

Les modèles de processus sont -

  • Spécification collaborative

  • Illustrer les spécifications à l'aide d'exemples

  • Affiner la spécification

  • Exemples d'automatisation

  • Valider fréquemment

  • Documentation vivante

Spécification collaborative

Les objectifs de la spécification collaborative sont:

  • Obtenez les différents rôles dans une équipe pour avoir une compréhension commune et un vocabulaire partagé.

  • Impliquez tout le monde dans le projet afin qu'ils puissent apporter leurs différents points de vue sur une fonctionnalité.

  • Assurer une communication et une appropriation partagées des fonctionnalités.

Ces objectifs sont atteints dans un atelier de spécification également connu sous le nom de réunion des Trois Amigos. Les Trois Amigos sont BA, QA et le développeur. Bien qu'il existe d'autres rôles dans le projet, ces trois rôles seraient responsables de la définition à la livraison des fonctionnalités.

During the meeting −

  • Le Business Analyst (BA) présente les exigences et les tests pour une nouvelle fonctionnalité.

  • Les trois Amigos (BA, développeur et QA) discutent de la nouvelle fonctionnalité et examinent les spécifications.

  • Le QA et le développeur identifient également les exigences manquantes.

  • Les trois Amigos

    • Utilisez un modèle partagé en utilisant un langage omniprésent.

    • Utilisez le vocabulaire du domaine (un glossaire est mis à jour si nécessaire).

    • Recherchez les différences et les conflits.

  • Ne passez pas aux détails d'implémentation à ce stade.

  • Parvenez à un consensus pour savoir si une fonctionnalité a été suffisamment spécifiée.

  • Un sens partagé des exigences et de l'appropriation des tests facilite les spécifications de qualité

  • Les exigences sont présentées sous forme de scénarios, qui fournissent des exigences explicites et sans ambiguïté. Un scénario est un exemple du comportement du système du point de vue des utilisateurs.

Illustrer les spécifications à l'aide d'exemples

Les scénarios sont spécifiés à l'aide de la structure Given-When-Then pour créer une spécification testable -

Given <une condition préalable>

And <conditions préalables supplémentaires> Optional

When <une action / un déclencheur se produit>

Then <une condition postérieure>

And <conditions de publication supplémentaires> Optional

Cette spécification est un exemple de comportement du système. Il représente également un critère d'acceptation du système.

L'équipe discute des exemples et les commentaires sont incorporés jusqu'à ce qu'il y ait accord sur le fait que les exemples couvrent le comportement attendu de la fonctionnalité. Cela garantit une bonne couverture des tests.

Affiner la spécification

Pour affiner une spécification,

  • Soyez précis dans la rédaction des exemples. Si un exemple s'avère complexe, divisez-le en exemples plus simples.

  • Concentrez-vous sur la perspective commerciale et évitez les détails techniques.

  • Considérez à la fois les conditions positives et négatives.

  • Adhérez au vocabulaire spécifique au domaine.

  • Discutez des exemples avec le client.

    • Choisissez des conversations pour y parvenir.

    • Considérez uniquement les exemples qui intéressent le client. Cela permet de produire uniquement le code requis et évite de couvrir toutes les combinaisons possibles, qui peuvent ne pas être requises

  • Pour garantir la réussite du scénario, tous les cas de test de ce scénario doivent réussir. Par conséquent, améliorez les spécifications pour les rendre testables. Les cas de test peuvent inclure diverses plages et valeurs de données (cas de limite et d'angle) ainsi que différentes règles métier entraînant des modifications des données.

  • Spécifiez des règles métier supplémentaires telles que des calculs complexes, la manipulation / transformation de données, etc.

  • Inclure des scénarios non fonctionnels (par exemple, performances, charge, utilisabilité, etc.) comme spécification par exemple

Exemples d'automatisation

La couche d'automatisation doit rester très simple - il suffit de câbler la spécification au système testé. Vous pouvez utiliser un outil pour le même.

Effectuez l'automatisation des tests à l'aide du langage DSL (Domain Specific Language) et montrez une connexion claire entre les entrées et les sorties. Concentrez-vous sur la spécification et non sur le script. Assurez-vous que les tests sont précis, faciles à comprendre et testables.

Valider fréquemment

Incluez un exemple de validation dans votre pipeline de développement à chaque changement (ajout / modification). Il existe de nombreuses techniques et outils qui peuvent (et devraient) être adoptés pour aider à garantir la qualité d'un produit. Ils s'articulent autour de trois principes clés:Test Early, Test Well et Test Often.

Exécutez les tests fréquemment afin de pouvoir identifier les maillons faibles. Les exemples représentant les comportements aident à suivre la progression et un comportement n'est dit complet qu'après la réussite du test correspondant.

Documentation vivante

Gardez les spécifications aussi simples et courtes que possible. Organisez les spécifications et faites-les évoluer au fur et à mesure de l'avancement des travaux. Rendre la documentation accessible à tous dans l'équipe.

Spécification par exemple d'étapes de processus

L'illustration montre les étapes du processus dans Spécification par l'exemple.

Anti-motifs

Les anti-modèles sont certains modèles de développement logiciel qui sont considérés comme une mauvaise pratique de programmation. Contrairement aux modèles de conception, qui sont des approches courantes de problèmes communs, qui ont été formalisés et sont généralement considérés comme une bonne pratique de développement, les anti-modèles sont le contraire et ne sont pas souhaitables.

Les anti-modèles posent divers problèmes.

Anti-motif Problèmes
Pas de collaboration
  • De nombreuses hypothèses

  • Construire une mauvaise chose

  • Tester une mauvaise chose

  • Je ne sais pas quand le code est terminé

Je ne sais pas quand le code est terminé
  • Tests difficiles à maintenir

  • Difficile à comprendre les spécifications

  • Perte d'intérêt des représentants d'entreprises

Exemples trop détaillés ou trop centrés sur l'interface utilisateur
  • Tests difficiles à maintenir

  • Spécifications difficiles à comprendre

  • Perte d'intérêt des représentants d'entreprises

Sous-estimation de l'effort requis
  • Les équipes pensent avoir échoué et sont déçues tôt

Solution aux problèmes - Qualité

La qualité peut être assurée en surveillant les anti-motifs. Pour minimiser les problèmes créés par les anti-modèles, vous devez -

  • Réunissez-vous pour spécifier à l'aide d'exemples.

  • Nettoyez et améliorez les exemples.

  • Ecrire un code qui satisfait les exemples

  • Automatisez les exemples et déployez.

  • Répétez l'approche pour chaque user story.

Résoudre les problèmes dus aux anti-motifs signifie l'adhésion à -

  • Collaboration.

  • Se concentrer sur quoi.

  • Se concentrer sur les affaires.

  • Soyez prêt.

Comprenons ce que chacun de ces éléments signifie.

Collaboration

En collaboration -

  • Les gens d'affaires, les développeurs et les testeurs donnent leur avis de leur propre point de vue.

  • Des exemples automatisés prouvent que l'équipe a construit la bonne chose.

  • Le processus est plus précieux que les tests eux-mêmes.

Se concentrer sur quoi

Vous devez vous concentrer sur la question - «quoi». Tout en se concentrant sur `` quoi '' -

  • N'essayez pas de couvrir tous les cas possibles.

  • N'oubliez pas d'utiliser différents types de tests.

  • Gardez les exemples aussi simples que possible.

  • Les exemples doivent être facilement compréhensibles par les utilisateurs du système.

  • Les outils ne devraient pas jouer un rôle important dans les ateliers.

Se concentrer sur les affaires

Se concentrer sur l'entreprise -

  • Gardez les spécifications à l'intention de l'entreprise.

  • Incluez les entreprises dans la création et la révision des spécifications.

  • Masquez tous les détails de la couche d'automatisation.

Soyez prêt

Soyez prêt pour ce qui suit -

  • Les avantages ne sont pas immédiatement apparents, même si les pratiques de l'équipe sont modifiées.

  • La présentation de SbE est un défi.

  • Nécessite du temps et des investissements.

  • Les tests automatisés ne sont pas gratuits.

Outils

L'utilisation d'outils n'est pas obligatoire pour la spécification par l'exemple, bien qu'en pratique plusieurs outils soient disponibles. Il y a des cas qui réussissent après la spécification par l'exemple même sans utiliser d'outil.

Les outils suivants prennent en charge la spécification par exemple -

  • Cucumber

  • SpecFlow

  • Fitnesse

  • Jbehave

  • Concordion

  • Behat

  • Jasmine

  • Relish

  • Speclog