Qu'est-ce que la user story et les critères d'acceptation (exemples)

Exemple:

En tant qu'utilisateur WhatsApp, je veux une icône d'appareil photo dans la zone d'écriture du chat pour capturer et envoyer des images afin que je puisse cliquer et partager mes photos simultanément avec tous mes amis.

Qu'est-ce qu'un critère d'acceptation?

Un critère d'acceptation est un ensemble de conditions ou de règles commerciales acceptées que la fonctionnalité ou la fonctionnalité doit satisfaire et respecter, afin d'être acceptée par le Product Owner / Stakeholders.

C'est une partie très importante de l'achèvement de la user story et elle doit être étudiée très méticuleusement par le Product Owner et l'analyste commercial, car manquer un seul critère peut coûter cher. Il s'agit d'une simple liste numérotée ou à puces.

Son format est le suivant:

' Étant donné une condition préalable lorsque je fais une action, j'attends le résultat ».

avec quoi ouvrir les fichiers swf

Exemple (par rapport à la user story ci-dessus):

• Considérons que je clavarde avec un ami et que je devrais pouvoir prendre une photo.
• Lorsque je clique sur une image, je devrais pouvoir ajouter une légende à l'image avant de l'envoyer.
• En cas de problème lors du démarrage de l'appareil photo de mon téléphone, un message d'erreur du type 'L'appareil photo n'a pas pu démarrer'. etc., doivent être affichés en conséquence.

Par conséquent, la user story définit l'exigence pour toute fonctionnalité ou fonctionnalité tandis que les critères d'acceptation définissent la «définition de terminé» pour la user story ou l'exigence.

En tant que QA, il est très important de comprendre la user story et ses critères d'acceptation en profondeur sans même un seul doute au «début des tests». Pour aller de l'avant, comprenons pourquoi il est extrêmement important de creuser «profondément» dans les user stories et les critères d'acceptation.

Approfondir les histoires d'utilisateurs

Pour commencer, comprenons d’abord l’importance d’une étude «approfondie» d’une chose fondamentale et fondamentale, c’est-à-dire Histoires d'utilisateurs.

Les cas suivants sont mes propres expériences réelles.

Cas 1:

Avant 3 ans, je travaillais sur un projet d'application mobile et le produit était une application conçue pour les livreurs.

Vous auriez vu un livreur venir chez vous pour la livraison. Et ils ont un téléphone portable sur lequel ils vous demandent de donner votre signature après la livraison. Cette signature se reflète sur le portail des prestataires de services de messagerie comme DTDC, FedEx etc.

Imaginons que l'application mobile vient tout juste d'être lancée et que leurs portails existent déjà et sont déjà en place.

Problème: Pour un Sprint, votre Product Owner a une user story pour cette application mobile qui 'En tant qu'administrateur du portail, je devrais pouvoir voir la signature prise par le livreur au moment de la livraison' . Ici, le portail (application Web) est modifié et mis à jour en conséquence pour refléter la signature.

En tant que contrôle qualité, vous devez vérifier si la signature capturée dans l'application mobile se reflète comme prévu dans le portail.

Si vous regardez cette user story, cela semble simple, mais il y a une exigence cachée ici: 'Pour les livraisons historiques, il n'y avait pas de fonctionnalité de réflexion de signature, alors que devrait-il se passer si les gars du portail consultent les livraisons historiques?' Les données historiques doivent-elles être effacées? Devrions-nous autoriser les plantages ou les erreurs pour ces données?

Bien sûr, pas du tout, cela doit être géré gracieusement.

Solution: Lorsque les tables DB respectives sont mises à jour pour ajouter une nouvelle colonne pour l'emplacement de signature, les anciennes données doivent avoir une valeur NULL ou 0 qui doit être vérifiée et un message indiquant «Aucune signature n'existe» doit être affiché.

Cela peut être appelé comme un échec du Product Owner ou de l'analyste commercial, mais cela doit être fait. Mettre en œuvre une fonctionnalité avec succès mais casser quelque chose avec elle n'est pas souhaitable par les clients. Cela doit être fait avec la même user story et dans le même sprint.

Cas n ° 2

Il y a 6 ans, je travaillais sur une application de financement de la planification de la retraite (sans BA) qui était une application globale où des gens de la finance comme CA, des conseillers financiers pouvaient l'utiliser pour différentes devises pour projeter les plans d'investissement, l'épargne, etc., sur un longue période à leurs clients.

Problème: Le Product Owner vous donne une User Story qui «En tant que conseiller, je souhaite consulter le rapport de mon client en fonction des détails financiers fournis».

Ici, il y avait 2 exigences cachées et je l'appellerais comme une histoire incomplète parce que:

à) Les rapports doivent tenir compte du taux de conversion quotidien des devises et non de l'historique comme dans le dernier rapport consulté et

b) Si la devise est modifiée après avoir fourni les détails financiers du client, les rapports doivent apparaître dans la devise modifiée.

Solution: J'ai soulevé cette inquiétude directement auprès de notre Product Owner et lui ai fait savoir que les deux devaient être faits le plus tôt possible. Il était d'accord avec moi et a créé 2 histoires différentes pour les sprints à venir avec priorité.

Emporter: Celles-ci ont été capturées parce que nous connaissions tous très bien les produits, leur conception, leur structure, etc. De telles connaissances ne peuvent être obtenues qu'en comprenant complètement le produit, en comprenant l'interopérabilité des modules et en étudiant minutieusement la user story même si elle une doublure 2.

Prenez des notes pour faciliter les choses et discutez avec les BA et les développeurs de leur réflexion.

Examen approfondi des critères d'acceptation

