Critères d’acceptation : objectifs, formats et meilleures pratiques

La réussite de chaque projet dépend de la capacité d’une équipe de développement à répondre aux besoins de ses clients. La communication entre le client et l’équipe de développement joue un rôle essentiel dans la livraison d’une solution qui correspond aux exigences du produit et du marché. Les problèmes surviennent quand les clients expliquent leurs besoins de manière trop vague et que l’équipe ne peut pas obtenir des exigences claires.

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 cliquables (fantaisie, fiction, histoire, roman, etc.). Après deux semaines de développement, vous recevez une barre de recherche où les utilisateurs doivent taper la catégorie qui les intéresse, au lieu de parcourir les catégories pré-répertoriées. Bien que cela fonctionne également, le but initial était d’afficher toutes les catégories et laisser l’utilisateur final les explorer.

C’est à ce moment qu’une documentation logicielle de haute qualité peut aider à éviter le problème. User stories et critères d’acceptation sont les principaux formats de documentation des exigences. Une user story est une description en langage naturel d’une fonctionnalité. Elle est généralement accompagnée de critères d’acceptation.

Critère d’acceptation (ISO 24765) : le critère de sortie que doit satisfaire un composant ou un système de façon à être accepté par un utilisateur, client ou une autre entité autorisée.

Les critères d’acceptation 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 user story et définissent le comportement des fonctionnalités du point de vue de l’utilisateur final. Des critères d’acceptation bien rédigés aident à éviter des résultats inattendus à la fin d’une phase de développement et garantissent que toutes les parties prenantes et tous les utilisateurs sont satisfaits de ce qu’ils obtiennent.

1. Principaux objectifs des critères d’acceptation

Clarifier les exigences des parties prenantes est un objectif de haut niveau. Pour rendre les objectifs des critères d’acceptation plus clairs, nous allons les diviser en plusieurs éléments :

1.1 Clarification des features scope

Les critères d’acceptation définissent les limites des user stories. Ils fournissent des détails précis sur les fonctionnalités qui aident l’équipe à comprendre si user story est terminée et fonctionne comme prévu.

1.2 Décrire les scénarios négatifs (non passants)

Vos critères d’acceptation peuvent exiger que le système reconnaisse les entrées de mot de passe dangereuses et empêche un utilisateur de continuer. Le format de mot de passe invalide est un exemple de scénario dit négatif lorsqu’un utilisateur effectue des entrées non valides ou se comporte de manière inattendue. Les critères d’acceptation définissent ces scénarios et expliquent comment le système doit y réagir.

1.3 Amélioration de la communication

Les critères d’acceptation synchronisent les visions du client et de l’équipe de développement. Ils garantissent 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é.

1.4 Rationalisation des tests d’acceptation

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

1.5 Feature estimation

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

2. Types et structures des critères d’acceptation

Les critères d’acceptation peuvent être écrits dans différents formats. Il y en a deux, les plus courants, et la troisième option consiste à concevoir votre propre format :

Orienté scénario (Given/When/Then)
Orienté règles (Checklist)
Formats personnalisés

2.1 Critères d’acceptation orientés scénario

Le format d’écriture des critères d’acceptation orienté scénario est connu sous le nom de type Given / When / Then (GWT).

Étant donné (Given) une condition préalable
Quand (When) je fais de l’action
Alors (Then) j’attends un résultat

Cette approche a été héritée du développement axé sur 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. Cela réduit également le temps consacré à la rédaction des cas de test, car le comportement du système est décrit à l’avance.

Chaque critère d’acceptation écrit dans ce format comporte les déclarations suivantes:

Scénario – le nom du comportement qui sera décrit
Étant donné – l’état initial du scénario
Quand – action spécifique que l’utilisateur effectue
Ensuite – le résultat de l’action dans “Quand”
Et – utilisé pour continuer l’une des trois déclarations précédentes

Lorsqu’elles sont combinées, ces instructions couvrent toutes les actions qu’un utilisateur entreprend pour terminer une tâche et connaître le résultat.

Regardons quelques exemples :

Exemple 1

User story : en tant qu’utilisateur, je souhaite pouvoir récupérer le mot de passe sur mon compte, afin de pouvoir accéder à mon compte en cas d’oubli du mot de passe.

Scénario: mot de passe oublié

Given: L’utilisateur a accédé à la page de connexion

When : L’utilisateur a sélectionné l’option de mot de passe oublié

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

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

Given : L’utilisateur a reçu le lien par e-mail

When : l’utilisateur a parcouru le lien reçu dans l’e-mail

Then : 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 de l’argent à mon compte dans un guichet automatique afin de pouvoir recevoir l’argent de mon compte rapidement et à différents endroits.

Critère d’acceptation 1:

Given : que le compte est solvable

And : la carte est valide

And : le distributeur contient de l’argent

When : le client demande de l’argent

Then : assurez-vous que le compte est débité

