Je suis nouveau chez BDD. Donc j'ai eu quelques questions sur les scénarios? Quelles sont les différences entre les scénarios BDD et le scénario utilisateur? Existe-t-il une différence nette par rapport au "scénario utilisateur" ou au "cas d'utilisation" classique? Pouvez-vous s'il vous plaît expliquer plus?Scénario de développement basé sur le comportement (BDD) par rapport au scénario utilisateur ou aux différences de cas d'utilisation?
Puisque vous venez de mentionner « Scénarios utilisateur classiques », qui est un peu vague, je suppose que vous voulez dire les histoires de l'utilisateur Description:
En tant que [rôle]
Je veux [But]
Pour que [Résultat/Avantage]
Ceci est la description de l'user story, qui nécessiterait des scénarios décrivant comment l'utilisateur est censé se comporter avec le système. Cela peut être fait de plusieurs façons. L'un d'eux pourrait être BDD. Maintenant, BDD ne définit pas particulièrement comment on doit écrire leurs scénarios. Tout ce qu'il définit est que
Le premier point garantit qu'il n'y a pas d'ambiguïté dans les exigences et que la rétroaction est rapidement partagée entre les trois équipes. Le deuxième point assure que tout le monde utilise un langage compréhensible par tous et qui ne laisse aucune ambiguïté pour tout le monde. Par exemple, un testeur peut écrire un scénario comme
When I drop a file to FTP location, then it's FTP information should be validated and file should be sent
mais pas d'affaires pourrait connaître ce lieu FTP/FTP/validation de l'information est. serait de faire vos scénarios dans le domaine Langue spécifique (DSL), quelque chose comme
When a file is dropped in send location, then validate it's credentials and send the file
Une façon d'atteindre les deux points ci-dessus est en utilisant un langage Gherkin Une meilleure approche. Cornichon est un langage DSL qui a une syntaxe comme suit:
Given [Precondition]
When [Action]
Then [Result]
L'expansion de notre exemple précédent:
Given user drops file "sample.txt"in "Send File" location
When the credentials for file "sample.txt" are validated
Then the "sample.txt" should be sent to "Receive File" location
Comme vous pouvez le voir, il est presque la même chose que notre exemple précédent, sauf que nous avons utilisé un exemple de suppression d'un fichier par un utilisateur, ce qui réduit considérablement l'ambiguïté; De plus, la langue n'est pas de nature technique, mais compréhensible par tous.
La même chose aurait pu s'écrire Verify that file FTP credentials are valid and fie is sent through FTP Mais ici, nous pourrions manquer une condition préalable ou peut-être que le résultat final requis pourrait être ambigu. Et le langage est plus technique, donc les entreprises ne le comprendraient pas. Et les entreprises n'ont fourni aucun exemple pour expliquer ce qu'elles veulent vraiment, de sorte que nos scénarios pourraient ne pas être liés à ce que l'entreprise veut vraiment. Pour éviter toute cette confusion, BDD recommande aux entreprises, aux testeurs et aux développeurs de s'asseoir ensemble et d'écrire ensemble des fonctionnalités et des scénarios. Cela permet des questions croisées, des exemples et des retours rapides.Un autre avantage de ceci est qu'avec l'implication des entreprises dans la réalisation de ces scénarios, l'objectif des scénarios serait davantage axé sur le comportement du système et non sur l'aspect technique de celui-ci. Si un système est tel que A entre dans une pièce et que B s'en va, alors quels que soient les processus en cours dans la pièce, l'entrée et la sortie, ou le comportement est le même. Le système ne doit pas se casser juste parce que quelqu'un a changé de place de carré en cercle. C'est le changement de processus, pas le changement de comportement.
En outre, consultez cet article here.
Veuillez donner quelques exemples de "Scénarios BDD" et de "scénario d'utilisateur". Je ne suis pas sûr de la définition de «scénario utilisateur conventionnel», donc je ne peux pas essayer de vous aider. J'ai besoin de plus d'exemples ou de contexte. Probablement les deux. –