Développement guidé par les tests d acceptation (ATDD/BDD) au Ministère de la défense nationale Un retour d expérience Martin Lalonde, M.Sc
Survol Introduction Un exemple concret Défis et Solutions Obtenir l approbation du PO Comment bien commencer le développement? Comment les tests peuvent-ils guider le développement? Comment écrire un scénario? Les tests de bout en bout Conclusion
L organisation Ministère de la défense nationale Organisations des cadets du Canada L équipe de Forteresse Scrum 11 membres 7 développeurs 1 dba, 1 architecte/sm, 1 infrastructures, 4 développeurs génériques 1 analyste d affaire 1 responsable du soutien aux utilisateurs 1 adjointe au gestionnaire de projet 1 gestionnaire de projet (PO)
L application Forteresse Bilingue Pancanadienne Environ 3000 utilisateurs actifs D un point de vue technique Programmée en Asp.Net C# En production depuis septembre 2010 + de 250 tables + de 200 pages web Exécutée sur un serveur IIS avec une BD SqlServer
Introduction Pourquoi?
Introduction - pourquoi? Nous introduisons trop de bogues Malgré + de 4000 tests unitaires et d intégration Code de la vue difficile à tester Code du UI très fragile Tests manuels Aucun test Automatisé UI Integration Type de tests couvert à 55% Unit Quantité
Introduction - pourquoi? Augmenter la collaboration entre les acteurs du projet Construire une compréhension partagée Utiliser et diffuser le langage métier partout Élaborer/raffiner une solution/design Comprendre le «Afin de» et les «critères d acceptation» de la même façon Développeurs Expert du domaine / Client PO
Introduction - pourquoi? Livrer le bon produit tests unitaires : le comment tests d acceptation : le quoi Logiciel bien programmé (le comment) Échec d affaire Succès Useless Crap Cauchemar de maintenance Programmer le bon logiciel (le quoi) Traduction libre de la figure 1.1 tirée du livre Specification by Example de Gojko Adzic
Introduction - pourquoi? Avoir de la documentation toujours fiable Aussi appellée documentation vivante elle évolue tout le temps! Toujours à jour Vérifiée sur le code de production Très attrayant en théorie
Introduction - pourquoi? Synthèse des objectifs 1) Diminuer le nombre de bogues introduis 2) Augmenter notre collaboration 3) Livrer le bon produit 4) Avoir de la documentation vivante
Plan Introduction Un exemple concret Défis et Solutions Obtenir l approbation du PO Comment bien commencer le développement? Comment les tests peuvent-ils guider le développement? Comment écrire un scénario? Les tests de bout en bout Conclusion
Un exemple concret Modèle BDD o Outil SpecFlow (équivalent de Cucumber) o Langage Gherkin o Alternative sérieuse envisagée : Fitnesse Écrit en anglais o parce que la majorité de nos utilisateurs sont anglophones Écrit selon le même format que les tests unitaires o A-A-A Arrange-Act-Assert Given-When-Then
Un exemple concret Fichier.Feature Tag Step Feature: Promoting a cadet (Attribuer un grade) @pbi123 Scenario : Promote cadet from Master Corporal to Sergeant Given a cadet in an army cadet corps And the cadet current rank is Master Corporal When I promote the cadet Then the cadet s current rank becomes Sergeant
Un exemple concret [Binding] public class PromotingACadetSteps : FortressTestBase { [Given(@"a cadet in an army cadet corps")] public void GivenACadetInAnArmyCadetCorps() { var cadetcorps = CreateArmyCadetCorps(); ScenarioContext.Current.Set(CreateCadet(cadetCorps)); } [Given(@"the cadet current rank is Master Corporal")] public void GivenTheCadetCurrentRankIsMasterCorporal() { var cadet = ScenarioContext.Current.Get<CadetEntity>(); cadet.currentrank = RankEnum.MasterCorporal; Save(cadet); }
Un exemple concret [When(@"I promote the cadet")] public void WhenIPromoteTheCadet() { var cadet = ScenarioContext.Current.Get<CadetEntity>(); new FortressNavigation().CadetPromotionHistoryPage(cadet ).PromoteCadet(); } [Then(@"the cadet s current rank becomes Sergeant")] public void ThenTheCadetSCurrentRankBecomesSergeant() { var cadet = ScenarioContext.Current.Get<CadetEntity>(); var currentrank = ServiceFactory.PromotionService.GetCadetCurrentRank(cadet); Assert.That(currentRank, Is.EqualTo(RankEnum.Sergeant)); }
Plan Introduction Un exemple concret Défis et Solutions Obtenir l approbation du PO Comment bien commencer le développement? Comment les tests peuvent-ils guider le développement? Comment écrire un scénario? Les tests de bout en bout Conclusion
Défis et solutions Obtenir l approbation du PO Pourquoi il fallait avoir l approbation du PO? On change la définition de terminé On ajoute des tests d acceptation automatisés Peut diminuer la vélocité à court terme
Défis et solutions Obtenir l approbation du PO Comment obtenir son approbation? Choisir un PO ouvert d esprit et orienté sur la qualité Arriver bien préparé, crédible et motivé Expliquer les objectifs visés et les bénéfices potentiels mais aussi les risques (de ne pas le faire) Discuter des investissements nécessaire en temps et en argent (transparence) Laisser du temps Choisir le bon moment Quand c est le temps de livrer une fonctionnalité critique Quand on ne peut faire de compromis sur la qualité
Défis et solutions Comment avons-nous commencé le développement? ex: Un kata (exercice) d écriture de scénarios en groupe Se faire des ententes de travail Langue de rédaction Format de dates Classement des fonctionnalités Utilisation des tags Stratégie de test (qu est-ce qu on teste? UI? Service? Contrôleur?) N implémenter que les scénarios Happy Path au début Se donner du temps Faire beaucoup de travail en binômes Nommer un champion du projet
Défis et solutions Les premières ententes de travail Réunions Courriels de synthèse des réunions Faire respecter les ententes Par la programmation en binômes Par la revue de code
Défis et solutions Comment les scénarios guident-ils notre développement? Nous ne pouvons demander au client ou aux experts d écrire les scénarios Formation trop longue Experts trop nombreux (+50) Experts partout au Canada Experts changent en fonction du processus Analyste est l expert
Défis et solutions Comment les scénarios guident-ils notre développement? Le développeur écrit les scénarios en collaboration avec l analyste et le PO. Cela guide le développement de la manière suivante : La première tâche d un PBI est le test d acceptation Le «Afin de» et les «critères d acceptation» des User Stories sont clarifiés Les discussions clarifient le langage métier à utiliser Raffiner une solution en collaboration avec l analyste
Défis et solutions Comment écrire un scénario de manière claire? Exercice
(1) Scenario: Reactivating a cadet in different cadet corps can edit results Given an army cadet corps named firstcadetcorps And a cadet in firstcadetcorps And cadet membership in firstcadetcorps is terminated And an army cadet corps secondcadetcorps When reactivating the cadet in secondcadetcorps Then Performance Objective Results should be editable by his new cadet corps (2) Scenario: Reactivating cadet in different cadet corps can edit results Given a cadet in an army cadet corps with a newly terminated membership When reactivating the cadet in another army cadet corps Then Performance Objective Results should be editable by his new cadet corps
Défis et solutions Comment écrire un scénario de manière claire? On dit qu un bon test doit être : Facile à lire Facile à maintenir Digne de confiance Sauf que... Ce sont des critères subjectifs! Ça peut générer des discussions sans fin
Défis et solutions Comment écrire un scénario pertinent? Qu est-ce qu on teste? À quel niveau conceptuel écrit-on les scénarios? En terme d éléments de l interface graphique? En langage du métier? La configuration de l application (données de référence) Exemple de Catégories d activités et le type de participant
Défis et solutions Comment écrire un scénario de manière conçise? Scenario Outline et tables de décision Qu est-ce qu une table de décision? exemple : aussi appelée table de vérité The user will be allowed to take attendance depending when the serial is happening, Can take attendance depending when serial is happening happening ongoing in the past in the future allowed? allowed allowed not allowed
Défis et solutions Comment écrire un scénario de manière conçise? Scenario Outline et tables de décision Qu est-ce qu un Scenario Outline? Scenario Outline: Can take attendance depending when serial is happening Given a serial that is <happening> When taking the attendances Then operation is <allowed> Examples: happening allowed ongoing allowed in the past allowed in the future not allowed
Défis et solutions Comment écrire un scénario de manière conçise? Scenario Outline et tables de décision Nous avons préféré le format en langage naturel Avec la structure Given-When-Then Nous trouvons que les tables de décision sont plus difficile à comprendre C est une des raisons pour laquelle nous sommes allés vers le BDD et l outil Specflow Encore une fois : c est subjectif! Malgré cela, il n est pas exclu d utiliser les Scénario Outline : Scénarios plus conçis Moins de duplication Particulièrement pertinent pour énumérer des exemples (!)
Défis et solutions Autres défis Le piège de l outil SpecFlow et de l intellisense Réutilisation des steps SpecFlow Divers problèmes de maintenance Duplication Manque de rigueur Ne pas traiter le code des tests avec le même respect que le code de production Ne pas remodeler assez souvent
Défis et solutions Autres défis Utilisation des tags Exclusions @WebTest, @NotImplemented, @InProgress Aide à la recherche @pbi#, @bug# Catégories/classement @HappyPath Différencier/Exécution différentes @ScenarioUsingReadCommittedTransaction, @WebTest,...
@HappyPath @WebTest @pbi25588 Scenario : Cadet selection on a serial Given a serial in the future And context unit is MyRcsu When selecting the cadet Then the cadet is selected And the participation offer is ready to be sent to the cadets corps/sqn @NotImplemented @pbi25588 @ScenarioUsingReadCommittedTransaction Scenario : Cadet selection to a serial after being SOSed from a different serial Given a serial that is not finished And a cadet TOS on that serial And cadet is struck of strength today When selecting the cadet on different serial tomorrow Then cadet is selected
Défis et solutions Les tests de bout en bout peuvent nous aider à nous protéger contre la régression réduire le QA manuel avant livraison augmenter la confiance dans notre code livrer plus souvent livrer plus vite
Défis et solutions Tests de bout en bout Par programmation Choix du cadre applicatif Sélénium Telerik Microsoft Performance Web Test Watin Autre
Défis et solutions Tests de bout en bout 65 fichiers.feature en date du 1er octobre 67 scénarios de bout en bout sur + 300 scénarios L application compte entre 400 et 600 fonctionnalités 10-15% des fonctionnalités sont couvertes À cause de la répartition de la couverture Presque 100% des nouvelles fonctionnalités Ne pas confondre avec la couverture de code
Défis et solutions Temps d exécution des tests +300 tests +60 de bout en bout +8 minutes et ça monte vite!
Défis et solutions Pourquoi est-ce un problème? Solutions? Temps de rétroaction trop long Expérience traumatisante de déboggage S assurer de seulement tester le HappyPath Pas de Scénario Outline de bout en bout Mettre en place le contexte du test par la base de données Séparer en plusieurs projets/builds
Défis et solutions Fragilité des tests de bout en bout Ajax JavaScript Popup Problème non résolu Baisse de confiance Coûts de maintenance augmentent Aurions-nous eu les mêmes problèmes avec des tests enregistrés? On dit que :? Plus difficile à comprendre Plus coûteux à maintenir
Défis et solutions Documentation vivante Peu utilisée mais c est parce que... Nous avons seulement des scénarios sur des fonctionnalités récentes (frais en mémoire) Faible taux de roulement des employés Confiance qu elle sera utilisée davantage car... Nouveau bug corrigé = nouveaux scénarios Nous ne sommes pas encore en phase maintenance Pickle pour les non-programmeurs Pratiquement jamais utilisé
Conclusion Objectifs 1) Diminuer le nombre de bogues introduis 2) Augmenter notre collaboration 3) Livrer le bon produit 4) Avoir de la documentation vivante
Conclusion Diminuer le nombre de bogues introduis Oui, nous avons réussi Nous avons plus confiance dans notre code et nous livrons plus rapidement et plus souvent
Conclusion Plus de collaboration Oui nous collaborons plus... On ne s est jamais aussi bien compris pour livrer ce qui était attendu, et la pratique du BDD y est forcément pour quelque chose.
Conclusion Livrer le bon produit Oui nous savons que nous livrons mieux le bon produit... L équipe est d accord pour dire que nous livrons mieux ce que l analyste d affaire demande dans les tests Nous ne savons pas si nous livrons mieux ce que le client demande mais nous travaillons présentement à régler ce problème
Conclusion Avoir de la documentation vivante Oui nous en avons mais... elle n est pas encore très utilisée mais tout porte à croire qu elle le sera.
Conclusion Globablement : succès! On continue Merci! Question, commentaires, avis à partager? martin.lalonde@ursce.cadets.gc.ca