Comment rédiger des critères d'acceptation : exemples et bonnes pratiques (2024)

Chez Mobindustry, nous opérons avec uneAgileapproche. Cela signifie que nous utilisons des composants Agile comme les user stories et les critères d'acceptation. Les équipes et les organisations performantes ont ces composants dans leurs backlogs de produits, et elles savent comment les créer et les utiliser efficacement. Si tu veuxcréer un MVP, les critères d'acceptation sont l'une des choses les plus importantes à réfléchir.

Si votre backlog de produit manque de user stories et de critères d'acceptation - ou s'ils ne sont pas clairement définis - vous risquez que vos attentes ne convergent pas avec la réalité.Histoires d'utilisateurset les critères d'acceptation sont chargés de représenter la manière dont l'utilisateur final utilisera votre application et la manière dont votre équipe de développement doit exécuter chaque tâche de développement. Lorsque nous commençons à travailler sur un nouveau produit, notre équipe collabore avec le client pour définir les user stories.

Une user story est une description courte et simple d'une fonctionnalité de produit du point de vue d'une personne qui souhaite utiliser cette fonctionnalité. Les user stories sont utilisées pour définir le backlog de produit dans un workflow de développement Agile.

Le backlog de produit est essentiellement une collection d'histoires d'utilisateurs qui informent les spécifications fonctionnelles et le développement de fonctionnalités pour un produit ou un service particulier. Les user stories se composent de trois parties : unepersonnagede l'utilisateur pour lequel l'histoire est écrite, une description defonctionnalitél'utilisateur a besoin, et une explication de labesoinla caractéristique satisfait.

Voici comment rédiger des user stories et des critères d'acceptation :

En tant qu'(utilisateur), je veux une (fonctionnalité) pour pouvoir (satisfaire un besoin).

Voyons à quoi pourrait ressembler une user story. Nous prendrons Airbnb comme exemple. Imaginons à quoi pourrait ressembler une histoire d'utilisateur typique pour un produit comme Airbnb.

"En tant qu'utilisateur, je souhaite rechercher une destination afin de pouvoir réserver un logement dans une ville étrangère."

Définition des critères d'acceptation

Maintenant, nous devons nous assurer que les user stories sont correctement complétées et répondent aux demandes du client.

Les critères d'acceptation sont les conditions qu'unproduit logicieldoit satisfaire pour être accepté par un utilisateur, un client ou, dans le cas d'une fonctionnalité au niveau du système, le système consommateur.

Les critères d'acceptation sont un ensemble d'énoncés, chacun avec un résultat clair de réussite/échec, qui peuvent être mesurés et spécifier à la fois les exigences fonctionnelles et non fonctionnelles.

La rédaction des critères d'acceptation est importante non seulement pour établir ce que le client attend du produit, mais aussi pour le processus de développement. Naturellement, différentes personnes voient le même problème sous des angles différents. Des critères d'acceptation bien définis fournissent une vue uniforme de la fonctionnalité que vous envisagez de mettre en œuvre.

Tout le monde devrait pouvoir accéder à un tableau Scrum, saisir un élément du backlog produit, lire les critères d'acceptation et voir clairement tout ce qui doit être complété pour que cet élément particulier soit déplacé vers la colonne terminé. Les critères d'acceptation vous indiquent ce qui doit être fait pour qu'une partie particulière d'un produit soit finie.

Pourquoi avons-nous besoin de critères d'acceptation?

Définir les limites

Les critères d'acceptation aident l'équipe de développement à définir les limites d'une user story. Ils servent de forme de confirmation que l'application fonctionne comme prévu, ce qui signifie que la user story est complète.

Parvenir à un consensus

Les critères d'acceptation permettent à l'équipe de développement d'être sur la même page que le client. Ils informent l'équipe de développement des conditions exactes à remplir et garantissent que le client sait à quoi s'attendre de l'application.

Rationalisation des tests d'acceptation

