Webinar - Mieux s'entendre entre Dev / PO / Testeur avec TDD et BDD

TDD (Test Driven Development) / BDD / ++
Mieux délivrer et s'entendre entre Dev / Testeur / PO!
#INSPIRER #CATALYSER #DELIVRER
At

DC CONSULTANTS - Catalyser vos transformations ! 2
Avez-vous déjà pratiqué du TDD ou du
BDD en pratique dans des projets ?

Transformation de notre Meetup en Webinar
Nouveau contexte COVID
Learning en continu

Comprendre comment le TDD peut aider à délivrer ?
Comment améliorer la communication entre tous les
acteurs du sujet : Développeur, Testeur, Product Owner, … ?
Faire un lien entre Agilité et Testing
Quelles bonnes pratiques ?
DC CONSULTANTS - Catalyser vos transformations !
4
Moins utile pour vous si :
• Vous pratiquez déjà TDD/BDD régulièrement
• Pour vous, « tester c’est douter »

Qui sont les intervenants ?
Le pitch
1/ Pourquoi tester ?
2/ TDD / BDD / Test by example : qu’est-ce ?
3/ Améliorer la communication : feedback
4/ Questions / Réponses
6

Alex GON
• Consultant, coach, formateur
• Fondateur de DC CONSULTANTS et la communauté des
Digital Catalysts
• Accompagner les transformations digitales, donner du sens
• Parcours : #Utilities #Startup #Conception #Product Owner
#Coaching d’organisations
• Passions : #agilité #aider #vélo #forgoodprojects

DC CONSULTANTS - Catalyser vos
transformations !
9
• En ce moment :
• Agile Scrum Master PSM 1 / Product Owner PSPO 1
• Design Thinking / Lean Startup
• DEVOPS / ITIL v4
• Classe virtuelle, adapté
• Financement à 100% via votre CPF ou OPCO
• Pour vous :
• une réduction de 15% sur les prochaines sessions
• + discount si vous inscrivez 2 personnes et plus
Comment faire :
• écrire à Alex maintenant en chat privé
• écrire à sales@dc-consultants.net pour demander plus d’infos inscriptions

11
• Tester c’est douter ?

• “Quality is never an accident; it is always the result of intelligent
effort.” – John Ruskin
• “A pinch of probability is worth a pound of perhaps.” James
Thurber
• “Software never was perfect and won’t get perfect. But is that a
license to create garbage? The missing ingredient is our
reluctance to quantify quality.” – Boris Beizer

• Aller droit au but : faire en sorte d’avoir le comportement
attendu
• Aligner la vision Produit et Technique : Product Owner,
Développeur, Testeur, …
• Gagner du temps pour réduire le processus de livraison :
• Délivrer de la qualité
• Délivrer régulièrement

• Vous avez :
• Des tests manuels
• Beaucoup de tests d’acceptation qui demandent de gros efforts de mains
d’œuvre à chaque livraison.
• Vous avez de grosses livraisons
• Vous avez des tests unitaires mais vous n’avez pas ou ne stockez pas les
résultats
• Vous n’avez pas de stratégie de tests ou vous ne savez plus ce qu’il y a
dedans
UI test
services
TU

• A voir selon votre cas
• Les tests sont pensés avec les fonctionnalités
• Les tests sont d’abord pensés pour être
automatisés
• La grande majorité des tests sont automatisés
• Vous avez une stratégie de tests à jour et
améliorée en continu
E to E
Services
TU

UI test
services
E to E
Services
TU
E to E
Services
TU
UI test
services
TU
UI test
services
TU
UI test
services UI test
TU
E to E
Services
TU
E to E
Services
TUTU
TUF
TUF
TU

25
• Technique de développement
• Implémenter le test avant d’implémenter la fonctionnalité (= coder le test
avant de coder la fonction)
• Tests dits unitaires

26
3 lois du TDD :
1.Loi no 1 : Vous devez écrire un test qui échoue
avant de pouvoir écrire le code de production
correspondant.
2.Loi no 2 : Vous devez écrire une seule assertion à la
fois, qui fait échouer le test ou qui échoue à la
compilation.
3.Loi no 3 : Vous devez écrire le minimum de code de
production pour que l'assertion du test
actuellement en échec soit satisfaite.
Fonctionne très bien en Pair programming :
• L’un rédige le test
• L’autre code
• Échange des rôles
• (plusieurs roulements possibles)

27
• Hygiène garantie : faire évoluer sans crainte
• Réduction du temps de correction d’anomalie.
• Confiance en votre code, notamment vis-à-vis de votre équipe

28
• Souvent vu comme un investissement temps lourd
• Permet de maintenir un code de qualité dans le temps, donc « rentable »

29
• Penser les fonctionnalités selon le comportement
• Exprimer les besoins selon un comportement attendu
• « c’est le résultat qui compte »
• Je développe une fonctionnalité pour atteindre le comportement attendu

• Spécification par l'exemple
• Tests fonctionnels
• Documentation exécutable

30
• Illustrer la spécification / règle de gestion par un (des) exemple(s)
• Exemple : Google Doc
• En tant qu’utilisateur je souhaite pouvoir éditer un document à plusieurs en
simultané
• Jusqu’à 5 utilisateurs peuvent éditer un document
• Les utilisateurs ayant les droits peuvent compléter, commenter le document en même
temps
• Exemple : 5 personnes (A, B, C,D, E) ont accès au document « Recette.gdoc ». Ils
ouvrent le document en ligne, ils écrivent chacun leur nom en simultané. Les noms des
5 personnes sont visibles sur le document.
• Qui ? Le Product Owner, Business Analyst, Testeur

