Upgrade to Pro — share decks privately, control downloads, hide ads and more …

BDD: Une conversation pour découvrir et spécifier les besoins d’affaires

BDD: Une conversation pour découvrir et spécifier les besoins d’affaires

/ Version de 2017-11 (Agile Tour Québec 2017)

Nous croyons que le BDD est le fil conducteur pour rassembler les analystes, les affaires, le QA et les développeurs.

L’essence du BDD réside dans la conversation et la compréhension commune de tous les intervenants (“amigos”). C’est bien plus qu’une technique de test...

À l’aide de cas vécus, nous présenterons le processus complet du BDD: spécification par l’exemple, tests et documentation vivante.

Félix-Antoine Bourbonnais

November 07, 2017
Tweet

More Decks by Félix-Antoine Bourbonnais

Other Decks in Technology

Transcript

  1. &
    FÉLIX-ANTOINE
    BOURBONNAIS
    B.ING., M.SC, PSM
    Agile Tour Québec 2017
    Le BDD: Une conversation pour
    découvrir et spécifier les besoins
    d’affaires
    PASCAL ROY
    ING., CSM, PSM, PMP

    View Slide

  2. Diapositives et références
    http://conferences.elapsetech.com/bdd-spec-affaires/
    Cette présentation s’adresse à un public
    débutant désirant s’initier au BDD.

    View Slide

  3. Le BDD n’est pas une technique de test

    View Slide

  4. Le BDD peut être fait sans outils
    comme Cucumber, SpecFlow, etc.

    View Slide

  5. Le BDD est un processus pour
    découvrir, spécifier et documenter les
    requis d’affaires

    View Slide

  6. View Slide

  7. Cadre de la conférence
    Public cible
    Cette présentation
    s’adresse à un public
    débutant désirant
    s’initier au BDD.
    Nos objectifs
    • Comprendre (survol) ce qu’est le BDD
    et pouvoir continuer à explorer le sujet
    • Le BDD n’est pas une technique de test
    • Le BDD est une approche pour la
    découverte et la spécification

    View Slide

  8. 8
    Qui sommes-nous ?
    Pascal Roy
    Ing., PSM, CSM, PMP
    Félix-Antoine Bourbonnais
    B.ing., PSM, M.Sc.

    View Slide

  9. Formations Mentorat Diagnostics Conférences

    View Slide

  10. Conférenciers
    Formateurs
    Mentors &
    coaches
    Tech.
    Équipe &
    Affaires
    Gestion
    TDD
    Architecture
    évolutive
    Essais
    automatisés
    DDD

    Scrum
    QA Agile
    Gestion de
    projets
    BDD
    > Nous sommes
    Conseils
    stratégiques
    > Spécialités
    Agilité

    View Slide

  11. Quels sont les défis typiques
    concernant la documentation ?

    View Slide

  12. > Transmission et distorsion de l’information
    Passage de documents souvent sans explications et contexte
    > Interprétations différentes
    Impossibilité de transmettre directement un modèle mental
    > Documentation pas à jour
    Quelle est la quantité réaliste que l’on pourra garder à jour?
    > La qualité ≠ la quantité
    Plus de texte ≠ plus clair
    Problèmes concernant la documentation

    View Slide

  13. View Slide

  14. Est-ce que je produis
    la bonne chose?
    (« Building the right thing »)
    14

    View Slide

  15. BDD :
    « Behavior-Driven Development »
    BDD ?!? 15

    View Slide

  16. 16
    Un processus
    pour comportement
    souhaité d’un
    système
    le
    Explorer
    Découvrir
    Spécifier
    Piloter

    View Slide

  17. Comportement
    (« behavior »)
    * Système au sens large et peut englober plusieurs systèmes « physiques »
    ou applications dans certains cas.
    Comportement ?!?
    17
    Contexte
    Action
    Conséquence
    (« outcome »)

    View Slide

  18. 18
    Explorer
    Découvrir
    Spécifier
    Piloter
    le développement avec
    des tests automatisés
    et piloter
    une spécification
    exécutable
    =
    la conversation et
    des exemples concrets
    utilisant
    une compréhension
    commune du problème
    pour forger

    View Slide

  19. Les ingrédients
    BDD
    +
    =
    Spécification par
    l’exemple
    1
    Automatisation des
    scénarios en tests
    2
    Conversations

    View Slide

  20. Tests
    Fonctionne comme prévu? + vérifie et valide le développement
    BDD
    Bon comportement/produit? + guide le développement
    BDD versus Tests

    View Slide

  21. Il était une fois…
    Sprint courant
    Sprint -1
    Story 4
    • Alice --> Propriétaire du produit
    • Jean --> Assurance qualité
    • Bob --> Développeur
    • La Story 4 devrait être
    réalisée dans le prochain
    sprint
    Explorons la Story 4…
    • Sa portée
    • Ses critères d’acceptation et règles d’affaires
    • Etc.

    View Slide

  22. 1

    View Slide

  23. Où ?
    Découverte

    View Slide

  24. Atelier de découverte
    Atelier de découverte
    … plus de…
    … plus petites …
    Compréhension
    commune
    Règles d’affaires
    (critères d’acceptation)
    Questions
    Exemples
    (scénarios)
    Story /
    Fonctionnalité

    View Slide

  25. Qui ?
    Découverte

    View Slide

  26. 3 Amigos
    26
    Affaires / Produit
    - Valeur –
    Dev / Ops / …
    - Faisabilité –
    QA / UX
    – Utilisabilité & détails –

    View Slide

  27. 3 Amigos ≠ 3 personnes
    27

    View Slide

  28. 28
    Affaires
    A le contexte, le
    pourquoi
    et connaît la valeur.
    QA / UX
    Pense naturellement
    aux détails et à
    l’utilisabilité
    Dev & Ops
    Pense à la faisabilité et
    aux aspects techniques
    et à la complexité

    View Slide

  29. Comment ?
    Découverte

    View Slide

  30. User Story /
    Fonctionnalité • Règles d’affaires; et/ou
    • Critères d’acceptation;
    • Conditions de succès
    Mais avons-nous compris la
    même chose ?
    Est-ce que ça veut dire X
    ou Y ?
    décrite par

    View Slide

  31. BDD
    centré autour
    Des
    conversations

    View Slide

  32. J’ai écrit mes
    « BDDs »
    Voici les
    scénarios

    View Slide

  33. Le BDD permet à l’équipe de
    découvrir et s’approprier la
    spécification
    Voici
    les scénarios

    View Slide

  34. Donne-moi un exemple!
    34

    View Slide

  35. On utilise des exemples pour
    communiquer et découvrir les règles.

    View Slide

  36. Déroulement
    Exemple
    Et si..
    Dans ce
    cas…
    Questions
    sous forme
    d’exemples

    View Slide

  37. Ainsi, on valide que tous ont la même
    compréhension et qu’il ne manque pas
    de règles importantes.

    View Slide

  38. Pour une activité ludique sur l’interprétation des
    règles à faire avec votre équipe:
    https://www.slideshare.net/Reloaddk/bdd-how-to-solve-
    communication-problems

    View Slide

  39. Le principe
    39
    Scénario
    (exemple)
    Règle /
    Critère
    illustre

    View Slide

  40. Concrètement ?
    Découverte

    View Slide

  41. Limite quotidienne de retrait
    Si limite=1000
    Et déjà retrait =500 le 7 Nov.
    Montant=500 le 7 Nov.
    ->OK
    Si limite=1000
    Et déjà retrait =500 le 7 Nov.
    Montant=501 le 7 Nov.
    ->Refusé
    Si limite=1000
    Et déjà retrait =500 le 7 Nov. 23h59
    Montant=501 le 8 Nov. 00h01
    ->?????
    Story: Retirer au guichet

    View Slide

  42. Limite quotidienne de retrait
    Si limite=1000
    Et déjà retrait =500 le 7 Nov. 13h00
    Montant=500 le 7 Nov. 14h00
    ->OK
    Si limite=1000
    Et déjà retrait =500 le 7 Nov. 13h00
    Montant=501 le 7 Nov. 14h00
    ->Refusé
    Si limite=1000
    Et déjà retrait =500 le 7 Nov. 23h59
    Montant=501 le 8 Nov. 00h01
    ->Refusé
    Si limite=1000
    Et déjà retrait =500 le 7 Nov. 23h59
    Montant=501 le 9 Nov. 00h00
    ->OK
    Story: Retirer au guichet
    Autre règle
    Exemple 1

    View Slide

  43. Il existe des activités pour mener les ateliers
    (ex.: Example Mapping, Feature Mapping, …)

    View Slide

  44. Activité: « Example Mapping »
    Fonctionnalité /
    Story
    Règle
    Exemple
    Questions à
    valider
    Nouvelle Story
    Nouvelle Story
    Règle Règle
    Exemple
    Exemple
    Exemple Exemple
    Exemple

    View Slide

  45. Démonstration
    Example Mapping Story:
    Retirer au guichet
    Doit avoir assez
    de fonds
    Par tranche de 20$ Limite quotidienne
    Si carte 123 est bloquée
    Et j’essaie de retirer
    ????
    20$ -> OK
    21$ -> Err
    40$ -> OK
    1000$ @ 13h
    1$ @ 14h  Non
    1000$ @ 13h le 7
    1$ @ 13h le 8 -> OK
    1000$ @ 23h59
    1$ @ 00h01 -> NON


    Distribution $$
    exclue
    Déjà authentifié
    Limites (scope):

    View Slide

  46. Pour en savoir plus sur l’Example Mapping
    https://cucumber.io/blog/2015/12/08
    /example-mapping-introduction

    View Slide

  47. 2

    View Slide

  48. Quand ?
    Qui ?
    Spécification

    View Slide

  49. fnc.feature
    Déroulement
    Scénarios
    Découvrir 1
    Atelier de découverte
    Exemple
    Spécifier 2
    Description du contexte
    - Règle
    - Règle

    View Slide

  50. 1. Prendre les règles et les exemples trouvés lors de la découverte
    2. Mettre au propre (pas en groupe!) --> Spécification
    3. L’équipe s’entend sur le comportement
    Écrire la spécification

    View Slide

  51. Sous quel format?
    Spécification

    View Slide

  52. Des exemples
    sous différentes formes!

    View Slide

  53. On utilise généralement le Gherkin : un
    langage simple et textuel

    View Slide

  54. Comportement
    (« Behavior”)
    Le Gherkin
    54
    Contexte
    Action
    Conséquence
    (« Outcome”)
    Étant donné
    (« Given »)
    Quand
    (« When »)
    Alors
    (« Then »)

    View Slide

  55. Des exemples concrets
    Scénario: Retirer avec un solde suffisant
    Étant donné un compte avec 600$
    Quand je fais un retrait de 400$
    Alors le retrait est autorisé
    Et le solde du compte est de 200$
    Gherkin

    View Slide

  56. Scénario Gherkin versus tests
    Test: Retirer avec un solde suffisant
    1. Se connecter avec compte ‘C37362’
    2. Aller dans les opérations > Retrait
    3. Faire un retrait de 400$
    4. => un message montre que c’est
    accepté
    5. Aller dans le sommaire
    6. => Le solde doit être de 200$
    Scénario: Retirer avec un solde suffisant
    Étant donné un compte avec 600$
    Quand je fais un retrait de 400$
    Alors le retrait est autorisé
    Et le solde du compte est de 200$
    Impératif
    Étapes --> Actions
    Déclaratif
    Étapes --> Comportements

    View Slide

  57. « Feature File »

    View Slide

  58. Nos fonctionnalités composées de règles et de
    scénarios constituent maintenant une
    documentation

    View Slide

  59. 3

    View Slide

  60. Déroulement
    Découvrir 1
    Atelier de
    découverte
    Exemple
    Spécifier 2
    fnc.feature
    Scénarios
    Description du contexte
    - Règle
    - Règle
    1
    2
    3 TDD
    Piloter 3

    View Slide

  61. Piloter
    Fonctionnalité
    Code
    Tests
    automatisés
    Avancement

    View Slide

  62. Image du rapport: http://blog.jonasbandi.net/2010/03/classifying-bdd-tools-unit-test-driven.html
    Automatisation des tests
    Feature:
    Scenario: …
    Given …
    When …
    Then ..
    Scenario: ...
    Automatisation

    View Slide

  63. Spécification
    (exemple)
    Documentation
    vivante exécutable
    +
    =
    Règles
    (critères
    d’acceptation)
    Résultat des
    tests
    +

    View Slide

  64. Scénario
    Étant donné un scénario
    Quand nous l’avons
    Alors il est le point rassembleur
    Un scénario pour tous!
    Spécification
    Tests automatisés
    Documentation
    <
    Livraison
    &

    View Slide

  65. Tests fonctionnels automatisés

    Tests bout-en-bout via l’interface et la BD

    View Slide

  66. Image par Gamma-Ray Productions sur Flickr
    Attention en automatisant !
    % du portfolio
    de tests auto. Large (L)
    Moyen (M)
    Petit (S)
    ~10%
    ~20%
    ~70%
    Bout-en-bout
    Toutes composantes
    Une ou quelques classes
    Une composante
    intégrée
    Fragilité des tests

    View Slide

  67. View Slide

  68. En résumé…
    68
    1 En découvrant ensemble les scénarios et les règles, nous
    bâtissons une compréhension commune et forte.
    2 Les scénarios servent d’exemples pour piloter le
    développement.
    3 Les scénarios sont attachés à des tests automatisés qui
    démontrent l’avancement et préviennent la régression
    4 Les scénarios et règles documentent la fonctionnalité de
    manière permanente et vivante…

    View Slide

  69. Cynefin Framework
    Quand utiliser ou ne pas utiliser le BDD?
    69
    Simple
    Compliqué
    Complexe
    Chaos

    View Slide

  70. Le BDD est particulièrement utile pour découvrir
    et spécifier des règles impliquant de la logique
    d’affaires complexe

    View Slide

  71. merci .

    View Slide

  72. Site
    elapsetech.com
    Twitter
    @fbourbonnais
    Courriel
    [email protected]
    [email protected]
    conferences.elapsetech.com
    Toutes nos présentations
    conferences.elapsetech.com
    /bdd-spec-affaires
    Diapositives et références
    Félix-Antoine Bourbonnais
    Pascal Roy
    @

    View Slide

  73. View Slide

  74. Découpage vers une fonctionnalité
    Vision
    Objectifs d'affaires
    Capacités
    Fonctionnalités
    Stories
    Règles d'affaires / COS
    Scénarios / Exemples
    Code
    Pourquoi ?
    Comment ?
    Quoi ?

    View Slide

  75. Quand et où dans mon processus de développement?
    Pourquoi ?
    Comment ?
    Temps
    Objectifs
    d’affaires
    Activités de
    l’utilisateur
    Fonctionnalité
    Capacités
    Stories Règles Scénarios
    Tests &
    Code

    View Slide

  76. 76
    Sprint courant
    Story A
    ✔️✔️✔️✔️
    + Exemple 1 + 2+3
    Story B
    ✔️✔️✔️✔️
    Story C
    ✔️✔️✔️✔️
    Story X
    ✔️ ? ✔️ ?
    + Exemple 1 + 2+3
    + Exemple 1 + 2+3
    + Exemple 1 + ??
    Story Z
    ✔️ ? ✔️ ?
    Story ??
    Temps
    Sprint -1
    Sprint -2
    Sprint N

    View Slide