Comprendre les critères d'acceptation et toutes les autres conditions et règles de manière exhaustive est encore plus important que de comprendre une user story. Parce que si une exigence est incomplète ou vague, elle peut être reprise dans le sprint suivant, mais si un critère d'acceptation est manqué, alors la user story elle-même ne peut pas être publiée.

Je suppose que nous aurions tous utilisé la banque en ligne à un moment donné et la plupart d'entre nous l'utilisons tous les jours et je télécharge beaucoup mes relevés historiques. Si vous l'observez attentivement, certaines options spécifiques sont disponibles pour les télécharger.

Il existe une option pour sélectionner le type de fichier pour télécharger votre relevé. Il existe une option à choisir si vous souhaitez télécharger uniquement les crédits / débit / les deux.

Imaginez maintenant que le Product Owner vous livre cette User story «En tant que client, je souhaite télécharger mon relevé de compte afin de pouvoir visualiser toutes mes transactions effectuées pour une période spécifique».

Avec les critères d'acceptation suivants:

• Étant donné que je suis sur la page Télécharger le relevé historique, je dois sélectionner la période pour laquelle je souhaite télécharger le relevé.
• Étant donné que je suis sur la page Télécharger le relevé historique, je dois sélectionner le compte pour lequel je souhaite télécharger le relevé.
• Étant donné que je suis sur la page de téléchargement de la déclaration historique, je ne devrais pas être autorisé à télécharger la déclaration pour la future date «À».
• Étant donné que je suis sur la page Télécharger la déclaration historique, je ne devrais pas être autorisé à sélectionner la date «De» 10 ans au-delà dans le passé.
• Étant donné que je télécharge ma déclaration, je devrais pouvoir afficher le fichier téléchargé.
• Étant donné que je suis sur la page de téléchargement de la déclaration historique, je devrais pouvoir télécharger ma déclaration aux formats doc, excel et pdf.

Si vous passez par cette acceptation, il manque 3 choses ici:

• Nom et format du nom de fichier qui sera téléchargé.
• Quelles informations (noms de colonnes) doivent être affichées dans le fichier.
• La liste d'options pour sélectionner le type de transaction souhaité par le client, c'est-à-dire uniquement les débits ou uniquement les crédits ou les deux.

De tels cas peuvent survenir de temps en temps, mais étudiez toujours bien chaque critère d'acceptation et essayez de le visualiser en référence à la user story. Plus vous étudiez en profondeur les conditions et les règles métier, plus vous en saurez plus sur la fonctionnalité.

Les bogues trouvés dans la phase initiale ne coûtent rien par rapport à ce que cela peut coûter lors de la phase de «test».

Importance de trouver des écarts dans la user story / les critères d'acceptation

Il est toujours important de plonger en profondeur dans les user stories et les critères d'acceptation à un stade précoce avant même que le développement ou le test ne commence.

Parce que cela implique:

# 1) Perte de temps:

Si les écarts ou les erreurs dans la user story / les critères d'acceptation sont détectés lors du développement ou des tests en cours, alors beaucoup de retouches peuvent être nécessaires dans le temps de sprint restant.

Il n’arrive pas que même si le Product Owner a manqué peu de choses, il déplace la user story vers le sprint à venir. 95% de chances sont qu'ils demandent à l'équipe de faire l'implémentation nécessaire et de la publier dans le même sprint.

Cela devient donc un cauchemar pour l'équipe qui doit passer plus de temps, venir le week-end ou travailler tard le soir. Cela peut être évité en étudiant et en discutant de la user story / des critères d'acceptation le plus tôt possible.

# 2) Gaspillage d'efforts:

Les développeurs et le contrôle qualité doivent revoir à nouveau le code implémenté et les cas de test. La mise à jour, l'ajout et la suppression selon les besoins ne sont pas une tâche facile. Cela devient trop douloureux car il y a déjà une pression pour livrer à temps.

Dans une telle situation, il y a des risques d'erreurs dans la phase de développement ou de test. Si vous rencontrez une telle situation, optez pour «Couplage DevQA». Cerise sur le gâteau, vous pourriez ne pas obtenir de compensation pour le travail supplémentaire.

Conclusion

Une compréhension approfondie de la User Story et des critères d'acceptation ne peut être obtenue qu'en passant un temps immense à l'étudier.

Il n'y a pas d'outil ou de cours spécifique disponible sur le marché pour le faire pour vous car tout est question de pensée logique, d'expérience et de connaissance du produit.

Participer activement à la réunion de pré-planification, parler au BA, étudier par vous-même ne peut que vous aider à y parvenir. Plus vous faites d'efforts, plus vous apprenez et grandissez.

Qu'il s'agisse du contrôle qualité ou des développeurs, tout le monde doit être sur la même longueur d'onde concernant les user stories et leurs critères d'acceptation, ce n'est qu'alors que les attentes du client peuvent être satisfaites.

Avez-vous quelque chose de nouveau à partager avec nous sur vos expériences de travail avec les User Stories? Veuillez exprimer vos pensées ci-dessous !!

lecture recommandée

• MongoDB Créer un utilisateur et attribuer des rôles avec des exemples
• Exemple de modèle de rapport de test d'acceptation avec des exemples
• Authentification des utilisateurs dans MongoDB
• Paramétrage des données JMeter à l'aide de variables définies par l'utilisateur
• Autorisations Unix: autorisations de fichiers sous Unix avec des exemples
• Qu'est-ce que le test d'acceptation (un guide complet)
• Qu'est-ce que le test d'acceptation de l'utilisateur (UAT): un guide complet
• Tutoriel Python DateTime avec des exemples