Students Save 30%! Learn & create with unlimited courses & creative assets Students Save 30%! Save Now
Advertisement
  1. Web Design
  2. Documentation
Webdesign

Comment documenter vos créations à l’aide de récits utilisateur influencés par le comportement

by
Length:LongLanguages:

French (Français) translation by Henri Lotin (you can also view the original English article)

Un problème courant lorsque l'on documente des exigences est une prise de position du point de vue système pour décrire ce qu’il faut, en oubliant que c’est l’utilisateur qui sera au centre des interactions. Les récits utilisateur, introduits par Agile, gèrent ce problème en faisant mettant l’utilisateur au centre de l’exigence, et du Behavior Driven Development (BDD) met les choses un cran au-dessus pour fournir un cadre où le comportement de l’utilisateur est ce qui pousse le développement.

Utiliser des techniques BDD pour créer des récits utilisateur rend la documentation des exigences plus facile à lire et à écrire. En outre, il fournit des outils supplémentaires pour communiquer l’expérience utilisateur attendue d’un design, dont les designers, développeurs et ingénieurs QA peuvent se servir pour accélérer et même automatiser une partie de leur travail. Dans cet article j’étudierai cette approche et montrerai comment vous pouvez l’utiliser afin de documenter vos propres créations, en commençant par de petits récits à l'organisation de ces récits pour communiquer sur des caractéristiques pleinement fonctionnelles.

Exigences UI vs exigences UX

Il y a une importante distinction à faire entre les exigences de l’interface utilisateur (également connu sous le nom de spécifications) et UX. D’une part, les exigences de l’interface utilisateur sont des documents techniques qui listent les détails au sujet de l’interface utilisateur, y compris les types de polices, de couleurs, de dimensions et de disposition des éléments. Un bon exemple de ce type de documentation est Living Style Guides.

Les exigences UX, d’autre part, décrivent ce que l’expérience doit être pour un utilisateur spécifique, étant donné que cet utilisateur est dans un scénario spécifique effectue une action spécifique. Un récit utilisateur peut capturer une exigence UX de manière très succincte. Par exemple :

  • En tant que... utilisateur éditeur,
  • Je veux... être en mesure d’examiner les articles avant leur publication,
  • Et alors... Je peux fournir une rétroaction et garantir la qualité en temps opportun.

Ce récit indique tout d’abord le rôle d’utilisateur, ce que cet utilisateur veut accomplir et explique alors la raison derrière cela. C’est très bien car il fournit un aperçu aux développeurs et aux testeurs de ce qui est le but ultime : pour combler un besoin utilisateur. Notez que les mots en gras sont le modèle utilisé pour écrire l’histoire. Il y a toujours un utilisateur, qui veut faire quelque chose, de sorte qu’il puisse accomplir un objectif précis. Vous pouvez suivre ces conseils pour la rédaction de bons récits utilisateur.

Avec ce récit à l’esprit, l’équipe de design peut décider qu’une action de « validation » est nécessaire pour accomplir l’objectif de l’utilisateur. Puis pour fournir des détails sur comment cela fonctionne réellement, vous pouvez utiliser la Gherkin syntax, qui est un outil de BBD (behavior-driven development) pour l’écriture des exigences lisibles. La Gherkin syntax est similaire aux récits utilisateur agiles puisqu’elle fournit une manière d’écrire les exigences qui peut également être utilisé comme modèle. L’avantage est que vous pouvez entrer dans plus de détails, fournissant les scénarios et les actions que l’utilisateur prendrait sans entrer dans le comment la mise en œuvre sera faite. Nous allons jeter un coup d’oeil à cela.

Rédiger des récits utilisateur à l’aide de la Gherkin Syntax

Les bases d’un récit en se servant de la Gherkin Syntax peuvent se résumer en ces parties :

  • Une fonctionnalité
  • Un scénario
  • Une condition préalable
  • Une action
  • Un résultat

Une fonctionnalité est où on décrit la valeur commerciale globale de la mise en œuvre. Il peut également être utilisé pour fournir des informations supplémentaires, telles que des règles de business, ou tout ce qui rendre le dispositif plus facile à comprendre (tels que des liens vers des prototypes ou des exigences de l’interface utilisateur).

