Test acceptance

15 952 vues

Publié le

Les tests d'acceptance en Agile

Publié dans : Technologie, Business
0 commentaire
12 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
15 952
Sur SlideShare
0
Issues des intégrations
0
Intégrations
1 142
Actions
Partages
0
Téléchargements
390
Commentaires
0
J’aime
12
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive






  • 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

























  • Test acceptance

    1. 1. TEST D’ACCEPTATION Yannick Quenec’hdu www.openagile.netvendredi 24 juin 2011
    2. 2. UN ÉLÉMENT DES PRATIQUES AGILEvendredi 24 juin 2011
    3. 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. 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 Commentvendredi 24 juin 2011
    5. 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. 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’acceptationvendredi 24 juin 2011
    7. 7. LES CRITÈRES D’ACCEPTATIONvendredi 24 juin 2011
    8. 8. CRITÈRES D’ACCEPTATION Ensemble de conditions que lhistoire doit satisfaire pour être considérée comme complète Généralement fourni par le product owner ou le clientvendredi 24 juin 2011
    9. 9. LES CRITÈRES D’ACCEPTATION NE SONT PAS DES TESTSvendredi 24 juin 2011
    10. 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 observablesvendredi 24 juin 2011
    11. 11. Pour tenir compte des conditions pre-requis, les Critères dacceptation 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 -Thenvendredi 24 juin 2011
    12. 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 dacceptationvendredi 24 juin 2011
    13. 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 tempsvendredi 24 juin 2011
    14. 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. 15. MESURABLE La principale mesure est : “ Pouvons-nous le marquer comme réalisée ? ”vendredi 24 juin 2011
    16. 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. 17. RELEVANT - PERTINENT Chaque critère doit être pertinent, cest-à- 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 sattendre à ce qu’on lui explique chaque tâche et sa justification.vendredi 24 juin 2011
    18. 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 davantagevendredi 24 juin 2011
    19. 19. vendredi 24 juin 2011
    20. 20. Story + Critères d’acceptation + Exemple (données + scénarios) =vendredi 24 juin 2011
    21. 21. Story + Critères d’acceptation + Exemple (données + scénarios) = TEST D’ACCEPTATIONvendredi 24 juin 2011
    22. 22. QUI ÉCRIT LES TESTS D’ACCEPTATION ?vendredi 24 juin 2011
    23. 23. QUI ÉCRIT LES TESTS D’ACCEPTATION ? Client Product owner L’équipe (Les testeurs, Développeurs, etc.)vendredi 24 juin 2011
    24. 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. 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. 26. EXEMPLEvendredi 24 juin 2011
    27. 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’accueilvendredi 24 juin 2011
    28. 28. ÉCRIRE UN BON TEST D’ACCEPTATIONvendredi 24 juin 2011
    29. 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 testvendredi 24 juin 2011
    30. 30. POSSIBILITÉ DE TEST D’AUTHENTIFICATION 1. Ajouter un utilisateur dans le système 2. Ajouter une valeur dans le champ identifiant Soyez précisvendredi 24 juin 2011
    31. 31. TEST PAR L’EXEMPLE Utiliser des exemples concrets Utiliser des comportements concrets L’ambiguïté n’est pas permisevendredi 24 juin 2011
    32. 32. POSSIBILITÉ DE TEST POUR L’AUTHENTIFICATION Insérer dans la table User la valeur : ‘Robert’, ‘password’) Saisir l’url : http://localhost/myapp Penser SMARTvendredi 24 juin 2011
    33. 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 fonctionnevendredi 24 juin 2011
    34. 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 fonctionnelsvendredi 24 juin 2011
    35. 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 conditionsvendredi 24 juin 2011
    36. 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 confirmationvendredi 24 juin 2011
    37. 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. Jexécute et vérifie le bon fonctionnement http://cuckes.info D’autres outils OpenSource de test : opensourcetesting.orgvendredi 24 juin 2011
    38. 38. QUESTIONS ?vendredi 24 juin 2011
    39. 39. Blog : www.openagile.net Contact : yquenechdu@gmail.com Merci pour votre attentionvendredi 24 juin 2011
    40. 40. Usage commercial non autorisévendredi 24 juin 2011 Usage commercial non autorisé

    ×