Le document présente le développement piloté par le comportement (BDD), mettant en avant son rôle dans la collaboration entre développeurs, testeurs et propriétaires de produits. Il décrit différents types de tests, leurs avantages et inconvénients, ainsi que l'utilisation d'outils d'automatisation tels que Selenium et Watir. Le BDD permet une rédaction plus claire des user stories, facilitant la compréhension des critères d'acceptation et réduisant les ambiguïtés dans le développement logiciel.

1. Behavior Driven
Development
Yannick Quenec’hdu
novembre 2011
lundi 21 novembre 11

2. Les types de tests
Les tests structurels
(TDD aussi appelé test des boîtes blanches)
Les tests fonctionnels
(ATTD aussi appelé test des boîtes noires)
Les tests d’interfaces, ce sont les tests de
l’interface homme-machine
lundi 21 novembre 11

3. IL ÉTAIT UNE FOIS...
Je n’ai rien Tu devrais
à dire sur le en parler sur
sujet ton blog
les tests fonctionnels
lundi 21 novembre 11

4. Les différents tests fonctionnels
Approche centrée sur l’IHM
Spécifications exécutables
Behavior Driven Develpment
lundi 21 novembre 11

5. Approche centrée sur l’IHM
Ceux qui pilotent un navigateur et reproduisent les
interactions de l’utilisateur.
IHM
Outil de TF d’IHM Navigateur Application
lundi 21 novembre 11

6. Approche centrée sur l’IHM
Il existe aussi des outils, de type robots HTTP, qui eux
se substituent au navigateur
IHM
Outil de TF d’IHM Application
lundi 21 novembre 11

7. Approche centrée sur l’IHM
Avantage
Le test fonctionnel d’IHM permet de
reproduire en intégralité les scénarios
d’une application (vue de l’utilisateur)
lundi 21 novembre 11

8. Approche centrée sur l’IHM
Inconvénients
Les tests sont décrits dans un formalisme technique.
Certains outils peuvent pallier à cette contrainte, mais
on perd la démarche du développement piloté par les
tests
Ces tests semblent exhaustifs, mais ne le sont pas.
Par exemple toute la partie batch des applications est
exclue et de manière générale des pans entiers des
applications
lundi 21 novembre 11

9. Outils test IHM
Selenium - Licence OpenSource
Selenium est un ensemble de différents outils
pour l'automatisation des tests d’IHM
Watir - Licence OpenSource
Watir est un projet similaire à celui de
Selenium, il permet d’enregistrer et de rejouer
des tests avec différents navigateurs
lundi 21 novembre 11

10. Spécifications exécutables
Une autre approche est celle des spécifications
exécutables
Outil de
Fixtures
spécifications Application
exécutables
Permet à des utilisateurs fonctionnels de décrire au sein
d’un wiki le comportement métier
lundi 21 novembre 11

11. Spécifications exécutables
On remarque que l'IHM n'est pas testée. Une couche
de fixture s'y substitue.
Avantages
Le formalisme des spécifications est compréhensible
par des populations fonctionnelles.
Il est possible, au sein même des tests, d’écrire de la
documentation fonctionnelle dans un wiki.
Les pages de wiki sont des vraies spécifications
exécutables
lundi 21 novembre 11

12. Spécifications exécutables
Il est possible de compléter l’outil en l’intégrant avec des
tests de l’IHM.
Outil de
Fixtures
IHM
spécifications Outil de TF d’IHM Application
exécutables
lundi 21 novembre 11

13. La réalité
lundi 21 novembre 11

14. Spécifications exécutables
Inconvénients
Un coût important de mise en oeuvre en terme de
formation aux outils et d’intégration des fixtures
La sémantique du wiki est très spécifique aux outils
(tables de décision, query, etc)
Un wiki qui mélange les noms de classe, méthode et texte
statiques
lundi 21 novembre 11

15. Behavior Driven Devlopment
C’est une pratique qui encourage la collaboration entre
les développeurs, les testeurs et le Product Owner
BDD est un langage naturel qui en met en avant les
interactions du logiciel
Il limite la traduction entre le langage technique
(développeurs) et le langage métier (l’entreprise)
Permet d’automatiser les tests unitaires et de non-
régression
Il se situe entre TDD et ATDD
lundi 21 novembre 11

16. Outils de BDD
Plus d’une trentaine d’outils en
OpenSource pour l’ensemble des
langages informatique (Java, PHP, Ruby,
Net, Javascript, etc.)
lundi 21 novembre 11

17. Les tests BDD
lundi 21 novembre 11

18. Les tests avec BDD
Les tests user stories sont formalisés de manière
à ajouter des critères d’acceptation
BDD permet d’enrichir les user stories en
proposant des spécifications du comportement
de la user stories
Ce ne sont pas des critères d’acceptation
lundi 21 novembre 11

19. User stories
Une user story est une façon de “spécifier” un
besoin fonctionnel. C’est une surtout une
méthode de communication au sein d’une équipe
Agile
Une user story est exprimée selon la matrice
rôle / fonction
En tant que “rôle”, je veux “faire une action”,
afin d’ “atteindre un objectif”
lundi 21 novembre 11

20. ATDD
L’approche ATDD ou Acceptance Test Driven
Development implique de préciser le besoin
par la définition des critères de contrôles
(d’acceptation)
lundi 21 novembre 11

21. Exemple
“En tant qu’utilisateur, je veux me connecter à Google
afin d’accéder à tous mes services en lignes”
Imaginons les critères suivants :
•
L’utilisateur peut se connecter
•
La barre de menu Google présente les services
disponibles
•
L’utilisateur peut accéder à tous ces services
•
Google présente la liste des nouvelles fonctionnalités
disponibles
lundi 21 novembre 11

