Share
Un problème courant lors de la documentation des exigences consiste à prendre position du point de vue du système pour décrire les besoins, en oubliant que c’est l’utilisateur qui sera au centre des interactions. Les user stories, introduites par Agile, traitent ce problème en plaçant l'utilisateur au centre du besoin, et le développement piloté par le comportement (BDD) va encore plus loin en fournissant un cadre dans lequel le comportement de l'utilisateur est le moteur du développement..
L'utilisation des techniques BDD pour créer des user stories facilite la rédaction et la lecture des exigences de documentation. En outre, il fournit des outils supplémentaires pour communiquer l'expérience utilisateur souhaitée d'une conception, que les concepteurs, les développeurs et les ingénieurs d'assurance qualité peuvent utiliser pour accélérer et même automatiser une partie de leur travail. Dans cet article, je vais explorer cette approche et montrer comment vous pouvez l'utiliser pour documenter vos propres conceptions, en partant de petites histoires pour organiser ces histoires afin de communiquer des fonctionnalités entièrement fonctionnelles..
Il y a une distinction importante à faire entre les exigences d'interface utilisateur (également appelées spécifications) et les exigences UX. D'une part, les exigences de l'interface utilisateur sont des documents techniques qui répertorient les spécificités de l'interface utilisateur, notamment les types de police, les couleurs, les dimensions et la disposition des éléments. Un bon exemple de ce type de documentation est les guides de style de vie..
Les exigences UX, d’autre part, décrivent ce que l’expérience devrait être pour un spécifique utilisateur, étant donné que cet utilisateur est dans un scénario spécifique en train d'effectuer une action spécifique. Une user story peut capturer une exigence UX de manière très succincte. Par exemple:
Cette histoire indique d'abord le rôle de l'utilisateur, ce que celui-ci veut accomplir, puis explique la raison derrière ce rôle. C’est formidable, car il offre aux développeurs et aux testeurs un aperçu du but ultime: satisfaire les besoins des utilisateurs. 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 pour pouvoir atteindre un objectif spécifique. Vous pouvez suivre ces conseils pour rédiger de bonnes histoires d'utilisateurs..
Avec cette histoire en tête, l'équipe de conception peut décider qu'une action «d'approbation» est nécessaire pour atteindre l'objectif de l'utilisateur. Ensuite, pour fournir des détails sur la manière dont cela fonctionnera réellement, vous pouvez utiliser la syntaxe Gherkin, qui est un outil BBD pour la rédaction d'exigences lisibles par l'entreprise. La syntaxe Gherkin est similaire aux user stories agiles, car elle fournit un moyen d'écrire les exigences qui peut également être utilisé comme modèle. L'avantage est que vous pouvez entrer dans plus de détails, en fournissant des scénarios et des actions que l'utilisateur pourrait entreprendre sans entrer dans le processus de mise en œuvre. Regardons cela de près.
Les bases d’une histoire utilisant la syntaxe de Gherkin peuvent être résumées comme suit:
Une caractéristique est un endroit pour décrire 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 commerciales, ou tout élément facilitant la compréhension de la fonctionnalité (tels que des liens vers des prototypes ou les exigences de l'interface utilisateur)..
Un scénario décrit les circonstances spécifiques dans lesquelles se trouve l'utilisateur. Du point de vue de la conception utilisateur, les scénarios permettent de communiquer les multiples variables d’une conception et la manière dont l’interface utilisateur doit les gérer, en fonction de l’utilisateur..
Une condition préalable aide à construire le scénario et supprime toute ambiguïté. Par exemple, dans un scénario qui décrit un premier utilisateur accédant à un écran particulier, la condition préalable peut préciser que l'utilisateur est connecté..
Une action indique exactement ce que l'utilisateur fait dans l'interface et est généralement un «déclencheur», tel que cliquer sur un bouton, soumettre un formulaire ou naviguer vers un autre endroit.
Un résultat est la conséquence de l'action, et devrait toujours être quelque chose qui peut être testé.
Avec ces parties en tête, écrivons une user story pour la fonctionnalité décrite précédemment:
En utilisant la syntaxe Gherkin, cette histoire ressemblerait à ceci:
| Fonctionnalité | Autoriser les éditeurs à examiner les articles avant leur publication finale et à y apposer leur approbation. |
| Scénario | Approuver un article prêt à être publié. |
| Condition préalable |
|
| action |
|
| Résultat |
|
Vous pouvez voir comment l'histoire initiale se transforme en un flux plus détaillé que l'utilisateur peut suivre et par conséquent, qui peut être testé. Notez également que les mots en gras sont les mots-clés utilisés par des logiciels tels que concombre pour automatiser l'exécution des tests. J'expliquerai davantage à ce sujet plus tard, mais pour l'instant, je tiens à souligner que ces mots clés sont également très utiles pour écrire l'histoire car ils permettent de distinguer les différentes parties de l'histoire..
Une autre chose à souligner est que bien que l'histoire fournisse plus de détails sur le flux d'utilisateurs, l'interface n'est pas décrite. La raison en est que la description de l'interface utilisateur peut rapidement transformer le récit en exigences d'interface utilisateur, ce qui pose un gros problème car elles peuvent être obsolètes assez rapidement. Par exemple, si l'article décrit l'apparence de l'alerte de succès et ce que le message spécifique doit indiquer, il est possible que l'historique ne soit plus synchronisé si l'un de ces éléments change, ce qui peut entraîner l'échec des tests..
L'astuce consiste donc à fournir suffisamment de détails, sans utiliser des outils plus adéquats, tels que des maquettes de conception, des prototypes et des guides de style. À cet égard, vous remarquerez que l’action indique «choisir d’approuver» par rapport à «utiliser». "Sélectionner l'approbation" n'indique pas à quoi ressemble ce contrôle (il peut s'agir d'un bouton, d'un bouton ressemblant à un lien ou d'une boîte cliquable), mais cela implique qu'un élément de l'interface utilisateur est déclenché. Il indique également que cet élément a écrit «approuver». Il s’agit d’une zone grise dans laquelle vous devrez faire preuve de bon sens, car dans certains cas, vous voudrez être aussi précis afin que les actions puissent être distinguées des autres. Par exemple, s’il existe un autre moyen d’approuver un article sur la même page, en indiquant que, dans ce scénario, l’utilisateur doit le «sélectionner», permet de faire la distinction..
Outre la syntaxe réfléchie fournie par Gherkin, l'une des choses que je trouve les plus utiles est d'utiliser la partie «scénarios». Les scénarios sont puissants car ils peuvent être utilisés pour tester la conception et s’assurer que toutes les bases sont couvertes..
Habituellement, les conceptions de toutes sortes commencent par la «voie heureuse», c'est-à-dire ce qui se passe lorsque tout se passe bien dans l'interface et son application à la majorité des utilisateurs. Dans notre exemple précédent, nous avions:
| Scénario | Approuver un article prêt à être publié. |
De plus, comme nous savons que les articles ont une date de publication, nous pouvons également indiquer: Il s’agit de notre premier scénario car, dans la plupart des cas, les articles à approuver doivent être prêts à être publiés. Mais cela soulève la question suivante: que se passe-t-il lorsqu'un article n'est pas prêt pour la publication et que l'éditeur y accède? Devraient-ils même pouvoir accéder à ces articles?
Toutes ces questions font partie du processus de conception et vous connaîtrez probablement les réponses lorsque vous passerez rapidement aux exigences en matière de documentation. La bonne nouvelle est que l'utilisation de scénarios dans la documentation de votre récit vous aidera à les structurer et, dans de nombreux cas, à vous aider à évaluer vos propres conceptions, en veillant à ce qu'elles soient conçues et diffusées correctement.
Voyons comment notre histoire se concrétiserait avec les scénarios supplémentaires:
| Fonctionnalité | Autoriser les éditeurs à examiner les articles avant leur publication finale et à y apposer leur approbation. |
| Scénario 1 | Approuver un article prêt à être publié.
|
| Scénario 2 | Accéder à un article qui n'est pas prêt pour la publication.
|
| Scénario 3 | Approuver un article dont la date d'échéance est passée
|
| Scénario 4 | Désapprobation d'un article dont la date de publication est ultérieure
|
| Scénario 5 | Désapprobation d'un article publié
|
Selon la fonctionnalité, plusieurs scénarios peuvent être envisagés. Leur clé est de les garder courts pour pouvoir les décrire et les tester facilement. Vous pouvez également essayer de les regrouper, en utilisant des dénominateurs communs. Par exemple, si plusieurs scénarios partagent la même condition préalable, vous pouvez l'encapsuler dans un «arrière-plan» utilisable par plusieurs scénarios. Par exemple:
| Contexte | L'auteur a soumis un article pour publication et l'éditeur a accédé à la vue de modification d'article. |
| Scénario 1 | Approuver un article prêt à être publié.
|
| Scénario 2 | Approuver un article dont la date d'échéance est passée.
|
| Scénario 3 | Désapprobation d'un article dont la date de publication est ultérieure.
|
Un problème commun qui se pose lors de la documentation des exigences est de décider de l'ordre dans lequel le faire. La raison en est 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 la simple interaction consistant à «approuver» un article, de nombreux éléments doivent être prêts:
Une approche permettant de documenter les exigences de chacune de ces dépendances consiste à les enregistrer en tant que différentes fonctionnalités pouvant ensuite être hiérarchisées en fonction de leur valeur métier..
| Fonctionnalité | La description | Priorité |
|---|---|---|
| Système d'alerte | L'interface utilisateur doit pouvoir renvoyer un message de succès, ainsi qu'un message d'échec, en cas de problème système. | 2 |
| Système de marquage | L'interface utilisateur doit pouvoir “marquer” les articles comme approuvés. | 4 |
| Système de publication | L’UI doit pouvoir afficher l’article selon la logique métier «publiée». | 1 |
| Système de notifications | Les notifications système doivent être activées pour que les auteurs puissent être alertés lorsque l'approbation est effectuée. | 3 |
Ensuite, vous pouvez créer une histoire «d'intégration» pour les rassembler. Par exemple, une user story pour le système de marquage aimerait ceci:
| Fonctionnalité | Autoriser les utilisateurs et le système à marquer des articles selon un état donné (non publié, approuvé, publié ou archivé). |
| Scénario 1 | Marquage d'un article comme non publié.
|
| Scénario 2 | Marquage d'un article comme approuvé.
|
| Scénario 3 | Marquage d'un article comme publié.
|
| Scénario 4 | Marquage d'un article comme archivé.
|
Dans le récit d'intégration, vous pouvez faire référence au récit de balisage si les détails de 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 leur publication finale et d’imprimer leur approbation.. |
| Scénario 1 | Approuver un article prêt à être publié.
|
Le but est d'éviter de répéter une documentation qui non seulement consomme du temps inutilement, mais aussi qui peut devenir désynchronisée.
Nous avons vu à quel point les histoires d'utilisateurs axés sur le comportement peuvent être utiles pour rédiger des exigences ciblées, concises, mais aussi complètes et descriptives. Dès la phase de conception, cet outil peut constituer un bon début pour les ingénieurs en assurance qualité lors de la rédaction de scénarios de test réels..
Outre ces avantages considérables, les histoires d'utilisateurs axés sur le comportement peuvent être transformées en tests fonctionnels à l'aide de logiciels tels que Cucumber ou Lettuce. L’idée de base est qu’une fois que les histoires sont écrites en utilisant la syntaxe Gherkin, vous pouvez les placer dans un .fonctionnalité fichier à l’intérieur de votre application, puis exécutez-les comme tests pour montrer s’ils ont réussi ou non. Pour un tutoriel détaillé sur l'utilisation de Lettuce pour une implémentation Python, consultez le tutoriel de David Sale:
Écrire des user stories en utilisant les principes de BDD peut servir à communiquer en détail les exigences commerciales et de conception, avec une approche centrée sur l'utilisateur, tout en utilisant un langage lisible par l'homme mais pouvant être étendu pour l'interprétation de logiciels. De plus, il peut être utilisé pour tester:
Cela signifie plus de couches pour que les bogues puissent passer, ce qui évite les lacunes dans la conception et protège mieux votre application des défaillances de bogues..
Accentsconagua