Un scénario décrit les circonstances spécifiques dans lesquelles l’utilisateur se trouve. Dans une perspective de design utilisateur, les scénarios permettent de communiquer les multiples variables d’un design, et comment l’interface utilisateur doit les prendre en charge, selon l’utilisateur.

Une condition préalable permet de mettre en place le scénario et supprime toute ambiguïté. Par exemple, dans un scénario qui décrit un utilisateur novice accédant à un écran particulier, la condition peut préciser que l’utilisateur est connecté.

Une action indique exactement ce que fait l’utilisateur dans l’interface, et est généralement un « déclencheur », par exemple cliquer sur un bouton, soumettre un formulaire, ou naviguer vers un autre endroit.

Un résultat est la conséquence de l’action et doit toujours être quelque chose qui peut être testé.

Avec ces parties à l’esprit, nous allons écrire un récit utilisateur pour la fonctionnalité que nous avons décrite précédemment :

  • En tant que... utilisateur éditeur,
  • Je veux... être en mesure d’examiner les articles avant leur publication,
  • Et alors... Je peux fournir une rétroaction et garantir la qualité en temps opportun.

Cette histoire, en se servant de la syntaxe de cornichon ressemblerait à ceci :

Fonctionnalité
Permettre aux éditeurs de réviser les articles avant publication finale et y apposer leur approbation.
Scénario
Approuver un article qui est prêt pour la publication.
Condition préalable
  • Étant donné que l’écrivain a présenté un article pour publication.
  • et que l’éditeur a accédé à la vue d’édition de l’article
Action
  • quand l’éditeur sélectionne « approuver »
Résultat
  • puis l’article est publié à la date prévue
  • et l’éditeur voit une alerte succès indiquant que l’article a été publié avec succès
  • et l’article est étiqueté comme « approuvé »
  • et une notification est adressée à l’auteur indiquant que son article a été approuvé.

Vous pouvez voir comment le récit initial se transforme en un flux plus détaillé que l’utilisateur peut suivre et donc qui peut être testé. Notez également que les mots en gras sont les mots clés qu'utilisent des logiciels tels que cucumber pour automatiser l’exécution de tests. Je vais vous expliquer plus à ce sujet par la suite, mais pour l’instant, je tiens à souligner que ces mots clés sont très utiles également pour l’écriture de l’histoire parce qu’ils aident à distinguer les différentes parties de l’histoire.

Quelque chose à souligner est que, bien que le récit fournisse plus de détails sur le flux de l’utilisateur, l’interface n’est pas décrite. La raison en est que décrire l’interface utilisateur peut rapidement transformer l’histoire en exigences UI, ce qui présente un gros problème car elles peuvent devenir obsolètes assez rapidement. Par exemple, si l’histoire décrit à quoi ressemble l’alerte de succès et ce que devrait être le message spécifique, alors l’histoire peut se désynchroniser si tout cela change, créant le potentiel de l’échec des tests.

L’astuce est donc de fournir suffisamment de détails, sans faire le travail des outils plus adéquats, tels que la création de maquettes, de prototypes et de directives de style. À cet égard, vous remarquerez que l’action n’indique pas « sélectionner approuver » mais se sert juste de « approuver ». « Sélectionner approuver » n’est pas précis quant à quoi ressemble ce contrôle (il pourrait être un bouton, un bouton qui ressemble à un lien ou une boîte qui est cliquable), mais cela ne signifie pas forcément qu’un élément dans l’interface utilisateur est déclenché. Il indique aussi que dans cet élément est écrit « approuver ». Il s’agit d’une zone grise où vous devrez faire preuve de sens commun, comme dans certains cas, que vous voudrez que ce soit spécifique afin que les actions se distinguent des autres. Par exemple, s’il y a une autre façon d’approuver un article sur la même page, ce qui indique que, dans ce scénario, l’utilisateur doit le « sélectionner », permet de faire la différenciation.

L’Importance des scénarios

Outre la syntaxe réfléchie que fournit Gherkin, une des choses que je trouve plus utile c'est l'utilisation de la partie « scénarios ». Les scénarios sont puissants parce qu’ils peuvent être utilisés pour tester le design et s’assurer que toutes les bases sont couvertes.

