Le document traite des tests d'acceptation dans le cadre des pratiques agiles, mettant en avant leur rôle en tant qu'outil de communication essentiel entre le client, le product owner et l'équipe de développement. Il explique la rédaction de critères d'acceptation sous forme de conditions spécifiques et mesurables, tout en soulignant l'importance d'exemples concrets et d'un format structuré tel que 'given-when-then'. Enfin, il mentionne des outils comme Cucumber pour faciliter l'écriture et l'exécution de ces tests.

1. TEST D’ACCEPTATION
Yannick Quenec’hdu
www.openagile.net
vendredi 24 juin 2011

2. UN ÉLÉMENT DES
PRATIQUES AGILE
vendredi 24 juin 2011

3. UNE HISTOIRE COURTE
Ça s’appelait
« Customer tests »
... Dans les premières versions de XP, on disait aussi :
« Functional test »
Maintenant on emploie plutôt
« Test d’acceptation ou ATDD»
En France on parle dans un autre contexte de recette... On
aura tendance à oublier ce terme en Agile.
vendredi 24 juin 2011

4. LE TEST D’ACCEPTATION
Un outil de communication
Fourni par le client ou le PO
Détermine quand une story est « terminée »
Écrit ensemble (client, PO, SM, développeur,
testeur, etc.)
Concentré sur le Quoi, plutôt que le Comment
vendredi 24 juin 2011

5. Je suis un j
uriste, je v
document eux dépos
s dans un er des
communau dossier sp
té écifique à
ma
Comment, je vérifie
cette stor y ?
vendredi 24 juin 2011

6. Je suis un j
uriste, je v
document eux dépos
s dans un er des
communau dossier sp
té écifique à
ma
Comment, je vérifie
cette stor y ?
J’écris quelqu
es critères
d’acceptation
vendredi 24 juin 2011

7. LES CRITÈRES
D’ACCEPTATION
vendredi 24 juin 2011

8. CRITÈRES D’ACCEPTATION
Ensemble de conditions que l'histoire
doit satisfaire pour être considérée
comme complète
Généralement fourni par
le product owner ou le client
vendredi 24 juin 2011

9. LES CRITÈRES
D’ACCEPTATION NE SONT
PAS DES TESTS
vendredi 24 juin 2011

10. RÉDIGER UN CRITÈRE D’ACCEPTATION
Les critères d’acceptation doivent
contenir :
Un acteur
un verbe - décrivant le
comportement
des résultats observables
vendredi 24 juin 2011

11. Pour tenir compte des conditions pre-requis, les
Critères d'acceptation peuvent être exprimés de
cette manière :
Pré-condition (état du système avant
l’exécution de la story)
Quand [Acteur + Action]
Et [Résultat observable]
Méthode Given - When -Then
vendredi 24 juin 2011

12. Les critères d’acceptation doivent être :
Visible pour l’utilisateur
Si le critère est « interne », ce n’est pas un
critère d'acceptation
vendredi 24 juin 2011

13. SMART Faci
lite
critè la réd
res actio
d’ac n de
cept
• Spécifique - défini et explicite atio s
n
• Mesurable - quantifiable et mesurable
• Atteignable - qui peut être réalisé et validé
• Relevant - pertinent pour la story
• Temporaire - limité dans le temps
vendredi 24 juin 2011

14. SPÉCIFIQUE
Un critère doit être suffisamment précis
pour que chacun puisse comprendre ce
qu’il implique.
vendredi 24 juin 2011

15. MESURABLE
La principale mesure est : “ Pouvons-nous
le marquer comme réalisée ? ”
vendredi 24 juin 2011

16. ATTEIGNABLE
Le propriétaire de la tâche doit être en
mesure de savoir si la tache est réalisable
Il peut demander de l’aide, mais il doit être
en mesure de la faire.
vendredi 24 juin 2011

17. RELEVANT - PERTINENT
Chaque critère doit être pertinent, c'est-à-
dire qu’il contribue à la story.
Les stories sont découpées en (critères)
tâches pour les développeurs, mais un PO
doit s'attendre à ce qu’on lui explique
chaque tâche et sa justification.
vendredi 24 juin 2011

18. TEMPORAIRE
Une tâche (critère) doit être définie dans
le temps : limitée à une durée spécifique.
Ce n’est pas une évaluation formelle. Mais
l’équipe doit savoir s’il est nécessaire de la
découper davantage
vendredi 24 juin 2011

