Since my last blog where I introduced how to document Acceptance Criteria using Behaviour Driven Development (BDD) (and more specifically the Gherkin language (Reference 1 & 2)), the team at Elabor8 have been debating a number of aspects regarding the use of BDD:
- What formatting rules apply to BDD, and what is “bad” practice”?
- Should BDD be used for all Acceptance Criteria that you may write?
- What level of detail should your Acceptance Criteria go to?
All of these points are great questions, and to provide an answer for each question would warrant a separate blog. However, what I will answer is that how you chose to document Acceptance Criteria using BDD is a decision made within the team that you are working in. The intent of BDD is that it should be simple and standardised. (Reference 3)
In this blog, I will begin to look into some of the pitfalls that can arise when writing requirements using BDD. I’ll do this by going through some additional Scenarios using the Facebook registration page example from last blog and my friend, Fred, as my user. (Reference 4)
Remember…the Title? How is it possible to write a “bad” Title?
As I continued thinking about the Scenarios that I could write for the Facebook registration page, I wondered what would happen when Fred does something he shouldn’t. What type of validation do we want for this process? This led me to start the scenario with the following title:
Scenario: Validation occurs when all fields are not populated
Given [some context],
When [some event],
Then [some outcome].
Now let’s have a think. Does this really explain the activity that the user will carry out? (Reference 3) Not exactly. What happened is that Fred did not provide all the mandatory fields. This should be the title of the Scenario. I have also attempted to avoid including “User” within the Scenario Title as it is assumed that they are performing whatever the activity is. Below is another crack at this Scenario.
Scenario: Failing to provide all mandatory fields prevents Facebook account creation
Given Fred is signing up for Facebook,
When Fred does not provide the following mandatory fields:
- First Name
- Last Name
- Re-enter email
- Password
- Birthday
- Gender
Then a Facebook account is not created,
And the ‘please enter all fields’ validation message is displayed.
You will notice that I have been quite specific with the fields, and the messaging that is displayed. This approach is referred to an ‘imperative’ approach to writing Acceptance Criteria. (Reference 5) This is a personal preference of mine, though others may disagree with this approach and may even say this is a pitfall of writing requirements, not just BDD. Check out this blog: ‘Imperative vs declarative scenarios in user stories’ if you’d like to look into this a bit more and come to your own conclusion.
Business Rules should be defined in your Scenarios, but where?
Another situation that I started to think about was, ‘What are the password requirements, and what if the User doesn’t meet them?’. This warrants another Scenario, which would go something like this:
Scenario: Providing an invalid password prevents Facebook account creation
Given Fred is signing up for Facebook,
When Fred provides a password with less than 6 characters in the ‘Password’ field,
And submits his request,
Then a Facebook account is not created
And the ‘Password requirements’ validation message for the ‘Password’ field is displayed.
Although it is perfectly fine to provide the Business Rules for Passwords in this scenario, shouldn’t it have been defined in the first scenario where Fred created his account successfully? Therefore, do we need to provide it again? Below are my revised versions of both scenarios of how the Business Rules are defined once. (And yes, this is Facebook’s only requirement for their password, which I was disappointed to find out. (Reference 6))
Scenario: Providing all required fields creates Facebook account
Given Fred is signing up for Facebook,
When he enters the following required details:
- First Name
- Last Name
- Re-enter email
- Password
- Birthday
- Gender
And the password provided has 6 or more characters,
And submits his request,
Then a Facebook account is created,
And account name is set as Fred’s email address,
And a confirmation email is sent to Fred.
Scenario: Providing an invalid password prevents Facebook account creation
Given Fred is signing up for Facebook,
When Fred provides a password that does not meet the password requirements
And submits his request,
Then a Facebook account is not created
And the ‘Password requirements’ validation message for the ‘Password’ field is displayed.
When using BDD to write your Acceptance Criteria (or however you document requirements) you can easily fall into the pitfalls of writing poor requirements. As you can see from this blog and my previous one, there is a lot to go through when learning how to write scenarios using BDD. From the basic structure and format, to how to write good requirements. There is certainly a lot more that can be covered. If you have any feedback or other suggested techniques, feel free to leave me a comment!
Shout out to Paul Velonis and Rupi Parmar for providing feedback and tips in developing this blog.
Additional reading that may be useful for you:
- A story explaining the difference and transition from Automation Testing to BDD to Specification by Example
- A blog explaining what BDD and Cucumber are, how they are two different things, but how they complement each other –
- An introduction to Gherkin and Cucumber, and how they can be used when using BDD
References:
- https://github.com/cucumber/cucumber/wiki/Given-When-Then
- http://dannorth.net/whats-in-a-story/
- https://www.facebook.com/
- http://benmabey.com/2008/05/19/imperative-vs-declarative-scenarios-in-user-stories.html
- https://www.facebook.com/help/124904560921566/
- https://github.com/cucumber/cucumber/wiki/Gherkin