Les critères d'acceptation sont à la base des tests d'acceptation des user stories. Chaque critère d'acceptation doit être testé indépendamment et avoir des scénarios clairs de réussite ou d'échec.

Planification et estimation

Les critères d'acceptation vous permettent de répartir les user stories entre les tâches afin qu'elles soient correctement évaluées et planifiées.

Décrire des scénarios négatifs

Les critères d'acceptation peuvent exiger que le système identifie un mot de passe faible et empêche un utilisateur de continuer, par exemple. La saisie d'un format de mot de passe incorrect est un exemple de scénario négatif dans lequel un utilisateur saisit des données incorrectes ou se comporte de manière inattendue. Les critères d'acceptation identifient ces scénarios et expliquent comment le système doit y répondre.

Qui rédige les critères d'acceptation ?

La rédaction des critères d'acceptation permet d'établir une compréhension commune entre le propriétaire du produit et l'équipe de développement en ce qui concerne la résolution du problème d'un client ou la création de fonctionnalités de produit. Mais qui devrait rédiger les critères d'acceptation ? Étant donné que les critères d'acceptation concernent le client et l'équipe, ils doivent être rédigés soit par le client, soit par un membre de l'équipe.

Chez Mobindustry, nos analystes métiers écrivent tous les critères d'acceptation des user stories. Les analystes commerciaux comprennent les besoins du client et ce que les développeurs doivent savoir pour répondre aux exigences du projet.

Les critères d'acceptation sont documentés et confirmés avant le début du projet, car l'équipe et le client doivent s'entendre sur les résultats qui répondront aux exigences du client.

Principaux défis de la rédaction des critères d'acceptation

Le principal défi de la rédaction de bons critères d'acceptation est de maintenir un équilibre entre le détail et l'étendue. Comme on dit, il est difficile de faire quelque chose de simple, vous devez donc garder votre documentation AC concise et claire, mais pas restrictive.

Parlons de certaines erreurs courantes et de leurs solutions, afin que vous puissiez trouver votre propre meilleure façon d'écrire des critères d'acceptation.

Rédaction des critères d'acceptation au fur et à mesure du développement.Vous devez avoir une documentation AC en place avant le début du processus de développement afin que tous les membres de l'équipe soient sur la même longueur d'onde concernant les besoins des utilisateurs. Les développeurs doivent décider des solutions techniques en fonction des critères d'acceptation, et elles doivent être convenues au préalable.

Trop rétrécir le CA.Vos critères d'acceptation doivent être concrets, mais pas trop étroits. N'oubliez pas qu'ils n'indiquent que la direction et non le moyen d'y arriver, alors laissez suffisamment de liberté à vos développeurs pour trouver la solution.

Aller trop loin dans les détails techniques.Rédigez vos critères d'acceptation dans un langage simple et communément compris par vos spécialistes techniques, parties prenantes, concepteurs et autres membres de votre équipe.

Utiliser la voix passive et les constructions négatives.Écrivez votre AC comme si un utilisateur parlait avec vous. Par exemple, "Je veux pouvoir trouver ma destination sur une carte et consulter les horaires de travail directement à partir de là". Évitez d'utiliser « non » et écrivez des phrases positives partout où c'est possible.

Exemples de user stories avec critères d'acceptation

Maintenant que vous avez une compréhension claire de ce que sont les user stories et les critères d'acceptation, examinons quelques exemples.

Exemple 1

Histoire de l'utilisateur: En tant qu'utilisateur, je souhaite pouvoir m'inscrire au service afin de pouvoir commencer mes achats en ligne.

Critères d'acceptation:

• Les utilisateurs ne peuvent soumettre un formulaire qu'en remplissant tous les champs obligatoires.
• L'e-mail fourni par l'utilisateur ne doit pas être fourni par un service de messagerie gratuit.
• Les soumissions de la même IP ne peuvent être faites que trois fois en 30 minutes.
• Les utilisateurs reçoivent des e-mails de notification après s'être enregistrés avec succès.

