Acceptance test driven development

1. ACCEPTANCE
TEST
DRIVEN
DEVELOPMENT
(ATDD)
4
octobre
2011

2. Sommaire
u Présenta4on
de
l’ATDD
u Constats
sur
l’industrie
du
test
u Les
grands
principes
de
l’ATDD
u Pour
quels
bénéfices
?
u Retour
d’expérience
u Mme
Bénédicte
Taillebois,
Responsable
des
études
d’ASTRIA
Club
Qualité
Logicielle
-­‐
4
octobre
2011
2

3. -­‐
I
-­‐
Présenta4on
de
l’ATDD

4. Constats
sur
l’industrie
du
test

5. Chiffres
5
50
%
Ra5o
maximum
code
testé
15
%
Bugs
connus
livrés
en
produc5on
40
%
Coût
des
tests

6. Conséquences
u Infla4on
du
coût
et
des
délais
u Fossé
entre
la
qualité
perçue
par
les
u4lisateurs
finaux
et
le
coût
du
test
u Effort
important
sur
les
tests
de
non
régression
souvent
manuels
u Difficulté
à
automa4ser
et
à
maintenir
les
tests
Club
Qualité
Logicielle
-­‐
4
octobre
2011
6

7. Bugs
et
Tests
Club
Qualité
Logicielle
-­‐
4
octobre
2011
7
1.
Specifica5on
2.
Développement
3.
Tests
4.
Bugs
Origine
des
bugs
dans
les
projets
IT
Spécifica4on
Développement
Autre
Résultats?

8. Pourquoi
ne
pas?
u Piloter
les
spécifica4ons
du
logiciel
u et
son
implémenta4on
u par
des
exemples
concrets?
Club
Qualité
Logicielle
-­‐
4
octobre
2011
8

9. ATDD
?
5
principes

10. ATDD
en
pra4que
Club
Qualité
Logicielle
-­‐
4
octobre
2011
10
Partager
une
vision
fonc4onnelle
commune
de
l’applica4on
Ecrire
les
tests
d’acceptance
Automa4ser
les
spécifica4ons
exécutables
Implémenter
le
code
U4liser
les
spécifica4ons
exécutables
comme
une
documenta4on
«
vivante
»
pour
faciliter
le
changement
1
2
3
4
5

11. Club
Qualité
Logicielle
-­‐
4
octobre
2011
11
Expert
mé4er
Développeurs
Testeurs
L’équipe
Grands
domaines
fonc5onnels
de
l’applica5on
Processus
et
workflows
Fonc5onnalités
principales
Vocabulaire
1.
Partager
une
vision
fonc4onnelle
commune
de
l’applica4on

12. 2.
Ecrire
les
tests
d’acceptance
Club
Qualité
Logicielle
-­‐
4
octobre
2011
12
1a.
Le
but
QUI?
QUOI?
POUR
QUOI?
2.
Les
tests
CONTEXTE?
ACTION
?
RESULTATS
?
1b.
Règles
de
ges4on
QUELLE
REGLE
?

13. 3.
Automa4ser
les
spécifica4ons
exécutables
Club
Qualité
Logicielle
-­‐
4
octobre
2011
13
Code
Fixture
Tests
d’acceptanc
e
exécutables
Tests
d’acceptance
automa5sés
Tests
Tests
Tests

14. 4.
Implémenter
le
code
en
fonc4on
des
tests
d’acceptance
Club
Qualité
Logicielle
-­‐
4
octobre
2011
14
1ère
exécu4on
du
TA
KO
Code
Ini5al
FINI
2ème
exécu4on
du
TA
3ème
exécu4on
du
TA
KO
KO
n-­‐ième
exécu4on
du
TA
OK

15. 5.
U4liser
les
spécifica4ons
exécutables
comme
une
documenta4on
‘vivante’
pour
faciliter
le
changement
Ü
Facile
à
écrire
Ü
Facile
à
lire
Ü
Facile
à
changer
Club
Qualité
Logicielle
-­‐
4
octobre
2011
15
Ü
Précis
Ü
Consistant
Ü
Valide
le
logiciel

16. Pour
quels
bénéfices?

17. Manager
:
Pour
quels
bénéfices?
En
tant
que
manager,
je
veux
:
ü
Suivre
l
’avancement
des
développements
avec
des
indicateurs
En
tant
que
manager,
j’ai:
ü Repor4ng
immédiat:
sta4s4ques
tests
OK/test
KO
Ø
Retour
client
:
“Il
était
difficile
d’avoir
des
retours
concrets
des
équipes”
Club
Qualité
Logicielle
-­‐
4
octobre
2011
17

