14 Avr 2016

Des cas de tests aux scénarios de la méthode BDD

Dans un précédent article, nous avons vu l’importance du dialogue pour espérer réussir à mettre en pratique la méthode BDD.

Ici, je vais tenter d’illustrer une autre problématique : comment passer des cas de tests aux scénarios BDD ?

J’ai été confronté à cette réflexion dans le cadre d’un atelier de Revue BDD pour présenter le premier besoin d’une nouvelle application.

Atelier de Revue

Le besoin était de pouvoir prendre connaissance d’un potentiel client afin de lui proposer la meilleure offre.

Effectivement, avant de proposer une offre, il convient de faire connaissance avec le client.

Nous nous retrouvons donc dans un atelier d’échange autour de cette première User Story « Saisir mes coordonnées »

 

Je présente très rapidement le déroulé de l’atelier :

  1. Le Product Owner présente son besoin avec le contexte et le but
  2. Des questions sont posées pour préciser la fonctionnalité et sa finalité
  3. Le Product Owner présente les règles métiers
  4. Des exemples sont proposés pour illustrer ces règles
  5. Des questions sont posées pour être sûr d’avoir compris les règles

Nous passons à la pratique :

  • PO : nous avons un écran avec des champs avec la maquette attachée à l’US.
  • DEV & QA : c’est beau 🙂
  • PO : tous les champs sont obligatoires
  • DEV & QA : ok, c’est clair
  • PO : il y a néanmoins quelques règles sur les champs :
    • la civilité : Mademoiselle, Madame, Monsieur : aucune valeur par défaut n’est cochée
    • Nom : texte : 15 caractères maximum
    • Prénom : texte : 28 caractères maximum
    • Date de naissance : affiche d’un dateTimePicker : vérification de date valide
    • Profession : liste des valeurs :
      • Etudiant(e)
      • Sans profession
      • Salarié(e)
      • Fonctionnaire
      • Enseignant(e) du premier degré
      • Enseignant(e) du  second degré ou supérieur
      • Retraite
      • Agriculteur(trice)
      • Autre
      • Inconnu
    • Téléphone : numérique : 10 caractères
    • email : contrôle du format de l’email : @ dans la chaîne, au moins un . après l’arobase et email et confirmation de l’email doivent être identiques
    • Adresse : texte : 100 caractères
    • Ville : texte : 26 caractères
    • Code Postal : numérique : 5 caractères
    • Case à cocher des offres commerciales : décochée par défaut et non obligatoire
    • Tous les champs sont obligatoires à part la case à cocher.
    • Le bouton Continuer : permet de passer à l’étape suivante sous condition que toutes les règles précédentes ont été validées.
  • DEV : le besoin est très clair, passons au scénarios
  • Nous proposons un cas passant et un cas non passant

CasTests

  • DEV : je suis satisfait, je sais « automatiser » ces deux cas avec Selenium (via protractor)
  • Tout va bien, nous pouvons passer à l’US suivante.

Tout ne s’est pas passé comme souhaité

Avec le recul, je me rend compte que nous sommes passé à côté : nous avons écrit deux cas de tests au format Gherkin et non des Scénarios de BDD.

  • Avons-nous validé les comportements de l’écran / de la fonctionnalité ?
  • Est-ce que le code produit est « testé » ? (pratique TDD avant BDD)
  • Notre code n’est-il pas déjà Legacy ?
  • Quelle documentation / spécification va rester ?

 

Toutes ces question me poussent à réagir : BDD n’est pas là pour expliquer l’US mais pour réaliser le développement par les tests avec toutes les parties prenantes du projet concernés par ces derniers. C’est de la spécification par l’exemple. Allons-y !

Comment s’améliorer ?

Fixons nous quelques règles :

  1. Etre conscient de la courbe d’apprentissage abrupte
    • tout d’abord, il est difficile d’obtenir des spécifications parfaites
    • continuer à pratiquer
    • c’était difficile pour tout le monde au début
  2. Identifier les règles de gestion
    • commencer par une liste de règles métier
    • faire un scénario pour chaque règle
    • ne pas essayer d’assembler plusieurs règles dans un seul scénario
  3. Rester simple
    • commencer par de petits scénarios
    • ne pas trop compliquer
  4. Le premier jet ne sera pas parfait
    • la spécification par l’exemple est un processus
    • la plupart du temps, vous modifierez les spécifications pour avoir de meilleurs comportements
    • le résultat final semble facile et évident, mais il est le produit de travail acharné et d’entrainement régulier
  5. Travailler ensemble donne un meilleur résultat
    • il est plus facile d’apprendre ensemble
    • vous obtenez un feedback instantané
    • c’est plus amusant
  6. Les étapes Given When Then ne sont pas des solutions miracles
    • bon pour décrire les règles métier
    • bon pour le comportement utilisateur
    • pas si bon pour les spécifications techniques
    • pas fait pour décrire l’interface utilisateur
  7. Utilisez ce que vous avez besoin à titre d’exemple
    • wireframe
    • tableau (Excel)
    • diagramme
  8. Utiliser des exemples précis de la vraie vie
    • pas : Given un utilisateur
    • mais : Given l’utilisateur “Manu”
    • utilisez vos “personas”
  9. Divisez les grandes tables
    • les exemples illustrent peut-être trop de règles
  10. Aucun mot de l’interface utilisateur