Exemple 2

Histoire de l'utilisateur: En tant qu'utilisateur, je peux accéder aux notifications sur mon appareil immédiatement après les avoir reçues.

Critères d'acceptation:

• Glisser/appuyer sur une notification amène l'utilisateur directement au message.
• La vue affiche la conversation - si le nouveau message était une réponse, il s'affiche au-dessus de l'original.
• Le nombre de messages est mis à jour.
• Un message est marqué comme lu après son affichage.

Types de critères d'acceptation

Il existe plusieurs types de critères de sélection. Cependant, les types suivants sont les plus populaires.

Critères d'acceptation axés sur le scénario.

Ce type de critères d'acceptation est présenté sous forme de scénario et illustre chaque critère. De plus, ils sont largement utilisés par les équipes Agile car ils leur permettent de répondre aux exigences et d'utiliser des scripts pour les tests d'acceptation manuels et automatisés.

Critères d'acceptation orientés règles

Contrairement aux critères d'éligibilité basés sur des scénarios, les scénarios de critères d'éligibilité basés sur des règles sont présentés sous forme de liste.

7 conseils pour rédiger de bons critères d'acceptation

Les critères d'acceptation ne sont pas faciles à rédiger. Malgré le format simple, écrire le texte est un défi. Voici sept conseils pour vous aider à éviter les erreurs courantes lors de la rédaction des critères d'acceptation ou de la révision des critères rédigés par un membre de votre équipe.

Documenter les critères avant le début du processus de développement

De cette façon, l'équipe est plus susceptible de saisir à l'avance tous les besoins du client. Au départ, il suffit de définir des critères pour un petit nombre de user stories pour compléter les backlogs de deux sprints. Les critères d'acceptation documentés sont ensuite utilisés par les développeurs pour planifier le processus technique.

Ne pas rendre les critères d'acceptation trop étroits

Des critères d'acceptation trop spécifiques laissent peu de marge de manœuvre aux développeurs. Pour éviter cela, rappelez-vous que les critères d'acceptation doivent être une expression d'intention et non une décision finale. De plus, des critères d'acceptation étroits peuvent ne pas prendre en compte toutes les actions des utilisateurs.

Gardez vos critères réalisables

Les critères d'acceptation efficaces définissent une quantité minimale raisonnable de fonctionnalités que vous pouvez fournir. Mais si vous continuez à décrire tous les petit* détails, il y a un risque que votre équipe se retrouve bloquée sur des centaines de petites tâches.

Éviter les critères d'acceptation trop larges

Des critères d'acceptation larges rendent une user story vague. Des critères d'acceptation efficaces doivent décrire la portée des travaux afin que les développeurs puissent correctement planifier et estimer leurs efforts.

Évitez les détails techniques

Les critères d'acceptation doivent être rédigés en langage simple. Vos parties prenantes et vos responsables n'ont peut-être pas de formation technique. Par conséquent, l'utilisation d'un langage simple rendra les critères compréhensibles pour tout le monde.

Parvenir à un consensus

Le même problème peut être résolu de différentes manières par les membres de l'équipe et les parties prenantes en fonction de leurs points de vue. Assurez-vous de communiquer vos critères d'acceptation aux parties prenantes et aux membres de l'équipe et de parvenir à un accord mutuel.

Rédiger des critères d'acceptation testables

Cela donnera aux testeurs la possibilité de s'assurer que toutes les exigences sont remplies et permettra aux développeurs de savoir si la user story est complète.

Comment rédiger les critères d'acceptation

Voici cinq règles générales qui vous aideront à résoudre les problèmes de formulation des critères d'acceptation. Ces règles vous permettront de gagner un temps précieux et d'établir une entente entre le propriétaire du produit et l'équipe de développement.

Règle n°1 : évitez le « non »

