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.

1. Alignement avec les métiers par
le test fonctionnel et
d’acceptation en projets agiles

2. Laurent PY
CEO, Smartesting
Laurent.py@smartesting.com
@py_laurent
www.smartesting.com
Guillaume Coquelle
Testeur, Availpro
Guillaume.coquelle@availpro.com
www.availpro.com

3. Smartesting en 30 secondes

Editeur de logiciel de test créé en 2003

Sites : Besançon, Paris et Bangalore (Inde)

Notre ADN : Nous croyons au test comme patrimoine de connaissance de
l'entreprise et comme vecteur d’efficacité et d'alignement entre les
différentes parties prenantes d'une organisation

Clients & Partenaires :

4. Introduction

5. Processus de développement chez Smartesting 2004/06

Développement - cycle en V
– Peu de tests fait par les développeurs (pas de TDD)
– 1 release chaque 6 mois
– 1 mois (x5 ingénieurs) pour faire du ‘release testing’
avant déploiement
– Niveau de qualité faible impactant nos clients et retours
négatifs
5

6. Introduction des méthodes agiles - 2006

Développement agile
– Scrum, TDD, Pair programming
– Mise en place de l’intégration continue
– 1 release client chaque 3 mois (une opérationnelle chaque 3
semaines)
– 1 mois/homme pour faire du ‘release testing’ avant déploiement
– Bon niveau de qualité
6

7. Plate-forme de test agile dans le cloud - 2012

DevOps
– Déploiement continue  agilité métier
– Plusieurs releases par jour!
– Acceptance Testing Driven Development (ATDD), 100% automatisé…
– … complété par du test exploratoire
Avec les pratiques ATDD et TDD, les projets sont livrés 31% plus vite et
avec 4 fois moins de défauts
http://www.thucydides.info/blog/295-does-atdd-really-save-you-time
7

8. Notre retour d’expérience

Les méthodes agiles conduisent à des itérations
courtes (1 à 4 semaines) et une automatisation massive
des tests

La chaine de valeur est compressée ⇒
test d’acceptation = spécification

Le test démarre en amont ou en parallèle des
développements: Shift left !!!
Req
Management
& Definition
Test
Planning
Execution
Defect
management
8

9. Notre retour d’expérience

Les propriétés clés des tests d’acceptation pour
itérer rapidement :
– Lisibles pour faciliter la communication et permettre
le ‘shift left’
– Maintenables aisément pour gérer les impacts des
évolutions et nouvelles fonctionnalités
– Automatisables pour une exécution rapide
9

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

11. Le test et les projets agiles
How Can You Scale Your Agile Adoption? Diego Lo Giugice, Forrester (Fev. 2014)

12. Scrum et le test d’acceptation
Tests d’acceptation
Shift left
Tests d’acceptation
Équipe Scrum
PO
Développeurs
testeurs
Scrum
master

13. Acceptance Testing Driven Development (ATDD)

Le test d’acceptation est un outil de communication

Il est la définition du ‘STOP’

Ecrits par le Tester avant le développement

Basés sur un DSL (Domain Specific Language)

Validés par l’équipe projet

Très souvent automatisés
Test en language naturel
Test fixture
Code

14. Acceptance Testing Driven Development (ATDD)

Bénéfices
– Améliore la collaboration et communication autours des tests
d’acceptation
– Compréhension partagée de ce que signifie implémentation
réussie
– Meilleure couverture des besoins métiers
– Feed-back plus rapide

Challenges:
– Nouvelle méthodologie nécessitant rigueur et discipline
– Trouver le bon équilibre personne/processus/outils

15. ATDD & Refactoring
Les tests d’acceptation doivent être
continuellement revus et refactoré
tout comme le code!
Martin Fowler

16. Test d’acceptation en continu

17. Zest: test agile dans le Cloud!

Fonctionnalités clés:
–
–
Suggestion pour faciliter la réutilisation de mots d’action et limiter la duplication
–
Refactoring: la modification de mots d’action métier impacte automatiquement l’ensemble
des scénarios de test
–
Optimisation: Des fonctions d’inspection permettent d’optimiser en permanence les tests
–

