Développement d'un grand projet piloté par les tests (BDD)
1 j'aime•673 vues
Le projet de billettique à Helsinki utilise une approche BDD (behavior driven development) pour intégrer efficacement plusieurs partenaires et gérer un vaste système de 4000 équipements. Cette méthode favorise la collaboration entre les équipes métier, développement et test, tout en garantissant une qualité de service continue et une meilleure automatisation des tests. Le déploiement du BDD a permis une intégration réussie et une adaptation rapide des fonctionnalités, tout en respectant les délais et en améliorant la qualité du produit final.
Développement d'un grand projet piloté par les tests (BDD)
- 1. 1
- 2. Développement d’un projet billettique piloté par les tests métiers (BDD) 2
- 4. Plan • Contexte projet • Pourquoi avoir choisi l’approche BDD • Le déploiement du BDD étape par étape • Les pratiques clés • Conclusion 4
- 5. Contexte projet Le projet : Helsinki • donneur d’ordre finlandais (HSL), Intégrateur système Tieto (fournisseurs rang 1), plusieurs partenaires dont Parkeon • un planning sur 3 ans • un projet d’intégration multi-culturel • 4000 équipements connectés • 360 millions de passagers par an • une migration de système existant 5
- 6. Contexte projet Les phases de projet: • Analyse fonctionnelle (1 an) • Architecture (6 mois en parallèle) • Cycles de développement et release (de 3 mois à 2 semaines en mode BDD) 6
- 7. Contexte projet Le système : 7 Validation - Contrôle (Android) Vente - Distribution (Web service) Paramétrage et supervision (back office node JS)
- 8. Contexte projet Organisation Parkeon: Management 1 Directeur de Projet 5 Chefs de Projet 1 x Design Authority 2 Architectes 4 Product Owners 4 x Équipe de Développement : 1 Team Leader / Kanban Master 1 Testeur 5-6 Développeurs 2 x Équipe de test 5-6 Testeurs 8
- 9. Au fait c’est quoi BDD? 9
- 10. Behavior Driven Development en un clin d’oeil • Créer une compréhension partagée du système avec des exemples • Basé sur un langage métier commun • Définition du stop • Lorsque que les tests/exemples sont automatisés, ils deviennent la spec vivante. 10
- 11. Story vue par le métier 11 Métier Ce que je veux
- 12. Story vue par le développeur 12 MétierDéveloppeur Ce que j’ai compris et développe
- 13. Story vue par le testeur 13 MétierDéveloppeurTesteur Ce que j’ai compris et teste
- 14. Ce que l’on va réellement faire 14 MétierDéveloppeurTesteur Un contrat basé sur des exemples
- 15. Une fois les exemples/tests exécutés 15 Spécification vivante
- 16. Pourquoi avoir choisi l’approche BDD? 16
- 17. Enjeux de Management de projet • Définir une méthode applicable à tous les archétypes d’équipes • Favoriser un découpage fonctionnel basé sur la valeur et projetable sur un planning • Maximiser l’automatisation des tests 17
- 18. Enjeux de Maintenance • Assurer une qualité de service continue avec une équipe (très) réduite • Faciliter la transmission des connaissances • Fournir un framework pour développer des nouvelles fonctionnalités 18
- 19. Le déploiement du BDD étape par étape 19
- 20. Test des sous systèmes de façon autonome 20 Artefacts : mockups simulateurs sondes Difficultés: uniformiser le dictionnaire de donnée (vocabulaire) limiter le nombre de steps limiter le nombre d’implémentations pour 1 step ne pas perdre le fil avec l’exigence initiale (traçabilité et sémantique) • La Design Authority définit les comportements en relation avec le client • Les PO et Développeurs les formalisent en BDD et développent ces comportements • Les équipes de Testeurs implémentent les étapes de test et enrichissent la librairie de l’automate • Une fois implémentés, les tests sont planifiés dans l’intégration continue
- 21. Test d’intégration et de bout en bout 21 • Les Développeurs réutilisent les étapes de test définies précédemment pour chaque module afin de les intégrer 2 à 2 (avant livraison interne) • Les équipes de test font de même, sur l’ensemble du système, pour réaliser une intégration bout en bout (après livraison interne) • Ces tests sont planifiés dans une intégration continue transverse Artefacts : simulateurs sondes robots Difficultés: limiter la dépendance avec un état initial du système prendre en compte la volumétrie du système en production
- 22. Validation du système 22 • Les équipes de test et la DA définissent des scénarios qui vont mettre en jeu des cycles de vie “métiers” (je suis administrateur, je suis conducteur, ...) • Ces tests sont exécutés pour la plupart manuellement (mais rapidement) • Les tests “voyageurs”, les plus critiques, sont néanmoins tous automatisés • Cette base de tests sert aussi aux démo réalisées avec le client Artefacts : sondes robots Difficultés: prouver la couverture des exigences limiter la dépendance avec un état initial du système interactions «physiques» avec le système
- 23. Synthèse 23 Toutes les équipes ont participé à la réalisation d’un objectif commun : construire une bibliothèque et un automate de tests leur permettant de valider l’ensemble du système Le BDD a donné un cadre au contrat qui les liait La démarche a été perçue avec enthousiasme par les équipes, sans contrainte. Elle a l’avantage de mettre en avant la valeur humaine et de favoriser les échanges.
- 25. Langage commun spécifique au métier Testeur 我希望我可 以混合颜色 function(c1, c2) { if (c1==c2) { return c1; } else { … } }; Expert métier Développeur Given the color red and the color green when you mix the colors then you obtain yellow 25
- 26. Syntaxe Gherkin Given : Étant donné un état When : Lorsqu’une action est effectuée Then : Une conséquence est constatée 26
- 28. Être consistant dans la terminologie 28 Autocomplete
- 29. Refactoring continu des tests 29 Détection des duplications pour créer un seul point de maintenance
- 30. Refactoring continu des tests 30 Propagation automatique des modifications sur le langage métier
- 31. Processus outillé 31 1- Détailler les stories 2 - Raffiner les cas de tests 3 - Implémenter les stories et tests 4 - Orchestrer les builds et tests runs 5 - Exécuter les tests Résultats
- 32. Automatisation et check (BDD) 32 1635 tests fonctionnels unitaires 990 tests d’intégration sous systèmes 475 tests d’intégration système 200 tests de validation métiers Langage métier: 1690 steps
- 33. Conlusion 33
- 34. Investissement en test 34 Répartition des coûts de développement
- 35. Respect du calendrier 35 Cohésion du planning: • Par rapport aux engagements pris, le plus gros décalage de livraison a été d’une semaine • Aucun déscopage fonctionnel n’a été réalisé pour tenir le planning • Environ 10% de fonctions (sur 800) ont pu être modifiées/ajoutées en parallèle du développement initial.
- 36. Répartition des défauts par phase 36 Gain sur la qualité du système délivré
- 37. Répartition des défauts par domaine 37 Facilité d’intégration du BDD et défauts Clients ● Équipements ○ Intégration compliquée ○ Fonctionne en mode produit pour plusieurs projets. ○ Pas de testeur dans l’équipe ● Back Office ○ Adhésion forte ○ Mais 3 équipes différentes ○ et «out sourcées» ● Serveur de Vente ○ Adhésion très forte ○ 1 équipe locale
- 38. Questions ? 38