« Non » signifie « en aucun cas », et par conséquent, aucun délai ne sera suffisant pour vérifier le respect d'une telle condition. Si vous réécrivez l'exigence sans utiliser « non », elle sera plus claire et, surtout, vérifiable.

Exemple:

Histoire de l'utilisateur

Ne le faites pas: En tant qu'utilisateur, je ne souhaite pas avoir à saisir mon mot de passe à chaque fois que j'accède à mon compte.
Faire: En tant qu'utilisateur, je souhaite que mon mot de passe soit mémorisé et renseigné automatiquement afin de pouvoir accéder à mon compte sans ressaisir mon mot de passe.

Critères d'acceptation

Ne le faites pas: Le système ne doit pas tomber en panne.
Faire: Le système doit avoir une disponibilité d'au moins 90 %.

Exception

Vous pouvez utiliser "not" dans les critères d'acceptation pour introduire une objection logique, telle que "le formulaire de connexion ne doit pas être rouge". Dans la plupart des cas, cela s'appliquera aux exigences non fonctionnelles. Dans cet exemple, nous formulons une contrainte qui peut être facilement vérifiée si la gamme de nuances de rouge est clairement définie (par exemple, spécifiée au format RVB).

Règle #2 : Utilisez la voix active

La voix active est lorsque le sujet dans une phrase est l'interprète de l'action. Si l'entité responsable de l'exécution de l'action n'est pas clairement indiquée, il sera difficile de savoir qui ou quoi doit exécuter l'action, et il vous sera plus difficile de vérifier si une exigence est remplie.

Exemple:

Histoire de l'utilisateur

Ne le faites pas: En tant qu'acheteur en ligne, je souhaite que des filtres soient appliqués pour trouver ce que je veux.
Faire: En tant qu'utilisateur, je souhaite appliquer des filtres de recherche pour pouvoir trouver des éléments.

Critères d'acceptation

Ne le faites pas: L'identité du client doit être confirmée. (On ne sait pas qui ou quoi est responsable de la confirmation de l'identité du client.)
Faire: Le Accounting_System doit confirmer le Customer_Indentity. (Notez que les définitions des termes "Accounting_System" et "Customer_Indentity" doivent être ajoutées au glossaire.)

Règle n°3 : évitez d'utiliser des pronoms (en particulier ceux qui ne sont pas définis)

Utilisez des noms plutôt que des pronoms lorsque vous faites référence à des éléments référencés dans d'autres exigences. Les pronoms doivent être évités car ils peuvent introduire une ambiguïté.

Ceci est particulièrement important lorsque les critères d'acceptation sont stockés dans des outils de gestion des exigences (tels que Jira) sous forme d'instructions distinctes qui ne sont pas nécessairement organisées. Utilisez toujours des noms au lieu de pronoms et vous éviterez ce problème.

Exemple:

Histoire de l'utilisateur

Ne le faites pas: En tant que membre du site, je souhaite partager des informations me concernant afin que les autres puissent les voir.
Faire: En tant que membre du site, je souhaite ajouter une description de profil afin que les autres puissent en savoir plus sur moi.

Critères d'acceptation

Ne le faites pas: Le contrôleur doit transmettre au conducteur l'itinéraire de la journée. Il doit être livré au moins 8 heures avant le quart de travail.
Faire: Le contrôleur doit envoyer le Driver_Itinerary pour la journée au conducteur au moins 8 heures avant le Driver_Shift.

Règle n°4 : évitez les conjonctions

Les conjonctions sont des mots et des expressions tels que "et", "ou", "mais" et "ainsi que" qui combinent des phrases simples en phrases complexes. Leur utilisation dans les exigences est généralement le signe qu'une exigence peut être décomposée en plusieurs exigences distinctes.

Exemple:

Histoire de l'utilisateur

