Comment décrire des user stories en utilisant le langage Gherkin

DEFINITION D’UNE USER STORY

Une user story est une description de la fonctionnalité ou d’une partie de la fonctionnelle écrite dans le langage courant ou métier qui capture ce qu’un utilisateur fait ou doit faire.

Les user stories fournissent un moyen rapide de traiter les exigences des clients au lieu des documents d’exigences formels et sans effectuer les tâches administratives liées à leur maintenance.

BENEFICES

.

Les spécialistes de notre entreprise ont formulé les avantages de l’utilisation des user stories pour chaque membre de l’équipe Agile :

POUR LES CHEFS DE PROJET :

  • Il aide à faire l’architecture de l’application correctement ;
  • Il réduit le temps de réponse aux questions sur la logique de l’application aux développeurs, concepteurs, testeurs ;
  • Il peut être utilisé comme documentation et mis à jour facilement ;

POUR LES CONCEPTEURS :

  • Il donne un aperçu de la quantité de maquettes nécessaires pour couvrir l’ensemble de l’application de mise en page;
  • Il avertit de l’excès ou de l’absence de certains écrans / boutons / fonctionnalités;

POUR LES DÉVELOPPEURS :

  • Les fonctionnalités sont la base de l’écriture des tests d’acceptation avec le développement piloté par les tests (TDD et BDD);
  • Il permet d’éviter les incompréhensions de la documentation (spécifications et exigences du client), et les erreurs dans la logique de l’application;

POUR L’AQ :

  • Il sert de base à l’écriture de cas de test et de scénarios de test;
  • Il aide à comprendre rapidement la logique de l’application;

POUR LES CLIENTS :

  • Donne une bonne compréhension d’une application et de son fonctionnement;
  • Le client peut décrire la nouvelle fonctionnalité, en utilisant notre format de user Story qui empêche une mauvaise interprétation des exigences;

FORMATS DES USER STORIES

Vous pouvez également rencontrer les formats suivants d’une user story :

Mike Cohn, un auteur bien connu de user stories, concernant la clause « afin que » comme facultative :

« En tant que < rôle>, Je veux <goal/desire> »

Chris Matts a suggéré que « chasser la valeur » était la première étape pour réussir à livrer un logiciel, et a proposé cette alternative dans le cadre de Feature Injection :

« Afin de <recevoir un bénéfice> en tant que <role>, Je veux <but/desir> »

Autres options :

« En tant que <role>, je veux <objectif/désir> pour que <bénéficie> »

« En tant que <role>, je peux <agir avec le système> afin que <bénéfice externe> »

Dans l’entreprise Steelkiwi, nous utilisons le langage Gherkin pour rendre une user story plus lisible et compréhensible à la fois pour les développeurs et les clients.

DEFINITION DU LANGAGE GHERKIN

Gherkin est un langage lisible par l’homme pour la description du comportement du système, qui utilise l’indentation pour définir la structure du document (espaces ou tabulations). Chaque ligne commence par l’un des mots-clés et décrit l’une des étapes.

La plupart des lignes du cornichon commencent par un mot-clé spécial et se composent de fonctionnalités et de scénarios, par exemple :

.

Regardons l’exemple ci-dessus :

1. Fonctionnalité : Une description courte mais complète de la fonctionnalité requise, qui démarre une fonction et lui donne un nom.

2. Les trois lignes suivantes décrivent le bénéfice que nous allons tirer de cette fonctionnelle.

3. Scénario : Une certaine situation commerciale spécifique commence le script et contient une description.

4. Les 7 lignes suivantes décrivent les étapes du test, qui correspondent à un code spécifique, effectuant l’action décrite. Les lignes qui sont suivies des mots-clés « Given », « AND », « Then », etc. sont comparées.

IMPLEMENTATION

.

Ci-après, vous pouvez voir à quoi ressemble la partie initiale d’une de nos user stories :

Actions de l’utilisateur : Afin de visualiser des photos, définir des likes, consulter les actualités, télécharger des photos et participer à des concours En tant qu’utilisateur, je veux télécharger l’application sur l’App Store, puis m’inscrire/se connecter, puis rechercher des photos par artiste, visualiser des photos, définir des likes, consulter les actualités, télécharger ma photo, ajouter une photo dans des concours.

1.1. Inscription : Afin de s’inscrire En tant qu’utilisateur non autorisé, je veux ouvrir une application téléchargée, puis cliquer sur le bouton  » S’inscrire « , remplir tous les champs obligatoires (email, mot de passe, etc.), me connecter à Google+/Facebook/Instagram/Twitter et ajouter des amis qui sont inscrits à l’application PhotoCulture, puis rediriger vers la page d’accueil.

1.1.1. Télécharger l’application : Afin de télécharger l’application à partir de l’App Store En tant qu’utilisateur, je veux ouvrir l’App Store, puis cliquer sur le bouton de recherche, puis saisir « ____ », puis cliquer sur le bouton « Installer ».

1.1.2. Sign Up : Pour s’inscrire En tant qu’utilisateur non autorisé, je veux ouvrir une application téléchargée, puis cliquer sur le bouton « S’inscrire », puis être redirigé vers l’écran « S’inscrire », puis saisir la valeur correcte dans le champ « email », saisir la valeur correcte dans le champ « mot de passe », dupliquer la valeur du mot de passe dans le champ « confirmer le mot de passe », puis cliquer sur le bouton « S’inscrire », puis afficher la pop up « Vérifiez votre email pour terminer l’inscription », puis confirmer l’inscription dans mon email.

CONCLUSION

Avant d’écrire une user story individuelle, nous créons la story qui décrit le scénario de bout en bout du comportement de l’application, de l’inscription à la fin de l’application (déconnexion). Dans cette user story, nous décrivons toutes les actions pour lesquelles l’application est créée, par exemple, visualiser les photos des autres membres en ajoutant vos propres photos, participer à des concours, recevoir des récompenses, écrire des commentaires, etc. Plus bas, nous faisons des user stories individuelles qui décrivent plus en détail certaines fonctionnalités. Plus loin, si nécessaire, nous décrivons les parties plus détaillées de la user story précédente.

Un trait distinctif de notre entreprise est que notre user story n’est pas séparée de la structure générale du projet. Nous formons toutes les user stories de l’application dans un seul document dans lequel elles apparaissent dans la structure arborescente.

ADVANTAGES DE NOTRE APPROCHE

  • Il permet d’éviter les user stories noncompatibles entre les user stories et l’architecture de l’application
  • Il montre comment les changements affectent la structure de l’application
  • Il permet aux clients de rendre les nouvelles exigences et les souhaits plus compréhensibles pour les développeurs

Liens utiles

  1. User story
  2. Fonctionnalités d’écriture – gherkin

Si vous aimez cet article – obtenez plus de contenu intéressant sur SteelKiwi Blog !
Si vous avez des questions – Contactez-nous!

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *