Imaginez que vous demandiez à votre équipe de développement de permettre aux utilisateurs de rechercher un produit dans une librairie en ligne par catégories. Vous vous attendez à avoir une interface claire avec les liens de catégorie pour les cliquer dessus (fumeur, non-fiction, historique, etc.) Après deux semaines de développement, vous recevez une fonction de barre de recherche où les utilisateurs doivent taper dans la catégorie qui les intéresse, au lieu de naviguer dans 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 plus avant.
Pour éviter que de tels problèmes ne se produisent et fournissent une solution qui réponde aux besoins du client et corresponde aux exigences du marché, il doit y avoir une documentation logicielle de haute qualité. Voici quand les histoires des utilisateurs et les critères d'acceptation (AC) entrent en jeu car ils sont les principaux formats d'exigences de documentation
Alors que les utilisateurs visent à décrire ce que l'utilisateur veut exactement faire le système, l'objectif des critères d'acceptation est d'expliquer les conditions auxquelles une histoire d'utilisateur spécifique doit satisfaire. Dans ce billet, nous nous concentrerons sur les critères d'acceptation: nous clarifierons leurs objectifs, leurs types et la manière dont ils devraient être écrits (à titre d'exemples).
Critères d'acceptation, expliqués
Quels sont les critères d'acceptation et leur rôle dans les projets?
Les critères d'acceptation (AC) sont les conditions auxquelles un produit logiciel doit satisfaire pour être accepté par un utilisateur, un client ou d'autres systèmes. Ils sont uniques pour chaque histoire d'utilisateur et définissent le comportement des caractéristiques du point de vue de l'utilisateur final.
Les critères d'acceptation
Les critères d'acceptation bien rédigés permettent d'éviter des résultats inattendus à la fin d'une phase de développement et de s'assurer que toutes les parties prenantes et tous les utilisateurs sont satisfaits de ce qu'ils obtiennent.
Un aspect important des critères d'acceptation est qu'ils doivent être définis avant que l'équipe de développement commence à travailler sur une histoire particulière d'utilisateurs. Sinon, il y a une chance décente que les produits ne répondent pas aux besoins et aux attentes d'un client.
Critères d'acceptation principaux objectifs
La clarification des exigences des parties prenantes est un objectif de haut niveau. Pour rendre les objectifs de l'AC plus clair, nous allons les décomposer.
Rendre la portée de la fonctionnalité plus détaillée. AC définit les limites des histoires des utilisateurs. Ils fournissent des détails précis sur la fonctionnalité qui aident l'équipe à comprendre si l'histoire est terminée et fonctionne comme prévu.
Décrire des scénarios négatifs. Votre AC peut exiger que le système reconnaisse les entrées dangereuses de mots de passe et empêche un utilisateur d'aller plus loin. Le format de mot de passe invalide est un exemple d'un scénario dit négatif lorsqu'un utilisateur entre ou se comporte de manière inattendue. AC définisse ces scénarios et explique comment le système doit y réagir.
Mise en place 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 que l'on attend de la fonctionnalité.
Rationalisation des essais d'acceptation. AC sont à la base des tests d'acceptation de l'histoire de l'utilisateur. Chaque critère d'acceptation doit être testé indépendamment et donc avoir des scénarios de réussite ou d'échec clairs. Ils peuvent également être utilisés pour vérifier l'histoire via des tests automatisés.
Réalisation d'évaluations de caractéristiques. Les critères d'acceptation précisent ce qui doit être développé par l'équipe. Une fois que l'équipe a des exigences précises, elle peut diviser les histoires des utilisateurs en tâches qui peuvent être correctement estimées.
Étant donné que différentes personnes peuvent avoir des points de vue et des idées de solution différents concernant un problème, il est nécessaire de créer une vision unifiée de la manière dont la fonctionnalité devrait être mise en œuvre. C'est exactement ce que font les critères d'acceptation clairement écrits.
Types et structures de critères d'acceptation
Compte tenu de la tâche initiale et de la complexité des exigences, les critères d'acceptation peuvent être rédigés sous différentes formes, à savoir:
- axé sur les scénarios (le modèle Given/When/Then);
- à l'état de référence (le modèle de liste de contrôle); et
- formats personnalisés.
Le plus souvent utilisé, le premier et le deuxième formats ont des structures très spécifiques, nous allons donc principalement nous concentrer sur elles. Cependant, vous pouvez trouver que d'autres formats conviennent mieux à votre produit, nous les aborderons donc brièvement.
Critères d'acceptation axés sur les scénarios
Comme son nom l'indique, le format orienté scénario est le type de critères d'acceptation qui se présente sous la forme de scénario et illustre chaque critère. Il est abordé à travers la séquence Given/When/Then (GWT) qui ressemble à ceci:
- En raison d'une condition préalable
- Quand je fais une action
- Puis j'attends un peu de 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 caractéristique particulière. Il réduit également le temps passé à l'écriture de cas de test car le comportement du système est décrit à l'avance.
Le modèle de critères d'acceptation dans ce format comprend les mentions suivantes:
- Scénario – le nom du comportement qui sera décrit
- Compte tenu de l'état d'avancement du scénario
- Quand – une action spécifique que l’utilisateur effectue
- Ensuite, le résultat de l’action dans « Quand »
- Et – utilisé pour poursuivre l'une des trois déclarations précédentes
Le modèle de critères d'acceptation dans le format Given/When/Then
Lorsqu'elles sont combinées, ces déclarations couvrent toutes les actions qu'un utilisateur prend pour mener à bien une tâche et faire l'expérience du résultat.
Regardons quelques exemples.
Exemple 1
L'histoire de l'utilisateur :
Récupérer l'exemple des critères d'acceptation par mot de passe
Scénario: Mot de passe oublié
- Donné: L'utilisateur navigue vers la page de connexion
- Quand : L'utilisateur sélectionne l'option «mot de passe oublié»
- Et : Saisir un e-mail valide pour recevoir un lien pour la récupération du mot de passe
- Ensuite : Le système envoie le lien vers l'e-mail saisi
- Donné: L'utilisateur reçoit le lien via l'e-mail
- Quand: L'utilisateur navigue à travers le lien reçu dans l'e-mail
- Ensuite: le système permet à l'utilisateur de définir un nouveau mot de passe
Exemple 2
En tant qu'utilisateur, je veux pouvoir demander l'argent de mon compte sur un distributeur automatique de billets afin de pouvoir recevoir l'argent de mon compte rapidement et à différents endroits.
« Demander de l'argent sur le compte à un ATM » exemple de critères d'acceptation, scénario 1
Scénario 1 : Demande d'espèces d'un compte solvable
- Compte tenu du fait que le compte est solvable
- Et : la carte est valide
- Et: le distributeur contient de l'argent liquide
- Quand: le client demande l'argent liquide
- Ensuite: s'assurer que le compte est débité
- Et : veiller à ce que les espèces soient distribuées
- Et: s'assurer que la carte est retournée
«Requêtement d'argent sur le compte à un ATM» exemple de critères d'acceptation, scénario 2
Scénario 2: Demande d'argent liquide auprès d'un compte trop sollicité
- Compte tenu du fait que le compte est trop tiré
- Et : la carte est valide
- Quand: le client demande l'argent liquide
- Ensuite: s'assurer que le message de rejet est affiché
- Et: s'assurer que l'argent liquide n'est pas distribué
Comme vous pouvez le voir d'après les exemples, les critères d'acceptation orientés vers le scénario peuvent être très efficaces dans les tonnes de situations. Mais ils ne peuvent pas être considérés comme une solution universelle.
Format des critères d'acceptation axés sur les règles
Dans certains cas, il est difficile d'adapter les critères d'acceptation dans la structure Given/When/Then. Par exemple, le Gouvernement du pays ne serait guère utile pour les cas suivants:
- Vous travaillez avec des histoires d'utilisateurs 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 de GWT ne correspondent pas aux 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 traiter ces cas avec le format AC orienté règle.
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 de puces. Jetons un coup d'oeil à un exemple.
Exemple
En ,
Critères d'acceptation de l'interface de recherche
- Le champ de recherche est placé sur la barre supérieure
- La recherche démarre une fois que l'utilisateur clique sur « Recherche »
- 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 tout combiné.
- 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 des symboles spéciaux (caracres). Si l'utilisateur a tapé un symbole spécial, afficher le message d'avertissement: «L'entrée de recherche ne peut pas contenir de symboles spéciaux».
Autres formats
La plupart des histoires d'utilisateurs peuvent être couvertes de deux formats mentionnés ci-dessus. Cependant, vous pouvez inventer vos propres critères d'acceptation étant donné qu'ils servent leurs objectifs, qu'ils sont clairement rédigés en anglais clair et qu'ils ne peuvent pas être mal interprétés. Certaines équipes utilisent même du texte en clair.
Par exemple, vos critères peuvent être spécifiés comme un exemple de comportement du système:
Un ensemble simple d'AC pour les mots de passe forts de Mark Levison
Cette approche fournit des lignes directrices claires pour les tests de fonctionnalité par mot de passe.
Modèles de critères d'acceptation prêts à l'emploi
Toutes les formules susmentionnées pour écrire des critères d'acceptation sont faciles à suivre et, ce qui est plus important, efficace. Ils s'assurent que l'équipe de développement comprend la tâche et que l'histoire de l'utilisateur sera correctement mise en œuvre.
Si vous avez besoin de modèles de critères d'acceptation téléchargeables pour remplir rapidement les informations nécessaires et organiser vos histoires d'utilisateurs, les ressources suivantes seront utiles.
- Klariti propose le modèle MS Excel Acceptance Criteria Log dans le cadre du pack de modèles de test logiciel.
- Ahaa fournit quelques modèles qui rendront compte des histoires d'utilisateurs et des critères d'acceptation différents.
- PowerSlides comprend un modèle au format PPT avec six conceptions dynamiques permettant d'écrire des phrases d'histoire simples de l'utilisateur et des critères d'acceptation.
- Sur la carte des parties prenantes, vous pouvez télécharger le modèle d'exigences du projet Excel entièrement modifiable qui inclut des critères d'acceptation.
Maintenant que vous avez quelques exemples de critères d'acceptation et de modèles à portée de main, nous allons traiter qui devrait être chargé d'écrire ce genre d'exigences logicielles.
Rôles responsables et mode de création des critères d'acceptation
Certains des critères sont définis et rédigés par le propriétaire du produit lorsqu'il crée l'arriéré de produits. Et les autres peuvent être précisés par l'équipe lors des discussions d'histoires des utilisateurs après la planification du sprint.
Le processus commence par la hiérarchisation des histoires des utilisateurs et se termine par des détails de négociation avec l'ensemble de l'équipe.
Il n'existe pas de recommandations strictes pour choisir la personne responsable de l'élaboration des critères. Le client peut les documenter s'il possède de nombreuses connaissances techniques et en matière de documentation sur les produits. Dans ce cas, le client négocie les critères avec l'équipe pour éviter les malentendus mutuels. Dans le cas contraire, les critères sont créés par un propriétaire de produit, un analyste d'entreprise, un analyste des exigences ou un de .
Pour en savoir plus sur la planification des logiciels et la documentation, consultez notre vidéo.
Documentation logicielle, expliquée
Principaux défis et meilleures pratiques en matière de critères d'acceptation par écrit
Les critères d'acceptation semblent être très faciles à écrire. Malgré leurs formats simplistes, l'écriture pose un défi pour de nombreuses équipes. Examinons de plus près les meilleures pratiques qui permettent d'éviter les erreurs courantes.
Récupération des critères avant l'élaboration. Les critères d'acceptation doivent être documentés avant le début de l'évolution effective. De cette manière, l'équipe saisira probablement à l'avance tous les besoins des clients. Au début, il suffit de fixer les critères pour qu'un petit nombre d'histoires d'utilisateurs résorbent les arriérés de 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 l'AC trop étroit. Les critères d'acceptation peuvent être des options de manœuvre bien trop spécifiques pour les développeurs de vivres peu ou pas. Pour éviter cela, souvenez-vous que l'AC doit transmettre l'intention mais pas une solution finale. De plus, un AC étroit peut être réduit de comportements multiples qui ne sont pas couverts.
Gardez vos critères réalisables. Ce point se croise étroitement avec le précédent. Des critères d'acceptation efficaces définissent le minimum raisonnable de fonctionnalité que vous êtes en mesure de fournir. Mais au cas où vous succombriez à la description de tous les petits détails, il y a un risque que votre équipe soit coincée avec des centaines de petites tâches.
Maintenir l'AC mesurable et pas trop large. Des critères d'acceptation larges rendent l'histoire d'un utilisateur vague. Des critères d'acceptation efficaces doivent définir la portée des travaux afin que les concepteurs 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 clair. Cela leur permettra de comprendre clairement et facilement pour tous: vos parties prenantes ou vos gestionnaires n'ont peut-être pas suffisamment d'informations techniques.
Parvenir au 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 AC aux parties prenantes et de parvenir à un accord mutuel. Il en va de même pour les membres de l'équipe. Chacun doit revoir l'AC et confirmer qu'il comprend et est d'accord avec chaque ligne.
Ecrire 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.
Suivez ces conseils pour vous guider sur la façon d'exprimer votre AC.
Écrivez en voix active, à la première personne. La voix active est lorsque l'objet d'une phrase effectue l'action (verb). S'en tenir à la voix active est une recommandation courante dans le cadre de la méthodologie Agile. De cette façon, AC reflète les mots réels que l'utilisateur dirait. L'utilisation de la voix passive peut rendre peu clair qui a besoin de quoi. Au lieu d'écrire « Les filtres devraient être appliqués à la recherche », essayez de fournir une explication plus informative “L'utilisateur devrait être en mesure d'appliquer un ensemble de filtres pour trouver des éléments spécifiques”.
Évitez les phrases négatives. Il est toujours judicieux d'éviter d'utiliser l'adverbe « pas » car cela rend souvent les exigences peu claires et moins vérifiables. Bien que l'utilisation de «non» soit possible lorsqu'il est nécessaire de présenter des exigences uniques à la fonctionnalité du système. Il est dit: «Le formulaire de connexion ne doit pas être mis en évidence en rouge lorsque l'utilisateur entre des valeurs incorrectes».
Écrivez des phrases simples et concises. Il est préférable d'utiliser plusieurs phrases simples au lieu d'une phrase complexe. Moins il y a de mots et de conjonctions inutiles comme « mais », « et », « ainsi » et « ainsi que » dans vos critères d'acceptation, plus les exigences sont compréhensibles pour les équipes de développement.
Mot final
Ne négligez pas les critères d’acceptation car ils – étant simples et accessibles – résolvent de multiples problèmes à la fois. Ils documentent les attentes des clients, offrent une perspective d'utilisateur final, clarifient les exigences, évitent l'ambiguité et, à terme, aident à vérifier si les objectifs de développement sont atteints. Que vous utilisiez les méthodes Agile ou non, assurez-vous de choisir le meilleur format ou d'expérimenter avec vos propres méthodes. Différents types d'histoires d'utilisateurs et, en fin de compte, peuvent nécessiter différents formats et tester les nouveaux qui fonctionnent pour vous est une bonne pratique
