temps de lecture: 7 minutes

le succès d’un projet dépend de la capacité d’une équipe de développement à répondre aux besoins de son client. La communication entre le client et l’équipe de développement joue un rôle essentiel dans la fourniture d’une solution qui répond aux exigences du produit et du marché., Les problèmes surviennent si les clients expliquent leurs besoins trop vaguement et que l’équipe ne peut pas comprendre les exigences claires et éventuellement le problème commercial derrière eux. Imaginez que vous demandiez à votre équipe de permettre aux utilisateurs de rechercher un produit dans une librairie en ligne par catégories. Vous vous attendez à avoir une interface claire avec des liens de catégorie pour cliquer dessus (par exemple fantasy, Non-fiction, historique, etc.) Après deux semaines de développement, vous recevez une fonction de barre de recherche où les utilisateurs doivent taper la catégorie qui les intéresse, au lieu de parcourir les catégories pré-listées., Bien que cela fonctionne également, votre objectif initial était d’exposer toutes les catégories disponibles et de permettre aux utilisateurs d’explorer davantage.

c’est à ce moment qu’une documentation logicielle de haute qualité pourrait aider à éviter le problème. Les User stories et les critères d’acceptation (AC) comme les principaux formats de documentation des exigences. Une histoire d’utilisateur est une description en langage naturel d’une fonctionnalité. Il est généralement accompagné de critères d’acceptation.

les critères D’acceptation (AC) sont les conditions qu’un produit logiciel doit remplir pour être accepté par un utilisateur, un client ou un autre système., Ils sont uniques pour chaque histoire d’utilisateur et définissent le comportement de la fonctionnalité du point de vue de l’utilisateur final. Des critères d’acceptation bien écrits permettent d’éviter des résultats inattendus à la fin d’une étape de développement et de s’assurer que toutes les parties prenantes et les utilisateurs sont satisfaits de ce qu’ils obtiennent.

les critères d’acceptation sont les exigences fonctionnelles de plus bas niveau

critères d’acceptation principaux objectifs

clarifier les exigences des parties prenantes est un objectif de haut niveau. Pour rendre les objectifs de L’AC plus clairs, décomposons-les.,

Détection de la portée de la fonctionnalité. AC définir les limites des user stories. Ils fournissent des détails précis sur les fonctionnalités qui aident l’équipe à comprendre si l’histoire est terminée et fonctionne comme prévu.

décrivant des scénarios négatifs. Yor AC peut exiger que le système reconnaisse les entrées de mot de passe non sécurisées et empêche un utilisateur d’aller plus loin. Le format de mot de passe non valide est un exemple de scénario négatif lorsqu’un utilisateur effectue des entrées non valides ou se comporte de manière inattendue. AC définir ces scénarios et expliquer comment le système doit réagir sur eux.

réglage de la communication., Les critères d’acceptation synchronisent les visions du client et de l’équipe de développement. Ils s’assurent que tout le monde a une compréhension commune des exigences: les développeurs savent exactement quel type de comportement la fonctionnalité doit démontrer, tandis que les parties prenantes et le client comprennent ce qui est attendu de la fonctionnalité.

rationalisation des tests d’acceptation. AC sont la base du test d’acceptation de l’histoire de l’utilisateur. Chaque critère d’acceptation doit être testable indépendamment et donc avoir un scénario de réussite ou d’échec clair. Ils peuvent également être utilisés pour vérifier l’histoire via des tests automatisés.

en Fonction de l’estimation., Les critères d’acceptation spécifient exactement ce qui doit être développé par l’équipe. Une fois que l’équipe a des exigences précises, elle peut diviser les histoires d’utilisateurs en tâches qui peuvent être correctement estimées.

critères D’acceptation types et structures

AC peut être écrit dans différents formats. Il y en a deux plus courants, et la troisième option consiste à concevoir votre propre format:

• orienté scénario (donné/quand/alors)
• orienté règle (liste de contrôle)
• formats personnalisés

comme le premier et le second formats ont des structures très spécifiques, nous nous concentrerons principalement sur eux., Cependant, vous constaterez peut-être que d’autres formats conviennent mieux à votre produit, nous les aborderons donc brièvement.

critères D’acceptation orientés scénario

le format D’écriture AC orienté scénario est connu sous le nom de type/When / Then (GWT) donné.

• étant donné une condition préalable
• lorsque je fais une action
• alors j’attends un résultat

