1. Laurent Bristiel
18/09/2012
Développement logiciel
en méthode agile

2. Agenda

Qui suis-je ?

De quoi parle-t-on au juste ?

Agilité

Tests

Bilan

3. 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

4. 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)

5. 2001

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 = Extrem Programming : 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 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

11. 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)

12. 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

13. 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

14. Pyramide idéale
des tests automatisés

15. 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 »

16. 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

17. Des questions ?