19. vendredi 24 juin 2011

20. Story
+
Critères d’acceptation
+
Exemple
(données + scénarios)
=
vendredi 24 juin 2011

21. Story
+
Critères d’acceptation
+
Exemple
(données + scénarios)
=
TEST D’ACCEPTATION
vendredi 24 juin 2011

22. QUI ÉCRIT LES TESTS
D’ACCEPTATION ?
vendredi 24 juin 2011

23. QUI ÉCRIT LES TESTS
D’ACCEPTATION ?
Client
Product owner
L’équipe (Les testeurs,
Développeurs, etc.)
vendredi 24 juin 2011

24. LES TESTS ONT BESOIN DE
TECHNIQUES
Le PO ou le client peut avoir besoin dune
aide technique pour écrire les tests
Les testeurs et les développeurs sont des
techniques
Créer des pairs (technique et métier)
vendredi 24 juin 2011

25. LES RÈGLES MÉTIERS PEUVENT
ÊTRE FLOUES
Parfois les testeurs peuvent avoir besoin
d’aide pour comprendre les tests
Le client ou le PO connaît les règles métier
Créer des pairs (métier et technique)
vendredi 24 juin 2011

26. EXEMPLE
vendredi 24 juin 2011

27. UNE AUTHENTIFICATION
Écrire un plan de test au format
textuel, pour une authentification
simple
Les informations sont dans un référentiel de données
Une authentification réussie redirige vers la page d’accueil
vendredi 24 juin 2011

28. ÉCRIRE UN BON TEST
D’ACCEPTATION
vendredi 24 juin 2011

29. POSSIBILITÉ DE TEST
D’AUTHENTIFICATION
1. Saisir l’url de l’application
2. Entrer le nom «Robert»
Créer d’abord un environnement
de test
vendredi 24 juin 2011

30. POSSIBILITÉ DE TEST
D’AUTHENTIFICATION
1. Ajouter un utilisateur dans le système
2. Ajouter une valeur dans le champ identifiant
Soyez précis
vendredi 24 juin 2011

31. TEST PAR L’EXEMPLE
Utiliser des exemples concrets
Utiliser des comportements concrets
L’ambiguïté n’est pas permise
vendredi 24 juin 2011

32. POSSIBILITÉ DE TEST POUR
L’AUTHENTIFICATION
Insérer dans la table User la valeur :
‘Robert’, ‘password’)
Saisir l’url : http://localhost/myapp
Penser SMART
vendredi 24 juin 2011

33. AUTHENTIFICATION :
SOLUTION POSSIBLE
Ajouter un utilisateur dans le système (‘Robert’, ‘password’)
Réaliser une authentification avec l’identifiant ‘Robert’ et
avec le mot de passe ‘Blas’
L’identification ne fonctionne pas
Réaliser une authentification avec l’identifiant ‘Robert’ et
avec le mot de passe ‘password’
L’identification fonctionne
vendredi 24 juin 2011

34. GIVEN - WHEN - THEN
Ce format provient du BDD (Behavior Driven
Development) qui provient des techniques de
développement Agile
Il a pour objectif d’intégrer une formalisation du
développement pour obtenir automatiquement des
tests fonctionnels
vendredi 24 juin 2011

35. UNE AUTRE SOLUTION
La matrice Given - When - Then un format recommandé
pour le test fonctionnel d’une user story
•Given (étant donné) un contexte
•When (lorsque) l’utilisateur effectue certaines actions
•Then (alors) on doit pouvoir constater telles
conséquences
•And (et) est utilisé de manière optionnelle pour ajouter
des conditions
vendredi 24 juin 2011

36. UN EXEMPLE
•Étant donné que j’ai fait une réservation,
•Lorsque j’annule ma réservation,
•Alors je dois recevoir un courriel de confirmation
vendredi 24 juin 2011

37. CUCUMBER
C’est un outil Open source pour écrire vos tests
1. Je décris le comportement avec le format Given - When -
Then
2. J’écris mon code
3. J'exécute et vérifie le bon fonctionnement
http://cuckes.info
D’autres outils OpenSource de test : opensourcetesting.org
vendredi 24 juin 2011

38. QUESTIONS ?
vendredi 24 juin 2011

39. Blog :
www.openagile.net
Contact :
yquenechdu@gmail.com
Merci pour
votre attention
vendredi 24 juin 2011

40. Usage commercial non autorisé
vendredi 24 juin 2011
Usage commercial non autorisé