Cette approche a été héritée du développement piloté par le comportement (BDD) et fournit une structure cohérente qui aide les testeurs à définir quand commencer et terminer le test d’une fonctionnalité particulière., Il réduit également le temps consacré à l’écriture de cas de test car le comportement du système est décrit en amont.,

chaque critère d’acceptation écrit dans ce format a les instructions suivantes:

1. scénario – le nom du comportement qui sera décrit
2. donné – l’état de début du scénario
3. lorsque – action spécifique que l’utilisateur effectue
4. puis – le résultat de l’action dans « When”
5. et – utilisé pour continuer l’une des trois instructions précédentes

prend pour terminer une tâche et l’expérience du résultat.

regardons quelques exemples.,

exemple 1

User story: en tant qu’utilisateur, je veux pouvoir récupérer le mot de passe sur mon compte, afin de pouvoir accéder à mon compte au cas où j’aurais oublié le mot de passe.,

lorsque: l’Utilisateur a sélectionné l’option Mot de passe oublié

et: a entré un e-mail valide pour recevoir un lien pour la récupération de mot de passe

puis: le système a envoyé le lien vers l’e-mail entré

donné: L’Utilisateur a reçu le lien via l’e-mail

lorsque: L’Utilisateur a navigué à travers le lien reçu dans l’e-mail

puis: le système permet à l’utilisateur de définir un nouveau mot de passe

exemple 2

user story: en tant qu’utilisateur, je veux pouvoir demander l’argent de mon compte dans ATM afin de pouvoir recevoir l’argent de mon compte rapidement et à différents endroits.,

et: le distributeur contient de l’argent

lorsque: le client demande l’argent

puis: s’assurer que le compte est débité

et: s’assurer que l’argent est distribué

et: s’assurer que la carte est retournée

critères D’acceptation 2:

étant donné: que le compte est à découvert

et: la carte est valide

lorsque:/p>

ensuite: assurez-vous que le message de rejet est affiché

et: assurez-vous que l’argent n’est pas distribué

format des critères d’acceptation orienté vers les règles

dans certains cas, il est difficile d’intégrer les critères d’acceptation dans la structure/when/then donnée., Par exemple, GWT ne serait guère utile pour les cas suivants:

• vous travaillez avec des user stories qui décrivent la fonctionnalité au niveau du système qui nécessite d’autres méthodes d’assurance Qualité.
• Le public cible pour les critères d’acceptation n’a pas besoin de détails précis sur les scénarios de test.
• Les scénarios GWT ne correspondent pas à la description des contraintes de conception et d’expérience utilisateur d’une fonctionnalité. Les développeurs peuvent manquer un certain nombre de détails importants.

Vous pouvez traiter ces cas avec le format AC orienté règle.,

La règle orientée forme implique qu’il existe un ensemble de règles qui décrivent le comportement d’un système. Sur la base de ces règles, vous pouvez dessiner des scénarios spécifiques.

habituellement, les critères composés à l’aide de ce formulaire ressemblent à une simple liste à puces. Jetons un coup d’oeil à un exemple.

exemple

User story: en tant qu’utilisateur, je souhaite utiliser un champ de recherche pour taper une ville, un nom ou une rue, afin de pouvoir trouver les options d’hôtel correspondantes.,

critères D’acceptation de L’interface de recherche de base

• le champ de recherche est placé sur la barre supérieure
• la recherche commence une fois que l’utilisateur clique sur « Rechercher”
• Le champ contient un espace réservé avec un texte de couleur grise: « Où allez-vous?”
• l’espace réservé disparaît une fois que l’utilisateur commence à taper
• La Recherche est effectuée si un utilisateur tape dans une ville, un nom d’hôtel, une rue ou tous combinés
• La Recherche est en Anglais, Français, allemand et ukrainien
• L’utilisateur ne peut pas taper plus de 200 symboles
• La recherche, Si l’Utilisateur a tapé un symbole spécial, affichez le message d’avertissement: « L’entrée de recherche ne peut pas contenir de symboles spéciaux.”

Autres formats

la Plupart des articles de l’utilisateur peuvent être couverts avec deux formats mentionnés ci-dessus. Cependant, vous pouvez inventer vos propres critères d’acceptation étant donné qu’ils servent leurs objectifs, sont écrits clairement dans un anglais simple et ne peuvent pas être mal interprétés. Certaines équipes utilisent même du texte brut.,