Le résultat

Chaque règle est illustrée par un scénario avec ses exemples

Tout d’abord le cas passant avec les valeurs par défaut

Feature1

Puis la saisie obligatoire, la taille des champs pour finir par la validité des champs

Feature2

Feature3

Conclusion

Chaque règle de la Story est illustrée par au moins un Scénario.

Le développeur peut facilement se servir des scénarios pour écrire son code et passer aux cycles de TDD.

Le temps n’est pas perdu puisque toute sera implémenté comme défini (illustré) ensemble 🙂

Une petite astuce

Petit Tip : vous pouvez ajouter une colonne au debut de vos exemples pour que les BDDs (lol, scénarios) aient un nom plus explicite

Tests

PO : Product Owner

DEV : développeur

QA : testeur

Share
  • Pierre Fiorelli

    Super article, j’aime beaucoup BDD. Mais pour pousser son utilisation il faut que ce soit bien industrialisé. Si je comprends bien tu utilise specflow uniquement pour écrire les BDD et tu fais l’automatisation avec sélénium? Je serais pas contre un petit article sur le sujet 🙂

    • Lehmann Emmanuel

      Tout d’abord, on n’écrit pas de BDD, BDD est une méthode. On décrit les spécifications du besoin en l’illustrant par des exemples ce qui donne des scénarios. Le langage utilisé est Gherkin. Ici comme le code est en .NET, c’est bien SpecFlow qui est utilisé mais tu peux utiliser Cucumber ou tout autre outils technique pour faire du BDD. Selenium n’est pas du BDD. BDD c’est comme TDD, tu écris des tests, puis tu implémente pour que les tests soient verts. Selenium c’est pour automatiser des cas de tests, rien a voir avec la méthode BDD.

      • Pierre Fiorelli

        Désolé pour le terme BDD, c’est un abus de langage de ma part (enfin de notre part, toute l’équipe l’utilise :s ). Effectivement je me demandais comme tu industrialisais tes scénarios.
        Par ailleurs as-tu un outil particulier pour les écrire, les mettre en forme et les valider? Notre CPQ les écrit directement en guerkin dans les US, sauf qu’il ne maîtrise pas ce langage. On se retrouve donc souvent avec des scénarios incorrects qu’il faut corriger dans VS à l’aide de specflow.
        Je suis conscient que le mieux serait de les écrire ensemble, mais aujourd’hui notre process est ce qu’il est. Néanmoins c’est déjà un début.

        • Lehmann Emmanuel

          Ecrire les scénarios ensemble est le point de départ de la méthode. Certains QSI ont Visual Studio mais ce n’est pas forcément la cible. Nous faisons des ateliers de Revue de la méthode BDD (l’échange des 3 amigos) et le compte rendu est le fichier feature. Il est fait par celui qui a l’outil qu’il faut, souvent, le développeur.
          Si les “Scénarios” sont livrés par un tiers, ça s’appelle un cas de test écrit au format Gherkin et en aucun cas un Scénario de BDD.
          La discussion est la force de la méthode. La documentation vivante (implémenter en partant des scénarios puis des cycles de TDD) est le résultat mais pas la finalité.

    • Lehmann Emmanuel

      Les articles techniques vont arriver 🙂

  • fabien bussiron

    J’aime pas le franglais. Je sais pas si specflow le permet, mais cucumber permet d’écrire tout en francais si besoin :
    https://github.com/cucumber/cucumber/wiki/Translations

    Et sinon personnellement, j’aurais plutôt écris un step de ce genre :
    Etant donné que je saisis ces informations :
    |prenom| nom | téléphone |etc
    |Gaston | Lagaffe | 012345678 | …

    Même si c’est un “faux” tableau (une seule ligne) ca donne quelque chose de moins verbeux, et extensible facilement. Et ca reste compatible avec l’utilisation d’Examples.
    Bon après les goûts et les couleurs…

    • Lehmann Emmanuel

      Bonjour Fabien,
      SpecFlow permet, comme cucumber, de tout faire en une seule langue.
      C’est un choix plutôt personnel qu’une contrainte de l’outil.
      Pour les steps, oui il était encore possible de factoriser les données dans un seul step. Ce n’était par contre pas l’objet de l’article. On peut aisément produire quelque chose de plus parfait avec plusieurs cycles de refacto des tests 😊