31
• Structure des tests en BDD :
• Etant donné que
• Lorsque
• Alors
 In english :
• Given
• When
• Then
• Standard reconnu par tous

32
• Exemple pour un moteur de recherche de contenu / comparateur
• Scenario: les suggestions proposées sont populaires, disponibles et adaptées à l'âge de l utilisateur
• Etant donné l'utilisateur "Tim"
• Et il a "4" ans
• Et les catégories populaires pour cet âge sont
| categorieId | nom |
| cat1 | Coloriage |
| cat2 | Comptines |
• Et les livres disponibles pour les catégories "cat1,cat2" sont
• | livreId | titre | categorieId |
• | lv11 | Colorier les poules | cat1 |
• | lv21 | Comptines de la ferme | cat2 |
• Quand on demande "2" suggestions
• Alors les suggestions sont
• | livreId | titre | categorieId |
• | lv11 | Colorier les poules | cat1 |
• | lv21 | Comptines de la ferme | cat2 |

• Documentation vivante : évolue de version en version,
• Pas de régression sur les versions livrées
• Architecture émergente : l’infrastructure du logiciel évolue au fur et à mesure

• Permet de décliner les objectifs du
produit, du Product Owner
• Centré sur le but, avec la contrainte de la
qualité
• Déclinaison des OKR au niveau du code

• Mettre en œuvre une démarche TDD / BDD oblige l’équipe à se parler :
• Attentes et besoins structurés du PO
• Discussions entre PO, Developpeurs, Testeurs,
• Plus de clarté
• Plus de factuel : exemples, résultats mesurables
 Bonnes recettes pour l’entente et le moral de l’équipe !

36
• Un panorama des classiques :

37
• Selon Gartner, les meilleurs en 2020 :
=> https://www.gartner.com/reviews/market/software-test-automation
=> https://medium.com/@briananderson2209/best-automation-testing-tools-for-2018-top-10-reviews-
8a4a19f664d2

38
• Pour les API / Webservices :

39
• Fitnesse : specifications executables Open Source
• Cucumber : specifications executables
• Katalon Studio : plateforme « All In One » : toutes applications, toutes technos
• Pour JIRA (ATLASSIAN) : XRAY
• Rédaction des scenarios Cucumber dans JIRA
• Centrealise les plans de tests projet et de l’entreprise, dans l’outil de gestion de votre travail
• Intégration avec la CI (intégration continue) (Bamboo, Jenkins)

Plusieurs pratiques selon les équipes croisées
Long chemin à mettre en œuvre
Difficultés/Challenges
Résultats ?

• Indispensable pour la livraison régulière : livrer à chaque fin de sprint,
ou en continu
• Augmente l’entente de l’équipe :
• Moins de refus sur le « fonctionnel » à posteriori (le PO qui refuse une
User Story…)
• Moins de discussions inutiles sur la classification Anomalie / Evolution /
Mauvaise spécification car meilleure anticipation

• Avoir une approche TDD, BDD, Automatiser les tests est excellent
• Mais les efforts sont lourds
• Garder une approche ROI : est-ce toujours rentable ?
• Sur une application en fin de vie ?
• Sur un projet déjà livré ?
• Sur un premier prototype ?

44
• Tester
• Peut couter très cher à la qualité de votre produit, et à la satisfaction utilisateur
• Sur la base du comportement attendu est plus efficace
• Est un bon moyen de créer de la communication entre Dev/PO/Testeur
• Automatiser les Tests
• C’est investir pour gagner du temps et de la qualité par la suite
• Y penser dès le début pour éviter les ennuis (= dette technique)
• Une idée / Envie
• d’intervenir
• de nous accueillir ?
• => alex.gon@dc-consultants.net

• Venir parler à votre CIO, DSI, CEO et vos équipes des enjeux
• Développement de vos talents :
o communauté,
o formations,
• Savoir-faire Digital Catalysts :
o Mindset de l’agilité dans les missions réalisées & suivies
• Des outils pour réussir
• Nos communautés :
o 1100+ Spécialistes agilité
o 800+ membres sur nos Meetups
Agilists
& Products
We

Alex GON
Principal Digital Catalyst
06 27 79 37 72
01 84 17 75 69
sales@dc-consultants.net
Activez la communauté Digital Catalysts :
https://www.linkedin.com/company/dc_consultants/
https://www.facebook.com/DigitalCatalysts/
Agile Nightmares : https://www.meetup.com/fr-FR/Agile-
Nightmares-by-Digital-Catalysts/

Webinar - Mieux s'entendre entre Dev / PO / Testeur avec TDD et BDD

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (19)

Similaire à Webinar - Mieux s'entendre entre Dev / PO / Testeur avec TDD et BDD

Similaire à Webinar - Mieux s'entendre entre Dev / PO / Testeur avec TDD et BDD (20)

Plus de DC CONSULTANTS

Plus de DC CONSULTANTS (20)

Webinar - Mieux s'entendre entre Dev / PO / Testeur avec TDD et BDD