Habituellement, tout type de design débute avec un « chemin heureux », ce qui signifie ce qui arrive, lorsque tout se passe bien dans l’interface, et comment il s’applique à la majorité des utilisateurs. Dans notre exemple précédent, nous avons eu :

Scénario
Approuver un article qui est prêt pour la publication.

Aussi, parce que nous savons que les articles ont des dates de publication, nous pouvons également affirmer : c’est notre premier scénario parce que dans la majorité des cas les articles qui doivent être approuvés doivent être prêts pour la publication. Mais cela amène la question : que se passe-t-il lorsqu’un article n’est pas prêt pour la publication et que l’éditeur y accède ? Devrait-il même être en mesure d’accéder à ces articles ?

  • Que se passerait-il si un article est approuvé a une date de publication dans le passé ? L’article devrait être publié immédiatement, ou irait-il dans une file d’attente ?
  • Et en allant un peu plus loin, que se passe-t-il si un éditeur approuve un article par erreur ? Quelle est la procédure pour annuler cette action ? Qui devrait être averti ?

Toutes ces questions font partie du processus de design, et très probablement au moment où vous sautez dans la documentation des exigences, vous connaîtrez les réponses. La bonne nouvelle est que l’utilisation de scénarios dans la documentation de votre histoire vous aidera à les structurer et dans de nombreux cas vous aidera à QA vos propres créations, en veillant à ce qu’il y ait un design et des flux destinés à chacun d’elles.

Nous allons voir comment notre histoire prendrait forme avec les scénarios supplémentaires :

Fonctionnalité Permettre aux éditeurs de réviser les articles avant publication finale et y marquer leur approbation.
Scénario 1 Approuver un article prêt pour la publication.
  • Étant donné que l’auteur a soumis un article pour publication
  • et l’éditeur a accédé à la vue édition de l'article
  • quand l’éditeur clique sur « approuver »
  • puis l’article est publié à la date prévue
  • et l’éditeur voit une alerte succès indiquant que l’article a été publiée avec succès
  • et l’article est étiqueté comme « approuvé »
  • et une notification est adressée à l’auteur indiquant que son article a été approuvée.
Scénario 2

Accéder à un article qui n’est pas prêt pour la publication.

  • Quand...
Scénario 3

Approuver un article dont la date d’échéance est dépassée

  • Quand...
Scénario 4

Désapprouver un article qui a une date de publication ultérieure

  • Quand...
Scénario 5

Désapprouver un article qui a été publié

  • Quand...

Selon la fonctionnalité, il peut exister plusieurs scénarios à envisager. La clé est de les garder courts, afin que vous puissiez les décrire et les tester facilement. Vous pouvez également essayer de les regrouper, à l’aide de dénominateurs communs. Par exemple, si quelques scénarios partagent la même condition, vous pouvez encapsuler cela dans un « contexte » qui peut être utilisé par plusieurs scénarios. Par exemple :

Contexte
Le rédacteur a soumis un article pour la publication et l’éditeur a accédé à l’affichage de modification de l’article.
Scénario 1
Approuver un article prêt pour la publication.
  • Étant donné que le contexte est rempli
  • quand...
Scénario 2
Approuver un article qui a une date d’échéance dépassée
  • Étant donné que le contexte est rempli
  • quand...
Scénario 3
Désapprouver un article qui a une date de publication ultérieure.
  • Étant donné que le contexte est rempli
  • quand...

Organiser les récits pour communiquer une fonctionnalité

Un défi qui se profile lorsqu'il s'agit de documenter les exigences est de décider dans quel ordre le faire. La raison étant que, dans la plupart des cas tout est en construction, ce qui rend difficile de tester une interaction lorsque les parties des interactions ne sont pas encore construites. Par exemple, dans l’interaction simple de « l'approbation » d’un article, beaucoup de choses doivent être prêtes :

  1. L’interface utilisateur doit être en mesure de retourner un message de réussite si l’approbation est réussie et un message d'échec dans le cas où il y a un problème système.
  2. L’interface utilisateur devrait pouvoir « marquer » les articles comme approuvés.
  3. L’interface utilisateur doit être capable d’afficher l’article conformément à la logique métier « publié ».
  4. Les notifications du système doivent être activées, de sorte que les auteurs peuvent être alertés lorsque se produit l’approbation.

