« Critères d'acceptation vs Scénarios » : différence entre les versions

De Wiki Agile
Aucun résumé des modifications
Aucun résumé des modifications
Ligne 34 : Ligne 34 :
Malgré les éléments « Étant donné / Given », « Lorsque / When » et « Alors / Then », il ne s'agit ''pas'' d'un scénario. Il s'agit de critères d'acceptation, c'est-à-dire une spécification complète de cet aspect du comportement, formulée sous forme de scénario. Souvent, je vois des gens rédiger des critères de ce type, puis se retrouver perplexes lorsqu'ils ne parviennent pas à les traiter comme un véritable scénario, c'est-à-dire en les discutant en détail, en en déduisant d'autres cas limites, en les automatisant, etc.<br/>
Malgré les éléments « Étant donné / Given », « Lorsque / When » et « Alors / Then », il ne s'agit ''pas'' d'un scénario. Il s'agit de critères d'acceptation, c'est-à-dire une spécification complète de cet aspect du comportement, formulée sous forme de scénario. Souvent, je vois des gens rédiger des critères de ce type, puis se retrouver perplexes lorsqu'ils ne parviennent pas à les traiter comme un véritable scénario, c'est-à-dire en les discutant en détail, en en déduisant d'autres cas limites, en les automatisant, etc.<br/>
<br/>
<br/>
Discuter des scénarios est, pour moi, l'aspect le plus important du BDD. C'est ainsi que nous découvrons si nous avons une compréhension mutuelle ou non, en utilisant des exemples spécifiques pour illustrer notre compréhension ou découvrir notre ignorance.<br/>
<br/>
Lorsque nous discutons des scénarios, il n'est pas toujours nécessaire de rédiger des scénarios pour tous les critères d'acceptation. Tant que les critères d'acceptation sont suffisamment clairs pour permettre de dériver facilement les scénarios pertinents, je recommande de les laisser tels quels jusqu'au moment où ils doivent être automatisés. Vous pouvez déterminer si les scénarios peuvent être dérivés en quelques secondes de conversation. Vous n'avez pas besoin de tout noter.<br/>
<br/>
Il est également possible de formuler les critères d'acceptation d'une autre manière :
Nous devrions être dans l'impossibilité de vendre des animaux plus jeunes que l'âge recommandé.
Vous pouvez désormais discuter des scénarios et identifier d'autres critères potentiels que vous auriez pu manquer :
Les clients doivent être encouragés à revenir lorsque l'animal est en âge d'être vendu.
Au fur et à mesure que vous discutez des scénarios, les informations dont nous avons besoin pour l'automatisation apparaissent, et les personnes impliquées dans ces discussions (généralement un développeur, un designer et un testeur) acquièrent une meilleure compréhension du domaine :
Étant donné que les lapins ne peuvent pas être vendus avant l'âge de 2 mois 
Étant donné que Fluffy, le lapin, est âgé d'un mois et demi 
Lorsque nous essayons de vendre Fluffy
Alors nous devrions être invités à dire au client : « Cet animal est trop jeune. Veuillez revenir dans 15 jours pour le récupérer. »
En discutant à la fois des critères d'acceptation et des scénarios, en posant des questions et en utilisant des scénarios pour illustrer les critères, nous en apprenons davantage sur notre domaine. Nous pouvons également les automatiser ultérieurement, ce qui permettra de fournir une documentation vivante et constituera des tests de non régression.<br/>
<br/>
Il existe une autre différence entre un scénario et des critères d'acceptation, voire un test d'acceptation. Vous pouvez demander à vos parties prenantes métier : « Pouvez-vous me donner un scénario dans lequel cela se produit ? » ou « Pouvez-vous me donner un exemple ? ». J'ai constaté que cela suscitait souvent des discussions plus utiles que « Pouvez-vous me donner les critères d'acceptation pour cela ? » ou « Pouvez-vous m'aider à déterminer comment tester cela ? ».<br/>
<br/>
Le langage BDD, et en particulier son vocabulaire, fournit un langage universel pour l'analyse et le développement.<br/>
<br/>
Maintenant, nous pouvons discuter.