Laurent Bristiel
18/09/2012
Développement logiciel
en méthode agile
Agenda

Qui suis-je ?

De quoi parle-t-on au juste ?

Agilité

Tests

Bilan
Qui suis-je ?

Ingénieur logiciel chez Fermat/Moody's de
2004 à 2012
− Responsable d'une équipe de testeurs
− Contexte : éditeur, bancaire, agile

Embauché chez Forgerock depuis 2 jours
− Mission semblable mais contexte différent
Développement logiciel
en méthode agile ?

Développement
− Spécification
− Programmation
− Tests

Logiciel
− Traditionnel (application)
− Soft As a Service (web)
− App (smartphone)

Méthodes
− Cow-boy
− Cascade
− Cycle en V
− Agile
− Open Source (bazar)
2001
Agile = scrum + XP

Scrum : méthode de gestion de projet
− Populations : product manager, dev, scrumMaster
− Outils : stories, itérations, backlog, board, post-it
− Réunions : planning, daily, démo, rétro

XP = Extrem Programming : méthode dév

Intégration continue, feedback loop

Pair-programming, propriété collective

TDD, tests fonctionnels
Agile aujourd'hui

Facebook, Ebay, Google...
− Livraison permanente

« Lean Startup »
− Création startup en continu

Communauté importante à Grenoble
− Yahoo, Kelkoo, Samse, Orange, EDF, Moody's...
− 2012 : 5e
conférence « Agile Grenoble »
(500 personnes, 40 sessions)
Agile chez Moody's

7 équipes de 10 personnes (PM, Prog, Testeurs)

Ratio Testeurs/Prog : 1/2

Releases de 3 mois, itérations de 2 semaines

Succès
− Capacité à réagir (réglementation, marché etc.)
− équipes (re)motivées et plus solides
− Meilleure transparence et predictabilité

