CODEWITHSUNDEEP
bddbehaviorscenarios
Kle
Kle

Reputation: 1043

Behavior Driven Development (BDD) scenario vs user scenario or use case differences?

I m new at BDD. So I had some questions about scenarios? What is the differences between BDD Scenarios and User scenario? Is there a clear difference from the conventional “user scenario” or “use case” so called? Can you please explain more?

Upvotes: 3

Views: 2489

Answers (1)

Star
Star

Reputation: 111

Since you just mentioned "Conventional User Scenarios" which is a little vague, I'll assume you mean the user stories description:

As a [Role]
I want [Goal]
So that [Result/Benefit]

That is the user story description, which would need scenarios that describe how the user is supposed to behave with the system. This can be done in a variety of ways. One of them could be BDD. Now, BDD doesn't particularly define how one must write their scenarios. All it defines is that

  • there should be clear communication between developers, testers and Business
  • this communication should be in an easy format which is understandable by all
  • examples should be used in communication to specify & clear requirements

The first point assures that there's no ambiguity in requirements and feedback is quickly shared among the three team. The second point assures that everyone uses a language that is understandable by all and that leaves no ambiguity for everyone. For example, a tester might write a scenario as 

When I drop a file to FTP location, then it's FTP information should be validated and file should be sent

but Business might no be familiar with what FTP/FTP location/ information validation is. A better approach would be to make your scenarios in Domain Specific Language (DSL), something like

When a file is dropped in send location, then validate it's credentials and send the file

One way to achieve the above two points is by using Gherkin language. Gherkin is a DSL language which has a syntax as follows:

Given [Precondition]
When [Action]
Then  [Result]

Expanding on our previous example:

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

As you can see, it's almost the same as our previous example, except that we have used an example of a user dropping the file, thereby reducing ambiguity a great deal; also language used in not technical in nature, but understandable by all.

The same could have been written as Verify that file FTP credentials are valid and fie is sent through FTP But here we might miss out on precondition or maybe final result required might be ambiguous. And language is more technical so business wouldn't understand it. And business hasn't provided any example to explain what they really want, so our scenarios might not be related to what the business really wants.

To avoid all this confusion, BDD recommends that Business, tester and developer all sit together and write down features and scenarios together. This allows cross questions, examples and quick feedback. Another advantage of this is that with business' involvement in making these scenarios, the focus of the scenarios would be more towards the behavior of the system and not the technical aspect of it. If a system is such that A enters a room and B leaves, then no matter what processes are being done in the room, the input and output, or the behavior is same. System should not break just because someone changed room from square to circle. That's the process change, not behavior change.

Also, check out this post here.

Upvotes: 7

Related Questions