Définition progressive des mots d’actions métier, permettant de créer un DSL (Domain
Specific Language) pour l’ criture des scénarios de test
Création de scripts pour l’automatisation (Ruby, Java, XML…)
Intégrations actuelles avec:
17

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

19. Construire de nouvelles entités métiers…
Définition progressive du dictionnaire métier (Action
Word). Collaboration autour des tests entre le métier, les
testeurs et développeurs

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 le métier, les
testeurs et développeurs

21. Le diable DUPLICATION

22. Un principe fondamentale du développement/test

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

24. Analyser et optimiser le plan de tests en continu
Subject
Testing BOOKSTORE
Testing BOOKSTORE
Testing BOOKSTORE
Testing BOOKSTORE
Testing BOOKSTORE
Testing BOOKSTORE
Testing BOOKSTORE
Testing BOOKSTORE
Testing BOOKSTORE
Testing BOOKSTORE
Testing BOOKSTORE
Testing BOOKSTORE
Testing BOOKSTORE
Testing BOOKSTORE
Testing BOOKSTORE
Testing BOOKSTORE
Testing BOOKSTORE
Testing BOOKSTORE
Testing BOOKSTORE
Test Name
A selection can be cancelled
A selection can be cancelled
A selection can be cancelled
A selection can be cancelled
A selection can be cancelled
Buy many books
Buy many books
Buy many books
Buy many books
Buy many books
Buy many books
Buy many books
Cart empty when logout
Cart empty when logout
Cart empty when logout
Cart empty when logout
Cart empty when logout
Cart empty when logout
Cart empty when logout
Status
Imported
Imported
Imported
Imported
Imported
Imported
Imported
Imported
Imported
Imported
Imported
Imported
Imported
Imported
Imported
Imported
Imported
Imported
Imported
Step Name
Step 1
Step 2
Step 3
Step 4
Step 5
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Description
Log with default account
Go to on-line library
Select the book Harry Potter and the order of the phoenix
Add to cart
Cancel cart
Log with default account
Go to on-line library
Select the book Harry Potter and the order of the phoenix
Add to cart
Select the book Harry Potter and the goblet of fire
Add to cart
Pay
Log with default account
Go to on-line library
Select the book Harry Potter and the order of the phoenix
Add to cart
logout
Log with default account
Go to on-line library
Expected Result
Check that user is logged
Check that cart contains 1 books
Check that cart contains 0 books
Check that user is logged
Check that cart contains 2 books
Check cart is paid
Check that user is logged
Check that user is logged
Check that cart contains 0 books
Réduction de l’effort de maintenance mesurable
dès la phase d’import

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

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

27. Synthèse
Des tests d’acceptation lisibles
La définition d’un DSL métier facilite
l’alignement de l’équipe autour des tests
Des tests d’acceptation
automatisables
La structuration et le design des
scénarios facilitent la création de
scripts exécutables
Des tests d’acceptation
maintenables
Les fonctions de refactoring et
optimisation accélèrent la gestion des
impacts liée aux évolutions

28. Retour d’expérience
sur le projet Availpro

29. Solution et technologies
v4.0
v4.5

30. Bénéfices du déploiement de Zest

Collaboration de tous les acteurs autour du test: Le partage des scénarios

Collaboration instantanée dans la conception: les scénarios sont visibles
permet aux membres des différentes équipes (développement, MOA, qualité) d’avoir une
vision identique des tests réalisés: alignement par les tests. L’écriture des scénarios peut
dorénavant se faire par tous types individus (technique ou non).
pour toutes les personnes en temps réel. Pas de décalage comme on pourrait avoir avec
des fichiers Excel.

Refactoring: Lors de modifications des fonctionnalités de nos applications, il peut être
nécessaire de modifier / ajouter certains paramètres. Ceci est maintenant nettement plus
rapide car centralisé et automatique. Gain de producitvité de l’ordre de 50%

Intégration avec JIRA Agile : Gestion de la traçabilité entre les issues (user story,

Intégration avec le framework d’automatisation: Aucune modification
tâche) dans JIRA et les scénarios dans Zest. Indication de l’évolution de l’écriture des
scénarios
dans le code robot nécessaire.

31. Questions / Réponses
www.smartesting.com
www.availpro.com