What is the definition of key examples when I write stories with BDD eligibility criteria

Question

After reading on BDD (Behavior driven development) and how to write good user stories with relevant eligibility criteria. I am a little confused when it comes to examples / acceptance criteria. BDD encourages us to work in cross functional teams using Prod owner, BA, QA, DEV, etc., to define these criteria. In addition, the BDD encourages us to adhere to key examples when we define these eligibility criteria. My question is: what do key examples mean to you? Does this include examples that try to violate other eligibility criteria for a particular story in order to demonstrate the boundaries of the story?

For example, let's say we have a story called “Register a user,” and all that is required to register is to provide a valid email address. One key example will obviously be

GIVEN I am an unregistered user WHEN I provide [e-mail] THEN I should be notified that my registration was successful 

What about other examples trying to invalidate this business rule? Should we also give examples such as

 GIVEN I am an unregistered user WHEN I provide aa~=233@xy ;;z.com THEN I should be notified that my email address is not valid 

My example may be too simplistic, because it probably makes sense to include a second example in this story. However, for more complex stories, we ourselves discuss whether a concrete example is “key examples” or not. The QA team, in particular, comes up with very good examples of how to test boundaries, verify, etc. However, quite often we discuss whether these types of examples are considered key examples. Some argue that these types of examples do not add any commercial value and therefore should not be part of the story. Any thoughts on this?

Answer 1

"does not add any business values"

This question should occur in relation to this function as a whole - all interested parties should agree on whether any feature adds any value to the business - if it is not fulfilled, then it will not be realized. I don’t think you can say, well, that this function is not so sexy, so do not add a specification to it, we will just add it to the code. This is correct in your example; you need to specify the edges and business rules.

BDD is an indication of each function of the application (both user and system interactions) so that everyone agrees on the goals and vision of what needs to be done and what is done. Good side effect - you get a set of tests that confirm your specifications.

I would not want to be in a situation where something was delivered, and the end user said "what is it, we did not ask for it," or the end user asked "we asked for it, where is it?" - These questions should always be answered by referring to your specifications.

Answer 2

It is important to have examples for all cases of margins, and not just obvious business cases.

Everyone should be able to trust the test suite. If you omit extreme cases, QA people will not trust your trials (and this is true).

Answer 3

After a little digging. I found the following article that discusses the concept of key examples pretty well

http://cuke4ninja.com/sec_collaborative_feature_files.html

Answer 4

I would push details down to step definitions:

 GIVEN I am an unregistered user WHEN I provide an email address in a valid format THEN I should be notified that my registration was successful GIVEN I am an unregistered user WHEN I provide an email address in a invalid format THEN I should be notified that my registration was not successful 

In the definitions of steps, you can specify valid and invalid addresses. You can work with the tester / QA to make a decision about this.

With this approach, you do not expose the small implementation details to the product owner, but you still check the behavior.