Le pilotage des développements par les tests d’acceptation reste un problème difficile à maîtriser dans les projets agiles. D’une part, il est compliqué d’impliquer les analystes métier dans la réalisation de scripts de tests automatisés, et d’autre part les tests de hauts niveaux qu’ils peuvent produire sont souvent difficiles à maintenir et automatiser. L’approche proposée, supportée par une plate-forme appelée Zest, associe la définition des scénarios de tests d’acceptation sur la base d’un DSL (Domain-Specific Language) construit incrémentalement avec des mots d’action, et des fonctions de refactoring qui permettent en permanence d’optimiser les scénarios pour en faciliter l’automatisation et leur maintenance.

2. Laurent PY
Accélérer les tests d’acceptation
en projet agile avec un DSL
et du Refactoring

3. MERCI À NOS SPONSORS

4. Accélérer les tests d’acceptation
en projet agile avec un DSL et du Refactoring
 Introduction
 Développement piloté par les tests d’acceptation
 DSL et refactoring pour les tests d’acceptation
 Retour d’expérience Availpro

5. Introduction

6. Jadis, le développement chez Smartesting…
 Cycle en V
 Pas de TDD
 Release = 1/6mois
 Phase de test = 5 mois
 Qualité faible

7. Puis, introduction des méthodes agiles…
 XP puis Scrum
 TDD, Pair programming
Intégration continue
 Release = 1/3mois
 Phase de test = 1 mois
 Qualité améliorée

8. Et depuis 2012, DevOps !
 Srum
 TDD + ATDD 100% + Test exploratoire
 Déploiement continue
 Plusieurs déploiements en prod/jour
ATDD + TDD = Projets livrés 31% plus vite avec 4 fois moins de défauts

9. Définition de critères
d’acceptation ATTD/BDD
Notre retour d’expérience
Définition
du besoin
Gestion
des
anomalies
Automatisation
massive
Execution
Test
Planning
Itérer rapidement nécessite
du refactoring de tests

10. Le développement piloté
par les tests d’acceptation

11. Scrum et le test d’acceptation
Test
d’acceptation
+

12. • Un outil de communication basé sur un DSL
• La définition du ‘STOP’
• Ecrit par le Tester avant le développement
& validé par l’équipe projet
• Très souvent automatisé
Acceptance Testing Driven Development (ATDD)
Code
Test fixture
Test language naturel
Le test c’est :

13. Acceptance Testing Driven Development (ATDD)
 Bénéfices
Collaboration & Communication
Compréhension partagée
Couverture besoins métiers
Feed-back rapide
…
 Challenges
Nouvelle méthode = rigueur et discipline
Equilibre personne/processus/outils

14.  Tests d’acceptation = continuellement revus et refactorés, comme le code!
ATDD & Refactoring
Martin Fowler

15. Utilisation d’un DSL et du refactoring
pour les tests d’acceptation

16. Test d’acceptation en continu

17.  Fonctionnalités clés :
Conception : Définition progressive d’un DSL
Maintenance : Refactoring & optimisation
Scripts pour l’automatisation
 Intégrations actuelles avec :
Zest: test agile dans le Cloud!
Agile Management Framework d’automatisationAgile Testing

18.  Collaboration autour du test
Zest: test agile dans le Cloud!
Testeur
Définit les tests
d’acceptation
Product Owner
Valide les tests
d’acceptation
Développeur
Automatise les tests
d’acceptation

19. Construire de nouvelles entités métiers…

20. …ou construire les entités métiers à partir des tests
Définition progressive du dictionnaire métier (Action Word).
Collaboration autour des tests entre : métier, test et dév.

21. Réutiliser, réutiliser, réutiliser !
Permet de construire et maintenir des scénarios de tests
consistants pour tout le projet
Propositions

22. La preuve en
image !

23. Ajouter, supprimer, modifier des mots d’action
Le refactoring permet de gérer automatiquement les
impacts liés aux évolutions permanentes.
Ajout d’un paramètre au mot d’action
Propagation automatique
aux scénarios l’utilisant

24. Le diable DUPLICATION

25. Un principe fondamentale du développement/test

26. Analyser et optimiser le plan de tests en continu
Réduction de l’effort de maintenance

27. Générer les Scripts
L’utilisation de mots d’action réduit significativement le coût de
l’automatisation et accélère le cycle de test

28. La preuve en
image !

29. Conclusion
Tests d’acceptation maintenables
Fonctions de refactoring & optimisation
pour gérer les impacts liée aux évolutions
Tests d’acceptation automatisables
La structuration et le design des scénarios
facilitent la création de scripts de tests
Tests d’acceptation lisibles
La définition d’un DSL métier facilite
l’alignement de l’équipe autour des tests

30. Retour d’expérience
projet Availpro

31. Solution et technologies
v4.5
v4.0
Expérience Availpro

32.  1 déploiement en production toutes les 2 semaines
 3 campagnes de test lancées par jour
 En moyenne, 3 nouveaux cas de tests créés par jour
 1200 tests gérés avec Zest
 Aujourd’hui, plus de 80% des cas de tests sont sous Zest
Quelques chiffres
Expérience Availpro

33. Bénéfices du déploiement de Zest
Expérience Availpro

34. Conclusion
Les tests d’acceptation doivent
être continuellement revus et
refactorés tout comme le code!

35. Questions / Réponses

36. Laurent PY
CEO, Smartesting
Laurent.py@smartesting.com
@py_laurent
www.smartesting.com