22. Les critères d’acceptation
Un critère d’acceptation doit être :
Une vision utilisateur
Ne pas proposer de solution
Ne pas être interne à la fonction
lundi 21 novembre 11

23. BDD
le langage Gherkin défini pour le BDD ou Behavior
Driven Developement
Aussi connu dans le monde Agile sous la pratique de
Given / When / Then (And).
Cette méthode est aussi appelée TDR pour Test
Driven Requirement ou exigences pilotées par les
tests.
lundi 21 novembre 11

24. BDD
BDD est bien plus qu’une pratique de test, c’est
une évolution dans la rédaction des Users
stories
En tant que testeurs vous êtes limité dans les
tests des users stories, parce qu’il n’y a pas de
contexte, de règle métier ou séquences
d’événements
lundi 21 novembre 11

25. Une user stories “Je suis... Je veux... Afin de...”
laisse la place à des interprétations erronées
La cause et l’effet ne sont pas décrits dans
les users stories
lundi 21 novembre 11

26. Contrairement aux users stories, le
“comportement” suggéré par le BDD apporte
le contexte (Etant donné que),
l’événement (Lorsque), et le résultat
(Alors)
lundi 21 novembre 11

27. Le contexte, l’événement et le résultat sont
identifiés pour chaque action de l’utilisateur ou
du système
BDD fonctionne comme une
spécification pour le comportement
du produit
lundi 21 novembre 11

28. Avantage
Permet aux développeurs et aux testeurs de
comprendre les actions à réaliser et comment le
système va répondre
Réduit les ambiguïtés dans les users stories
Fournit des spécifications simples et réduis les
aller-retour sur les users stories
BDD permet de se poser les bonnes questions
durant l’analyse de la user stories
L’activité de réflexion est mieux répartie au sein de
l’équipe
lundi 21 novembre 11

29. Résultat
10% du temps projet consacré au BDD
engendre 30% de déchets en moins durant le
cycle de vie du projet
BDD c’est LEAN
lundi 21 novembre 11

30. BDD en action
lundi 21 novembre 11

31. Une user stories à un
comportement
“En tant qu’utilisa
teur anonyme, je
connecter sur le veux me
site afin d'accéder
aux informations
de mon compte“
lundi 21 novembre 11

32. Les critères d’acceptations
La page d’accueil doit afficher une boîte de connexion
Le système doit valider les identifiants et les mots de passe
L’identifiant doit être au format email
Le mot de passe doit être avec un minimum de 6 caractères et
1chiffre
Le système doit afficher le tableau de bord si l’authentification
est valide
Le système doit afficher une erreur en cas d’authentification
incorrecte
lundi 21 novembre 11

33. Résultat
Le testeur indique vrai ou faux, le résultat
des tests d’acceptation
Aucune description des événements, ni des
actions de l’utilisateur
La cause et l’effet sont absents
Où est l’histoire derrière la user stories ?
lundi 21 novembre 11

34. BDD permet de raconter une histoire
lundi 21 novembre 11

35. La matrice GWT
La matrice Given - When - then est le format
utilisé pour la rédaction en BDD
Given (Etant donné que) : Le contexte
When (Lorsque) : L’action
Then (Alors) : Le résultat
And (Et) : Les autres résultats
lundi 21 novembre 11

36. “Scénario compte valide”
Étant donnée que je suis un utilisateur anonyme qui sait
précédemment enregistrer et qui se trouve sur l’espace de
connexion de la page d’accueil
Lorsque l’utilisateur saisit son identifiant et son mot de passe
dans la boîte de connexion et clique sur le bouton “connexion”
ou frappe sur la touche “Entrer”
Alors le système doit valider le nom de l’utilisateur et le mot de
passe et rediriger l’utilisateur vers le tableau de bord si le
compte est valide
Et il devra afficher l’identifiant de l’utilisateur en haut de la page
Et il devra actualiser la date de dernière connexion de
l’utilisateur sur la page
lundi 21 novembre 11

37. “Scénario compte invalide”
Étant donné que je suis un utilisateur anonyme qui sait
précédemment enregistré et qui se trouve sur l’espace de
connexion de la page d’accueil
Lorsque l’utilisateur saisi son identifiant et son mot de passe
dans la boîte de connexion et clique sur le bouton “connexion”
ou frappe sur la touche “Entrer”
Alors le système doit valider le nom de l’utilisateur et le mot de
passe
et si l’identifiant est invalide il doit afficher un message d’erreur
sur la page d’accueil “Identifiant invalide”
et si le mot de passe est invalide il doit afficher un message
d’erreur sur la page d’accueil “mot de passe invalide”
lundi 21 novembre 11

38. Dinosaure
Le cycle de vie BDD
lundi 21 novembre 11

39. Les acteurs Le testeur
Le PO
Développeurs
lundi 21 novembre 11

40. Le client exprime son besoin
lundi 21 novembre 11

41. Durant un atelier client....
lundi 21 novembre 11

42. Le Product Owner traduit ce besoin
User stories et
critères
d’acceptation
lundi 21 novembre 11

43. Le testeur rédige les tests en BDD...
lundi 21 novembre 11

44. avec les développeurs et le PO
lundi 21 novembre 11

45. les développeurs intègrent les tests
Scénario BDD
test BDD
lundi 21 novembre 11

46. le testeur réalise les tests BDD
lundi 21 novembre 11

47. et obtiens le résultat
lundi 21 novembre 11

48. Conclusion
lundi 21 novembre 11

49. Un produit
sans test
lundi 21 novembre 11

50. Un produit avec
des tests
lundi 21 novembre 11

51. Blog :
www.openagile.net
Contact :
yquenechdu@gmail.com
Remerciement :Erwan Le Gall
lundi 21 novembre 11

52. lundi 21 novembre 11