Une approche pour documenter les exigences pour chacune de ces dépendances c'est de les enregistrer en tant que fonctionnalités différentes qui peuvent ensuite être priorisées selon leur valeur commerciale.

Fonctionnalité
Description
Priorité
Système d’alerte
L’interface utilisateur doit être en mesure de retourner un message de réussite, mais aussi un message d’échec, dans le cas où il y a un problème de système
2
Système de marquage
L’interface utilisateur devrait pouvoir « marquer » les articles comme approuvés
4
Système de publication
L’interface utilisateur doit être capable d’afficher l’article conformément à la logique métier « publié »
1
Système de notifications
Le système de notification doit être activé, de sorte que les auteurs peuvent être alertés lorsque se produit l’approbation
3

Vous pouvez ensuite créer un récit de « l’intégration » pour les mettre tous ensemble. Par exemple, un récit utilisateur pour le système de marquage serait :

Fonctionnalité
Autoriser les utilisateurs et le système à marquer les articles selon un état donné (non publié, approuvé, publié ou archivé).
Scénario 1
Marquer un article comme non publié.
  • (détails...)
Scénario 2
Marquer un article comme approuvé.
  • (détails...)
Scénario 3
Marquer un article comme publié.
  • (détails...)
Scénario 4
Marquer un article comme archivé.
  • (détails...)

Dans le récit de l’intégration, vous pouvez faire référence au récit de marquage, dans le cas où les détails pour ce scénario doivent être vérifiés à nouveau ou si vous voulez simplement savoir si ces cas ont déjà été vérifiés.

Fonctionnalité
Permettre aux éditeurs de réviser les articles avant publication définitive et marquer leur approbation dessus.
Scénario 1
Approuver un article prêt pour la publication.
  • Étant donné que l'auteur a soumis un article pour publication
  • et l’éditeur a accédé à la vue modifier l'article
  • quand l’éditeur clique sur « approuver »
  • alors l’article est publié selon la date programmée
  • et l’éditeur voit une alerte succès indiquant que l’article a été publié avec succès
  • et l’article est marqué comme « approuvé » (cf scénario 2 du récit de marquage)
  • et une notification est adressée à l'auteur lui indiquant que son article a été approuvé.

Le point est d’éviter la répétition de documentation qui non seulement consomme du temps inutilement, mais cela peut aussi devenir désynchronisés.

Transformer les récits utilisateur en cas de test

Nous avons vu à quel point utile les récits utilisateur influencés par le comportement peut être pour la rédaction des exigences qui sont focalisées, concises, mais aussi approfondies et descriptives. À partir de la phase de design, cet outil peut être une bonne introduction pour les ingénieurs QA pour écrire des scénarios de test réels.

Outre ces grands avantages, les Behavioral Driven User Stories peuvent effectivement être transformés en tests fonctionnels à l’aide d’un logiciel, tel que Cucumber ou Lettuce. L’idée de base est qu’une fois que les récits sont écrits à l’aide de la syntaxe Gherkin, vous pouvez les placer dans un fichier .feature à l’intérieur de votre application et puis les exécuter comme tests pour montrer si elles ont réussi ou non. Pour un tutoriel approfondi sur l’utilisation de Lettuce pour une implémentation avec Python consultez le tutoriel de David Sale :

Conclusion

Écrire des récits utilisateur en utilisant les principes de BDD peut servir à communiquer en detail des exigences d'affaires et de design, avec une approche centrée sur l’utilisateur, tout en utilisant un langage qui est humain lisible mais extensible pour l’interprétation de logiciel. En outre, il peut être utilisé pour tester :

  • vos propres créations comme vous documentez les exigences
  • l’application réelle manuellement, une fois transformé en cas de test par un ingénieur QA
  • l’application actuelle automatiquement, lorsque transformée en tests fonctionnels à l’aide de logiciels BDD.

Cela signifie plus de couches pour les bogues à traverser, empêchant les lacunes dans le design et le blindage ultérieur de votre application des défaillances de bogue.

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.