Ne le faites pas : En tant que concepteur d'interface utilisateur, je souhaite créer et afficher un problème afin de savoir quoi tester.
Faire: En tant que concepteur d'interface utilisateur, je souhaite créer un problème afin de savoir quoi tester. / En tant que concepteur d'interface utilisateur, je souhaite afficher un problème afin de savoir quoi tester.

Critères d'acceptation

Ne le faites pas: L'utilisateur doit être de confiance ou non.
Faire: Le Security_System doit catégoriser chaque utilisateur comme Trusted ou Not_Trusted.

Exception

« Et », « ou » et « non » peuvent être utilisés pour décrire des conditions logiques et ajouter des qualificatifs.

Règle n°5 : Évitez les absolus inaccessibles

Un absolu (tel que 100 % de disponibilité) est inaccessible. Réfléchissez à la manière de vérifier l'indicateur : sera-t-il possible de prouver que le niveau de disponibilité du système est exactement de 100 % ? Et même si un tel système pouvait être créé, pouvez-vous vous le permettre ?

Évitez les mots « tous », « toujours » et « jamais », car la vérification de ces exigences absolues nécessitera un nombre infini de tests.

Exemple:

Histoire de l'utilisateur

Ne le faites pas: En tant que voyageur, je souhaite connaître ma position précise mise à jour en temps réel afin de ne pas me perdre. (« Temps réel » peut être interprété de différentes manières. Par exemple, il peut être vu comme un absolu (l'absence de tout retard), qui ne peut être atteint et qui n'est pas vérifiable.)
Faire: En tant que voyageur, je veux connaître ma position précise, mise à jour chaque seconde, pour ne pas me perdre.

Critères d'acceptation

Ne le faites pas: Le système doit avoir une disponibilité de 100 %. (100 % est un absolu qui ne peut être atteint et ne peut pas être vérifié.)
Faire: Le système doit avoir une disponibilité d'au moins 98 %.

Modèles prêts à l'emploi pour la rédaction des critères d'acceptation

Vous pouvez soit rédiger vous-même l'AC, soit utiliser des modèles prêts à l'emploi. Voici plusieurs ressources qui fournissent des modèles téléchargeables.

• Clarifiéfournit des modèles Excel pour écrire les critères d'acceptation dans leur pack de test logiciel
• Ah !vous donnera un modèle pratique pour écrire des user stories et des AC
• PowerSlidesfournit un modèle PPT avec différentes conceptions parmi lesquelles vous pouvez choisir pour écrire à la fois des histoires d'utilisateurs et des critères d'acceptation

Résumé rapide des critères d'acceptation

Nous espérons que cet article a mis en lumière les meilleures façons d'écrire des critères d'acceptation et des témoignages d'utilisateurs. Voici les principaux plats à emporter:

• Les critères d'acceptation sont les conditions qu'un produit logiciel doit remplir pour être accepté par un utilisateur, un client ou, dans le cas d'une fonctionnalité au niveau du système, le système consommateur.
• Les critères d'acceptation doivent être documentés et remplis avant le début d'un projet, car l'équipe et le client doivent s'entendre sur les résultats qui répondront aux exigences du client.
• N'oubliez pas que les critères d'acceptation doivent être une expression d'intention et non une décision finale.
• Les critères d'acceptation efficaces définissent un minimum raisonnable de fonctionnalités.
• De bons critères d'acceptation doivent décrire la portée du travail afin que les développeurs puissent correctement planifier et estimer leurs efforts.
• Les critères d'acceptation doivent être rédigés en langage simple.
• Assurez-vous de communiquer vos critères d'acceptation aux parties prenantes et aux membres de l'équipe et de parvenir à un accord mutuel.
• Lors de la rédaction des critères d'acceptation, évitez d'utiliser « non », des conjonctions et des absolus inaccessibles. Formuler des phrases à la voix active.

Si vous souhaitez créer des critères d'acceptation et des user stories pour votre application mobile ou si vous avez des questions à ce sujet, contactez Mobindustry pour une consultation gratuite.