Difficultés
− Équipes distribuées
− Agilité limitée à la R&D
− Logiciels vieillissants
Zoom sur les tests
(en Agile / chez Moody's)

Pour toute nouvelle version
− Les nouvelles fonctionnalités doivent marcher
− Les corrections de bugs doivent être effective
− Rien ne doit avoir été cassé (effets de bord)

2 activités de tests
− Tests de validation
− Tests de non regression
Types de tests

Tests unitaires
− Tests techniques faits par le programmeur sur le
code source (tests boite blanche)

Tests de composants
− Tests technico-fonctionnels faits par programmeur
ou testeur sur un service (boite grise)

Tests end-2-end
− Tests fonctionnels fait par testeur ou product
manager sur le système complet (boite noire)
Tests de validation

Tests collectifs, au plus tôt et en continu

Collaboration programmeur, testeur et PM

Calcul des attendus théoriques (oracle)

Programmeur : Test unitaires et TDD

Testeurs : production de test cases
(composants, E2E)
+ tests exploratoires

Important :
− on ne teste pas tout
− Il y a aura des bugs
Tests de non régressions

Risques de régressions ?

Tests de non régressions : somme de tous les tests de
validation du passé => croissance infinie

Fréquence des tests de NR : aussi souvent que possible
(coût bug, intégration continue..)

Méthodes de tests :
− Manuels : simple mais long (offshoring ?)
− Automatique : compliqué mais rapide (expertise)

Important :
− On ne reteste pas tout (évaluation de risques)
− Il n'y aura pas forcément de régression
Pyramide idéale
des tests automatisés
Bilan de 8 ans de tests

Les régressions sont le réel enjeu (progiciel)
− « on a le droit à l'erreur, mais une seule fois »

Difficulté à faire comprendre la pyramide
− « montrez-moi vos tests ! »

Cas particulier des tests d'interface graphique
− « comment vous avez pu rater ça ? »

Bug du 29 février 2008
− « on a eu chaud »
Bilan de 8 ans de tests

Métier passionnant en méthode agile
− véritables enjeux d'ingénierie logicielle
− métier peu connu et reconnu

Frustration sur le contexte
− C++/Oracle/licence versus Java/Web/OpenSource
Des questions ?

Développement en méthode agile

  • 1.
  • 2.
    Agenda  Qui suis-je ?  Dequoi parle-t-on au juste ?  Agilité  Tests  Bilan
  • 3.
    Qui suis-je ?  Ingénieurlogiciel chez Fermat/Moody's de 2004 à 2012 − Responsable d'une équipe de testeurs − Contexte : éditeur, bancaire, agile  Embauché chez Forgerock depuis 2 jours − Mission semblable mais contexte différent
  • 4.
    Développement logiciel en méthodeagile ?  Développement − Spécification − Programmation − Tests  Logiciel − Traditionnel (application) − Soft As a Service (web) − App (smartphone)  Méthodes − Cow-boy − Cascade − Cycle en V − Agile − Open Source (bazar)
  • 5.
  • 6.
    Agile = scrum+ XP  Scrum : méthode de gestion de projet − Populations : product manager, dev, scrumMaster − Outils : stories, itérations, backlog, board, post-it − Réunions : planning, daily, démo, rétro
  • 7.
     XP = ExtremProgramming : méthode dév  Intégration continue, feedback loop  Pair-programming, propriété collective  TDD, tests fonctionnels
  • 8.
    Agile aujourd'hui  Facebook, Ebay,Google... − Livraison permanente  « Lean Startup » − Création startup en continu  Communauté importante à Grenoble − Yahoo, Kelkoo, Samse, Orange, EDF, Moody's... − 2012 : 5e conférence « Agile Grenoble » (500 personnes, 40 sessions)
  • 9.
    Agile chez Moody's  7équipes de 10 personnes (PM, Prog, Testeurs)  Ratio Testeurs/Prog : 1/2  Releases de 3 mois, itérations de 2 semaines  Succès − Capacité à réagir (réglementation, marché etc.) − équipes (re)motivées et plus solides − Meilleure transparence et predictabilité  Difficultés − Équipes distribuées − Agilité limitée à la R&D − Logiciels vieillissants
  • 10.
    Zoom sur lestests (en Agile / chez Moody's)  Pour toute nouvelle version − Les nouvelles fonctionnalités doivent marcher − Les corrections de bugs doivent être effective − Rien ne doit avoir été cassé (effets de bord)  2 activités de tests − Tests de validation − Tests de non regression
  • 11.
    Types de tests  Testsunitaires − Tests techniques faits par le programmeur sur le code source (tests boite blanche)  Tests de composants − Tests technico-fonctionnels faits par programmeur ou testeur sur un service (boite grise)  Tests end-2-end − Tests fonctionnels fait par testeur ou product manager sur le système complet (boite noire)
  • 12.
    Tests de validation  Testscollectifs, au plus tôt et en continu  Collaboration programmeur, testeur et PM  Calcul des attendus théoriques (oracle)  Programmeur : Test unitaires et TDD  Testeurs : production de test cases (composants, E2E) + tests exploratoires  Important : − on ne teste pas tout − Il y a aura des bugs
  • 13.
    Tests de nonrégressions  Risques de régressions ?  Tests de non régressions : somme de tous les tests de validation du passé => croissance infinie  Fréquence des tests de NR : aussi souvent que possible (coût bug, intégration continue..)  Méthodes de tests : − Manuels : simple mais long (offshoring ?) − Automatique : compliqué mais rapide (expertise)  Important : − On ne reteste pas tout (évaluation de risques) − Il n'y aura pas forcément de régression
  • 14.
  • 15.
    Bilan de 8ans de tests  Les régressions sont le réel enjeu (progiciel) − « on a le droit à l'erreur, mais une seule fois »  Difficulté à faire comprendre la pyramide − « montrez-moi vos tests ! »  Cas particulier des tests d'interface graphique − « comment vous avez pu rater ça ? »  Bug du 29 février 2008 − « on a eu chaud »
  • 16.
    Bilan de 8ans de tests  Métier passionnant en méthode agile − véritables enjeux d'ingénierie logicielle − métier peu connu et reconnu  Frustration sur le contexte − C++/Oracle/licence versus Java/Web/OpenSource
  • 17.