Comment écrire un récit utilisateur testable.
Un récit utilisateur doit exprimer une capacité et sa valeur. Évitez de déguiser une tâche technique en avantage utilisateur.
Adaptez le processus à votre tâche.
Nommez l’utilisateur, la capacité et pourquoi elle importe, puis ajoutez des critères d’acceptation rendant le résultat observable. Gardez le récit suffisamment ciblé pour vérifier sa réalisation dans un scénario concret.
- Ce que vous fournissez
- Problème utilisateur et capacité souhaitée.
- Ce que vous obtenez
- Récits centrés sur l’utilisateur avec limites de portée.
Consultez les données et le résultat.
Entrée et sortie illustratives · exemple pédagogique, pas une exécution WebAct en direct
Exemple champ
Catalog manager needs to identify changed supplier prices.
Exemple complet
As a catalog manager, I want to review changed prices so I can approve updates before importing them.
Chargez ces données dans le prompt, puis copiez-le dans WebAct pour essayer la tâche. Votre résultat peut différer de l'illustration.
Décisions et dépannage.
Faut-il forcer une maintenance technique dans la phrase d’un récit utilisateur ?
Expliquez son but et ses contraintes réels. Une tâche technique peut être décrite honnêtement sans inventer une action utilisateur pour correspondre au format.
Pourquoi le récit semble-t-il terminé mais difficile à tester ?
Ajoutez comportement attendu et limites pertinentes. Le bénéfice explique l’intérêt ; les critères d’acceptation expliquent ce que signifie terminer.
Essayez avec votre propre source.
Remplacez l'exemple par vos données dans le prompt. Gardez les exigences nécessaires, puis copiez la tâche dans WebAct.
Personnaliser et copier la tâche ↑