And : assurez-vous que l’argent est distribué

And : assurez-vous que la carte est retournée

Critère d’acceptation 2:

Given : que le compte est à découvert

And : la carte est valide

When : le client demande de l’argent

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

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

Format des critères d’acceptation axés sur les règles

Dans certains cas, il est difficile d’intégrer des critères d’acceptation dans la structure given/when/then (étant donné / quand / alors). Par exemple, ne serait guère utile dans les cas suivants :

Vous travaillez avec des user stories qui décrivent les fonctionnalités de niveau système qui nécessitent d’autres méthodes d’assurance qualité.
Le public cible des critères d’acceptation n’a pas besoin de détails précis sur les scénarios de test.
Les scénarios GWT ne conviennent 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 critiques.

Vous pouvez résoudre ces cas avec le format de critères d’acceptation orienté règles.

La forme orientée règles 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. Voyons un exemple.

Exemple 3

User story : en tant qu’utilisateur, je souhaite utiliser un champ de recherche pour saisir une ville, un nom ou une rue, afin de 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 démarre une fois que l’utilisateur clique sur « Rechercher »
Le champ contient un espace réservé avec un texte en gris : “Où allez-vous ?”
L’espace réservé disparaît une fois que l’utilisateur commence à taper
La recherche est effectuée si un utilisateur saisit une ville, un nom d’hôtel, une rue ou tous
La recherche est en anglais, français, allemand et ukrainien
L’utilisateur ne peut pas taper plus de 200 symboles
La recherche ne prend pas en charge les symboles spéciaux (caractères). 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.»

2.2 Autres formats

La plupart des user stories peuvent être couvertes par les 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 en 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 exemple de comportement du système :

3. Rôles du Product Owner (PO)

Certains critères sont définis et écrits par le Product Owner (PO) lors de la création du backlog de produit. Et les autres peuvent être précisés par l’équipe lors des discussions sur les user stories après la planification du sprint. Il n’y a pas de recommandations strictes concernant le choix de la personne responsable de la rédaction des critères. Le client peut les documenter s’il a une connaissance approfondie de la documentation technique et des produits. 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 le PO, Business analyste, ou un Chef de projet.

4. Principaux défis et meilleures pratiques de rédaction des critères d’acceptation

Les critères d’acceptation semblent très faciles à rédiger. Malgré leurs formats simplistes, l’écriture pose un défi pour de nombreuses équipes. Examinons plus en profondeur les meilleures pratiques qui permettent d’éviter les erreurs courantes.

4.1 Documenter les critères avant le développement

Les critères d’acceptation doivent être documentés avant le début du développement proprement dit. 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 de user stories pour remplir les backlogs de deux sprints (si vous pratiquez Scrum ou une méthode similaire). Ils doivent être approuvés par les deux parties. Ensuite, les critères d’acceptation documentés sont utilisés par les développeurs pour planifier le processus technique.

4.2 N’utilisez pas des critères d’acceptation trop restrictifs

Les critères d’acceptation peuvent être bien trop spécifiques, avec peu ou pas de marge de manœuvre pour les développeurs. Pour éviter cela, n’oubliez pas que les critères d’acceptation doivent transmettre l’intention, mais pas une solution finale. De plus, un critère d’acceptation restrictif peut être dépourvu de plusieurs comportements utilisateur qui ne sont pas couverts.

4.3 Définissez des critères réalisables

Les critères d’acceptation efficaces définissent les fonctionnalités minimums que vous êtes en mesure de fournir. Mais si vous décrivez tous les petits détails, il y a un risque que votre équipe se retrouve coincée avec des centaines de petites tâches.

4.4 Gardez des critères d’acceptation mesurable et pas trop vagues

Des critères d’acceptation trop vagues rendent une user story compliquée. Les critères d’acceptation efficaces doivent définir l’étendue des travaux afin que les développeurs puissent planifier et estimer correctement leurs efforts.

4.5 Évitez les détails techniques

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

4.6 Atteindre un consensus

Le même problème peut être résolu différemment par une équipe et des parties prenantes, selon leurs points de vue. Assurez-vous d’avoir communiqué votre AC aux parties prenantes et de parvenir à un accord mutuel. La même chose s’applique aux membres de l’équipe. Tout le monde doit examiner les critères d’acceptation et confirmer qu’il comprend et accepte chaque ligne.

4.7 Ecrire des critères d’acceptation testables

Cela permettra aux testeurs de vérifier que toutes les exigences ont été respectées. Sinon, les développeurs ne comprendront pas si la user story est terminée.

5. Conclusion

Ne négligez pas les critères d’acceptation car, étant simples et accessibles, ils 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 éventuellement aident 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 expérimentez le vôtre. Différents types de fonctionnalités des user stories peuvent éventuellement nécessiter de différents formats et tests. Essayez le vôtre !

Source et images : altexsoft.com