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
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
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
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
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é
Hinweis der Redaktion
Un des gaspillages les plus spectaculaires dans le développement de logiciel est l'écriture de spécifications détaillées suivie de la rédaction d'un cahier de recette, plus ou moins à partir de ces spécifications.
A chaque histoire d'utilisateur sont associés des critères permettant au client de tester l'histoire. Ces critères d'acceptation peuvent être formalisés, pour aller un peu plus loin dans l'aide fournie à l'équipe