18. Expert
mé4er:
Pour
quels
bénéfices?
En
tant
qu’expert
mé5er,
je
veux
:
ü
Développeurs
comprennent
et
implémentent
correctement
les
besoins
spécifiés
ü
Testeurs
détectent
au
plus
tôt
le
maximum
de
bugs
En
tant
qu’expert
mé5er,
j’ai:
ü
Valida4on
immédiate
du
logiciel
Ø
Retour
client
:
“Les
développeurs
comprennent
mieux
notre
besoin
avec
des
exemples
concrets”
Club
Qualité
Logicielle
-­‐
4
octobre
2011
18

19. Développeur
:
Pour
quels
bénéfices?
En
tant
que
développeur,
je
veux
:
ü
Spécifica4ons
soient
les
moins
ambigües
possible
ü
Pouvoir
valider
mon
code
juste
après
l’avoir
écrit
En
tant
que
développeur,
j’ai
:
ü
Confiance
:
au
code
et
à
l’équipe
ü
Direc4on
bien
définie
Ø Retour
client
:
“Je
sais
quand
m’arrêter”
Club
Qualité
Logicielle
-­‐
4
octobre
2011
19

20. Testeur:
Pour
quels
bénéfices?
En
tant
que
testeur,
je
veux
:
ü
Eviter
de
faire
et
refaire
les
mêmes
tests
ü
Vérifier
les
règles
mé4er
en
un
clic
En
tant
que
testeur,
j’ai
:
ü
“Test
intelligent”
Ø
Retour
client
:
“Nous
pouvons
nous
concentrer
sur
des
tests
plus
complexes
(exploratoires)”
Club
Qualité
Logicielle
-­‐
4
octobre
2011
20

21. -­‐
II
-­‐
Retour
d’expérience
ASTRIA

22. ASTRIA
:
le
contexte
u Projet
de
refonte
de
SI
mé4er
représentant
plus
de
50%
de
l’ac4vité,
évalué
à
10
000
j/h,
entamé
en
juillet
2008
u Passer
d’une
applica4on
monolithique
à
une
architecture
applica4ve
urbanisée
avec
des
référen4els
u Permegre
une
adapta4on
du
programme
de
refonte
à
des
changements
fréquents
dans
le
planning
et
le
périmètre
u Eviter
le
trauma4sme
d’un
big
bang
vécu
en
2005
u Décision
:
développer
en
méthode
agile,
industrialiser
les
développements,
u4liser
les
spécifica4ons
exécutables
u Ou4llage
:
php
et
java,
Greenpepper
Club
Qualité
Logicielle
-­‐
4
octobre
2011
22

23. 3
ans
après
:
des
chiffres
u 60%
de
la
refonte
réalisée
u Processus
de
projets
:
u 1
phase
de
cadrage
u 1
phase
de
développement
u Des
spécifica4ons
exécutables,
automa4quement
(ou
pas)
u 20
applica4ons
en
produc4on
ou
en
développement
u
environ
10
000
tests
exécutables
Greenpepper
u
120
tests
Selenium
Club
Qualité
Logicielle
-­‐
4
octobre
2011
23

24. Les
spécifica4ons
exécutables,
c’est
quoi
?
Club
Qualité
Logicielle
-­‐
4
octobre
2011
24

25. Les
spécifica4ons
exécutables,
c’est
quoi
?
Club
Qualité
Logicielle
-­‐
4
octobre
2011
25

26. Les
spécifica4ons
exécutables,
c’est
quoi
?
Club
Qualité
Logicielle
-­‐
4
octobre
2011
26

27. Les
spécifica4ons
exécutables,
c’est
quoi
?
Club
Qualité
Logicielle
-­‐
4
octobre
2011
27
u Des
spécifica4ons
u Des
exemples
de
cas
de
recege
u De
la
glue
pour
servir
de
passe-­‐plat
:
on
exécute
le
code
de
l’applica4on
sur
des
jeux
de
données
préparées
à
l’avance
et
stables
u Possibilité
pour
le
Product
Owner
ou
le
développeur
d’ajouter
des
cas
de
tests
pour
valider
la
robustesse
de
son
code

