Téléchargé parJean-Pierre Lambert
Introduction aux spécifications exécutables (dit aussi atdd, bdd)
Le document aborde l'importance des spécifications exécutables dans le développement de logiciels, en précisant qu'elles doivent être rédigées en collaboration entre les développeurs et les équipes fonctionnelles pour garantir leur compréhension commune. Il souligne également les écueils à éviter, comme la dépendance excessive à des outils magiques ou le manque d'investissement dans des tests appropriés. Finalement, il propose des outils et méthodes pour mettre en oeuvre ces spécifications, tels que Cucumber et le langage Gherkin.
Contenu connexe
Similaire à Introduction aux spécifications exécutables (dit aussi atdd, bdd)
![[PFE] Master en ingénierie du logiciel](https://cdn.slidesharecdn.com/ss_thumbnails/prezpfebrjuin2010v2-110814125524-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
![[V2] La collaboration, signe d'une véritable agilité](https://cdn.slidesharecdn.com/ss_thumbnails/lacollaborationsigneduneveritableagilite-v2-191210223241-thumbnail.jpg?width=640&height=640&fit=bounds)
![[V1] La collaboration, signe d'une véritable agilité](https://cdn.slidesharecdn.com/ss_thumbnails/lacollaborationsigneduneveritableagilite-next-191113002449-thumbnail.jpg?width=640&height=640&fit=bounds)
![[V2] Une semaine dans ma peau de testeur agile](https://cdn.slidesharecdn.com/ss_thumbnails/unesemainedansmapeaudetesteuragilev3-191103223449-thumbnail.jpg?width=640&height=640&fit=bounds)
![[V1] Une semaine dans ma peau de testeur agile](https://cdn.slidesharecdn.com/ss_thumbnails/unesemainedansmapeaudetesteuragilev1agiletourlille-191014221321-thumbnail.jpg?width=640&height=640&fit=bounds)
Introduction aux spécifications exécutables (dit aussi atdd, bdd)
- 1.
- 2. Qu’est-ce que laqualité ? Réponse à plusieurs dimensions
- 3. Besoins d’accomplissement desoi Besoins d’estime Besoins d’appartenance et d’amour Besoins de sécurité Besoins physiologiques Pyramide des besoins de Maslow
- 4. Besoins d’accomplissement desoi Besoins d’estime Besoins d’appartenance et d’amour Besoins de sécurité Besoins physiologiques Une vue partagée de la qualité Réussite Prospère Utile Intuitif Ergonomique Performant Sécurisé – Fiable Déployable FonctionnellementOK
- 5.
- 6. • Comment aligner cesvisions ? • En se parlant ! • Quelle méthode de facilitation ? • Les spécifications exécutables ! • Le moyen de s’assurer qu’on parle tous la même langue …? !
- 7. Spécifications exécutables ? Specby Example, Behavior-Driven Development
- 8. Une documentationvivante Toujours à jour Versionnée comme le code Vérifiable à tout instant par rapport au code Utile pour toute l’équipe
- 9. À chaque testson outil !
- 10.
- 11.
- 12.
- 13. Test Technique Test Fonctionnel Le test échoue: qui sait dire pourquoi ? Régression ou changement fonctionnel ? Requirement Technique Requirement Fonctionnel ?
- 14. Test Technique Test Fonctionnel Le test échoue: qui sait dire pourquoi ? Régression ou changement fonctionnel ? Requirement Technique Requirement Fonctionnel ? Qui doit pouvoir comprendre ce test ?
- 15. Test Technique Test Fonctionnel Le test échoue: qui sait dire pourquoi ? Régression ou changement fonctionnel ? Requirement Technique Requirement Fonctionnel ? Qui doit pouvoir comprendre ce test ? Langage : code Langage : pseudo- naturel
- 16. Test Technique Test Fonctionnel Le test échoue: qui sait dire pourquoi ? Régression ou changement fonctionnel ? Requirement Technique Requirement Fonctionnel ? Qui doit pouvoir comprendre ce test ? Langage : code Langage : pseudo- naturel Outils spécifiques Outils génériques
- 17. Test Technique Test Fonctionnel Le test échoue: qui sait dire pourquoi ? Régression ou changement fonctionnel ? Requirement Technique Requirement Fonctionnel ? Qui doit pouvoir comprendre ce test ? Langage : code Langage : pseudo- naturel Outils spécifiques Outils génériques
- 18. Test Technique Test Fonctionnel Le test échoue: qui sait dire pourquoi ? Régression ou changement fonctionnel ? Requirement Technique Requirement Fonctionnel ? Qui doit pouvoir comprendre ce test ? Langage : code Langage : pseudo- naturel Outils spécifiques Outils génériques Efficacité ! Lisibilité !
- 19. Pratiques à éviter Commentêtre sûr de ne pas y arriver
- 20. Ecueil 1 : Penserqu’un outil ou une méthode magique résoudra tous les problèmes ! But : 3 amigos ! Se parler, se parler, se parler… … Se comprendre ! …Travailler ensemble !
- 21. Ecueil 2 : Lesdev rédigent les spécifications exécutables. But : avoir un document de référence compréhensible par les fonctionnels Que va-t-il se passer si ce sont les dev qui rédigent ? Bonne pratique (obligatoire) : rédaction par PO/MOA … Mais bien entendu avec relecture/en coopération avec les dev’ ! (cf. slide précédente)
- 22. Ecueil 3 : Nepas investir dans l’outillage de test. But : avoir des tests tenus à jour et vérifiables à tout instant Appliquer les bonnes pratiques d’ingénierie ! Mettre en place une modélisation fonctionnelle, par exemple Page Object Model pour une appli web Sinon que va-t-il se passer ? Investir dans les outils : cher mais a-t-on le choix ? ©MartinFowler
- 23. Ecueil 4 : Focaliseruniquement ses efforts sur les tests de haut-niveau. But : réduire les régressions et maîtriser son produit Que va-t-il se passer si on néglige les tests bas niveau ? (unitaire + assemblage) Bonne pratique : tests haut-niveau pertinents si accompagnés d’une bonne couverture de tests unitaires et d’intégration dans tous les cas commencer par là !
- 24. Mise en pratique: Example Mapping Un atelier pour mettre en place la démarche
- 25. Example Map Blog deCucumber – Example Mapping Introduction http://bit.ly/example-map
- 27. Exemple de miseen place : FitNesse De la spec JIRA jusqu’au code
- 29. Résumé del’algorithme décrit par l’US : 1. Autoriser les tops manuels et ingestions (jobs de type manual et ingest) 2. Pour les tops automatiques: 1. Bloquer tout ce qui est interdit aux -16 et -18 2. Pour ce qui n'est pas -16/-18 : bloquer tout ce qui est Film, sauf s'il s'agit d'un Court métrage
- 30. Organisation de la base detest Factorisation préparation avant testSpec en langage naturel Les tests
- 31.
- 32.
- 35. Lien entre testet code métier Les tableaux sont des tests Métier : écriture des cas de test DEV : code de lien entre tests et code de prod
- 36. Données d’entrée des tests Lienentre test et code métier Chaque ligne est un test
- 37. Setup à partirdes données du test Appel du code métier Lien entre test et code métier Chaque ligne est un test
- 38. Résultats attendus Lien entre testet code métier Chaque ligne est un test
- 39. Exemple d’écriture detest workflow : Robot Framework Et un de ses IDE, RIDE
- 40.
- 41. Exemple « Given-When-Then» (Gherkin): Cucumber Ou selon votre plate-forme : Behat, SpecFlow…
- 43. Quel outil choisir? Comparaison et recommandations Spoiler alert : par défaut, prenez Cucumber
- 45. TL;DR • Tous lesoutils peuvent tout faire • Cucumber est le plus facile d’accès pour les non-techniques, et disponible partout
- 46. • Un outilétabli et connu • Installation triviale • Wiki intégré, format doc directement accessible • Runner disponible pour beaucoup de plate- formes • Les plus belles tables de décision • Un endroit où écrire du beau blabla • Un outil vieillot • Langage incohérent • Scénarii workflow imbitables • Concepts contre-intuitifs • Utilisation duWiki obligatoire, rapports de test et rédaction pas « text-friendly » • Pas d’éditeur avancé pour les non-dev
- 47. • Pas vraimentd’IDE qui s’adresse aux fonctionnels • La coloration syntaxique ne marche qu’en anglais • Langage restreint et contraignant • Plus (+) de code de lien • Multi-plate-forme au niveau source : Gherkin • Runner disponible sur quasiment tous les environnements, directement intégré • Prise en main simple, pas d’outil nécessaire à la rédaction • Des contraintes de rédaction qui en font un excellent outil pédagogique • Langage localisable en français • La référence dans le domaine : « Given-When- Then » est utilisé par tout le monde
- 48. • Langage trèscomplet, puissant, régulier • Réutilisation des mots-clés, sans limite • Multi-plate-forme avec possibilité de mélanger les technos dans le même test • Nombreuses librairies clé-en-main, ajout en Python ou serveurs de mots-clés dynamiques dans n’importe quel langage • Nombreux outils associés, matures et complets • Plusieurs vrais IDE non restreints aux développeurs • Liberté du format de test : workflow, table de décision, Given-When-Then… • Langage complexe, difficile d’accès aux non- techniques • IDE parfois buggé, certains use-cases du langage non supportés sans édition textuelle • Serveurs de mots-clés pas disponibles sur tous les environnements
- 49. • Littéralement unespec qu’on peut exécuter • Belle intégration d’images et autres éléments de description d’une spec • Plate-formes majeures uniquement (Java, C#, Python, Ruby)
- 50. • Rédaction enMarkDown, écosystème MarkDown pour le formatage et l’édition • Par ! • Plein de bonnes idées, essaie de reprendre le meilleur de ses aînés • Java / C# / Ruby / JavaScript / Python / Golang • Relativement jeune
- 51. • Mettre lepied à l’étrier des fonctionnels • Dispo quelle que soit votre techno • Multi-techno au niveau de Gherkin • Enorme communauté • Beaucoup d’outils dérivés • La référence !
- 52. Les différents membresde l’équipe dans la démarche Et le testeur, il fait quoi dans tout ça ?
- 54. Comment démarrer ? Alorsqu’on a déjà du code !
- 55.
- 56.
Notes de l'éditeur
- #4 Besoins physiologiques (faim, soif, sexualité, respiration, sommeil, élimination) Besoins de sécurité (environnement stable et prévisible, sans anxiété ni crise) Besoins d'appartenance et d'amour (affection des autres) Besoins d'estime (confiance et respect de soi, reconnaissance et appréciation des autres) Besoin d'accomplissement de soi
- #5 Besoins physiologiques (faim, soif, sexualité, respiration, sommeil, élimination) Besoins de sécurité (environnement stable et prévisible, sans anxiété ni crise) Besoins d'appartenance et d'amour (affection des autres) Besoins d'estime (confiance et respect de soi, reconnaissance et appréciation des autres) Besoin d'accomplissement de soi
- #11 Spec exécutable : Une documentation vivante, Toujours à jour, Versionnée comme le code, Vérifiable à tout instant par rapport au code
- #12 Spec exécutable : Une documentation vivante, Toujours à jour, Versionnée comme le code, Vérifiable à tout instant par rapport au code
- #13 Spec exécutable : Une documentation vivante, Toujours à jour, Versionnée comme le code, Vérifiable à tout instant par rapport au code
- #14 Spec exécutable : Une documentation vivante, Toujours à jour, Versionnée comme le code, Vérifiable à tout instant par rapport au code
- #15 Spec exécutable : Une documentation vivante, Toujours à jour, Versionnée comme le code, Vérifiable à tout instant par rapport au code
- #16 Spec exécutable : Une documentation vivante, Toujours à jour, Versionnée comme le code, Vérifiable à tout instant par rapport au code
- #17 Spec exécutable : Une documentation vivante, Toujours à jour, Versionnée comme le code, Vérifiable à tout instant par rapport au code
- #18 Spec exécutable : Une documentation vivante, Toujours à jour, Versionnée comme le code, Vérifiable à tout instant par rapport au code
- #19 Spec exécutable : Une documentation vivante, Toujours à jour, Versionnée comme le code, Vérifiable à tout instant par rapport au code
- #21 Spec exécutable : Une documentation vivante, Toujours à jour, Versionnée comme le code, Vérifiable à tout instant par rapport au code
- #22 Spec exécutable : Une documentation vivante, Toujours à jour, Versionnée comme le code, Vérifiable à tout instant par rapport au code
- #23 Spec exécutable : Une documentation vivante, Toujours à jour, Versionnée comme le code, Vérifiable à tout instant par rapport au code
- #24 Spec exécutable : Une documentation vivante, Toujours à jour, Versionnée comme le code, Vérifiable à tout instant par rapport au code
- #27 Spec exécutable : Une documentation vivante, Toujours à jour, Versionnée comme le code, Vérifiable à tout instant par rapport au code
- #41 Spec exécutable : Une documentation vivante, Toujours à jour, Versionnée comme le code, Vérifiable à tout instant par rapport au code
- #56 1. Rédiger un test sur l’existant 2. Le faire marcher 3. Définir un process pour les nouveaux développements 4. Intégrer l’écriture des tests d’acceptation en amont du dev !