Développement guidé par - Agile...

Développement guidé par les tests d’acceptation (ATDD/BDD) au Ministère de la défense nationale

Martin Lalonde, M.Sc

Un retour d’expérience

● 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

Survol

Développement guidé par les tests d’acceptation (ATDD/BDD)

● 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


couvert à

55%

Integration

Unit

Aucun test

Automatisé UI

Quantité

Type de

tests

Tests manuels

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)

Programmer le bon logiciel

(le quoi)

Traduction libre de la figure 1.1 tirée du livre Specification by Example de Gojko Adzic

Succès

Cauchemar de

maintenance

“Useless Crap”

Échec d’affaire

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








● Conclusion


• 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


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

Fichier .Feature Tag Step

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()

{


new FortressNavigation().CadetPromotionHistoryPage(cadet ).PromoteCadet();

}

[Then(@"the cadet’s current rank becomes Sergeant")]

public void ThenTheCadetSCurrentRankBecomesSergeant()

{


var currentRank = ServiceFactory.PromotionService.GetCadetCurrentRank(cadet);

Assert.That(currentRank, Is.EqualTo(RankEnum.Sergeant));

}


Plan


● Introduction








● Conclusion


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 ?

● 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 un PO ouvert d’esprit et orienté sur la qualité

● 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 ? ● Un kata (exercice) d’écriture de scénarios en groupe

● Se faire des ententes de travail

ex: ● 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

Défis et solutions


(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


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 ?

■ aussi appelée table de vérité

○ exemple :

The user will be allowed to take attendance depending when the serial is

happening,

Can take attendance depending when serial is happening

happening allowed?

ongoing allowed

in the past allowed

in the future not allowed

Défis et solutions



○ 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, ...

Défis et solutions


@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


● 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 ?

○ Temps de rétroaction trop long

○ Expérience traumatisante de déboggage

● Solutions ?

○ 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é

Défis et solutions


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 ?

[email protected]

Conclusion

mailto:[email protected]

mailto:[email protected]

Développement guidé par - Agile...

Documents

Transcript of Développement guidé par - Agile...