28. Pourquoi
des
specs
exécutables
?
u Pour
livrer
plus
vite
durablement
u Pour
avoir
en
permanence
un
statut
sur
l’ap4tude
à
livrer
une
applica4on
u Pour
pouvoir
faire
évoluer
le
logiciel
avec
des
ressources
qui
changent
u Pour
appliquer
le
principe
du
«
fail
early
»
u Pas
de
(mauvaise)
surprise
à
la
fin
Club
Qualité
Logicielle
-­‐
4
octobre
2011
28

29. Stratégie
de
l’ATDD
u Les
spécifica4ons
exécutables
sont
pluggées
sur
la
couche
de
services
u Leur
qualité
est
essen4elle,
car
elle
détermine
la
structure
des
services
de
l’applica4on
u Et
le
reste
?
Des
tests
d’IHM
sur
le
process
standard
(
test
de
santé
)
u Sécurisa4on
des
applica4ons
legacy
par
un
harnais
de
tests
IHM
pe4t
à
pe4t
remplacés
par
des
tests
Greenpepper
Club
Qualité
Logicielle
-­‐
4
octobre
2011
29

30. L’organisa4on
liée
aux
tests
u L’idéal
:
c’est
le
mé4er
qui
écrit
les
tests.
Pas
facile
!
u L’AMOA
écrit
les
tests
u Pas
d’équipe
de
testeurs
dédiés
u Bien
séparer
les
tests
unitaires
(de
la
responsabilité
des
développeurs)
des
spécifica4ons
exécutables
(de
la
responsabilité
des
Product
Owners)
Club
Qualité
Logicielle
-­‐
4
octobre
2011
30

31. Les
tests
sont
un
inves4ssement
u Ces
tests
sont
un
patrimoine
dans
lequel
l’entreprise
inves4t
u Il
faut
rentabiliser
l’inves4ssement
ini4al
en
entretenant
le
capital
u
améliorer
la
couverture,
modifier
les
tests,
les
maintenir
opéra4onnels,
en
supprimer
certains
u Une
applica4on
ne
passe
en
produc4on
que
si
les
Greenpepper
sont
verts
u Principe
:
1
bug
=
1
test
Club
Qualité
Logicielle
-­‐
4
octobre
2011
31

32. Les
indicateurs
associés
u Pas
d’indicateurs
standards
fournis
par
les
usines
qualité
u Développement
en
cours
d’un
indicateur
de
couverture
des
tests
GP
u Mise
en
place
envisagée
d’un
indicateur
de
couverture
fonc4onnelle
des
tests
GP
(
sur
une
idée
de
GEFCO)
Club
Qualité
Logicielle
-­‐
4
octobre
2011
32

33. Et
si
on
arrêtait
de
faire
des
specs
exécutables
?
u 3
semaines
après
:
ça
devient
difficile
de
faire
une
modifica4on
fonc4onnelle
u 3
mois
après
:
on
souffre
pour
remegre
tout
ça
au
propre
u On
voudrait
ne
plus
jamais
arrêter
d’en
faire,
mais
il
faut
augmenter
la
qualité
des
spécs
exécutables
Club
Qualité
Logicielle
-­‐
4
octobre
2011
33

34. Problèmes
de
qualité
u La
qualité
est
cruciale
u Pour
réussir,
il
faut
:
u
Une
équipe
de
développement
qui
lit
les
spécifica4ons
u
Faire
rédiger
les
spécifica4ons
en
commun
par
les
Product
Owners
et
les
développeurs
u
Ne
pas
négliger
de
megre
des
tests
sur
les
interfaces
entrantes
/
sortantes
/
WS
et
même
sur
les
traitements
de
reprise
u Notre
dernière
idée
:
des
Technical
Reviews
sur
les
spécifica4ons
exécutables
Club
Qualité
Logicielle
-­‐
4
octobre
2011
34

35. L’ATTD
u Ne
supprime
pas
les
tests
faits
directement
par
les
u4lisateurs
finaux,
mais
les
sécurise
u N’est
pas
un
ou4l
magique
mais
évite
bien
des
sueurs
froides
u Trouve
sa
pleine
mesure
dans
un
environnement
de
développement
industrialisé
u Permet
de
réduire
les
temps
de
cycle
et
l’incrémental-­‐itéra4f
n’est
plus
seulement
une
promesse
u Demande
des
équipes
de
bon
niveau
et
qui
travaillent
de
manière
proche
Club
Qualité
Logicielle
-­‐
4
octobre
2011
35

36. Ques4ons
?
u Gilles
Mergoil,
gilles.mergoil@neoxia.com
u Bénédicte
Taillebois,
benedicte.taillebois@astria.com
36
Club
Qualité
Logicielle
-­‐
4
octobre
2011