parfois, vos critères peuvent être spécifiés comme un exemple de comportement du système:

un simple ensemble de CA pour les mots de passe forts par Mark Levison pour agilepainpainrelief.com

cette approche fournit des directives claires pour le test des fonctionnalités de mot de passe.

rôles responsables et comment les critères d’acceptation sont créés

certains des critères sont définis et écrits par le product owner lorsqu’il crée le Backlog Produit. Et les autres peuvent être spécifiés par l’équipe lors des discussions user stories après la planification du sprint., Il n’y a pas de recommandations strictes pour choisir la personne responsable de la rédaction des critères. Le client peut les documenter s’il a une connaissance suffisante de la documentation technique et du produit. Dans ce cas, le client négocie les critères avec l’équipe pour éviter les malentendus mutuels. Sinon, les critères sont créés par un product owner, Business analyst, requirements analyst ou un chef de projet.,

le processus commence par la hiérarchisation de l’histoire de l’utilisateur et se termine par la négociation des détails avec toute l’équipe

principaux défis et meilleures pratiques d’écriture des critères d’acceptation

les critères Malgré leurs formats simplistes, l’écriture pose un défi pour de nombreuses équipes. Examinons de plus près les meilleures pratiques qui aident à éviter les erreurs courantes.

documenter les critères avant le développement. Les critères d’acceptation doivent être documentés avant le début du développement réel., De cette façon, l’équipe capturera probablement tous les besoins des clients à l’avance. Au début, il suffit de définir les critères d’un petit nombre d’user stories pour remplir les backlogs pour deux sprints (si vous pratiquez Scrum ou une méthode similaire). Ils doivent être convenus par les deux parties. Ensuite, les critères d’acceptation documentés sont utilisés par les développeurs pour planifier le processus technique.

NE FAITES PAS DE COURANT ALTERNATIF trop étroit. Les critères d’acceptation peuvent être beaucoup trop spécifiques vivant peu ou pas d’options de manœuvre pour les développeurs. Pour éviter cela, rappelez-vous que AC doit transmettre l’intention mais pas une solution finale., De plus, le courant alternatif étroit peut être privé de plusieurs comportements d’utilisateur qui ne sont pas couverts.

Gardez vos critères réalisable. Ce point croise étroitement le précédent. Les critères d’acceptation efficaces définissent la partie minimale raisonnable de fonctionnalités que vous êtes en mesure de fournir. Mais si vous succombez à décrire tous les petits détails, il y a un risque que votre équipe se retrouve coincée avec des centaines de petites tâches.

gardez AC mesurable et pas trop large. Les critères d’acceptation larges rendent une histoire d’utilisateur vague., Les critères d’acceptation efficaces doivent décrire la portée des travaux afin que les développeurs puissent planifier et estimer correctement leurs efforts.

Éviter les détails techniques. Comme nous l’avons mentionné, les critères d’acceptation doivent être rédigés en anglais simple. Cela les rendra clairs et faciles à comprendre pour tout le monde: vos parties prenantes ou gestionnaires peuvent ne pas avoir de formation technique.

en Arriver à un consensus. Le même problème peut être résolu différemment par une équipe et des parties prenantes, en fonction de leurs points de vue. Assurez-vous d’avoir communiqué votre C. A. aux parties prenantes et d’être parvenu à un accord mutuel., La même chose s’applique aux membres de l’équipe. Tout le monde doit examiner le C. A. et confirmer qu’ils comprennent et sont d’accord avec chaque ligne.

écrire AC testable. Cela permettra aux testeurs de vérifier que toutes les exigences ont été satisfaites. Sinon, les développeurs ne comprendront pas si l’histoire de l’utilisateur est terminée.

final word

ne négligez pas les critères d’acceptation car ils – étant simples et accessibles – résolvent plusieurs problèmes à la fois., Ils documentent les attentes des clients, fournissent un point de vue de l’utilisateur final, clarifient les exigences et évitent toute ambiguïté, et aident éventuellement l’assurance qualité à vérifier si les objectifs de développement ont été atteints. Que vous utilisiez ou non des méthodes agiles, assurez-vous de choisir le meilleur format ou d’expérimenter avec les vôtres. Différents types d’histoires d’utilisateurs et éventuellement de fonctionnalités peuvent nécessiter des fromats différents et tester les nouveaux qui fonctionnent pour vous est une bonne pratique.