OPOWER CONFIDENTIAL: DO NOT DISTRIBUTE
16 January 2012
Behavior Drivent
Development
OPOWER CONFIDENTIAL: DO NOT DISTRIBUTE
2 16 January 2012
User Story Test Acceptance and Behavior Driven
Development
Behavior Driven Development was developed by Dan North in 2003 as an
extension of Test Driven Development in order to provide a more accurate way
of taking user story features and translating them into requirements.
What is the goal of BDD?
• Drive application development based upon Business Value.
• Write tests before you write code.
• Work in small increments of work.
• Provide the development team an ability to refactor code quickly.
• Designed to illustrate a specific aspect of behavior of the
application.
» What are the Benefits of BDD?
• Reduce the time for code implementation.
• BDD/TDD can lead to more modularized, flexible, and extensible
code.
• Encourages close teamwork between the entire Project Team.
OPOWER CONFIDENTIAL: DO NOT DISTRIBUTE
3 16 January 2012
User Story Test Acceptance and Behavior Driven
Development
» Before There Was Code, a Background in BDD
» What is the BDD Process?
• Identify all the Acceptance Criteria (BDDT) that supports a User Story/Feature before
any code is written.
• Have a complete review of the generated BDD and obtain sign off from the entire
team before starting coding.
• Coding is complete, and a feature can be implemented, when all the Acceptance
Criteria passes.
» What are the Benefits of BDD?
• Creates business value, because only what is needed to support the feature is coded,
nothing more, nothing less.
• Quality increases when developers understand how the feature will be used.
• Sprint quality improves with Agile/BDD zero defect policy.
» What is Testing’s role in BDD?
• BDD acceptance criteria provides Developers with a clear understanding of what they
need to develop.
• QA is responsible for developing the Acceptance Criteria and example data
(permutations) to support User Stories/Features and then ensuring that a formal
review and sign off occurs.
OPOWER CONFIDENTIAL: DO NOT DISTRIBUTE
4 16 January 2012
BDD Training
» Acceptance Criteria – Part of the BDD Process
» What Documents are Used in Support of the User Story?
• Acceptance Criteria is written in support of the User Story/Feature
and any supporting requirements, Comps, Wireframes and
Annotations.
» When is Acceptance Criteria Written?
• Acceptance Criteria is written when the User Story/Requirements
are complete and will continue until the feature is complete and
fully tested.
• Typically follows an iterative process and is done as part of each
Sprint with development of BDD test scripts occurring during the
previous Sprint.
» Who Owns Acceptance Criteria?
• QA owns the Acceptance Criteria and it’s change management
process
» What is the preferred format for Acceptance Criteria written for the BDD Process?
• The acceptance criteria format that supports BDD is Given, When,
Then
OPOWER CONFIDENTIAL: DO NOT DISTRIBUTE
5 16 January 2012
» Acceptance Criteria – Step 1 – High Level Outline
» Goal: Create a list of scenarios that support the User Story/Feature
• Example: User Story Title – Customer Withdraws Cash from Account
• Example: User Story - As a customer, I want to withdraw cash from
an ATM,
so that I don t have to wait in line at the bank.
» I. Use a short descriptive When Naming Each Scenario
• Example: Scenario 1 - Account is in Credit
» II. Each Scenario should represent a Different Facet of the User
Story
• Example: Scenario 1 – Account is in Credit
• Example: Scenario 2 – Account is Overdrawn
» III. Identify All the Variables that need to be supported in the User
Story
• What are considered customers (personal, business, corporate)?
• What are considered accounts (savings, checking, credit)?
BDD Training
OPOWER CONFIDENTIAL: DO NOT DISTRIBUTE
6 16 January 2012
BDD Training
» Acceptance Criteria – Step 1 – High Level Outline
» WHY is the High Level Outline Important?
• Descriptive Acceptance Criteria - No one remembers what the
purpose of what 1.6 Scenario is.
• Identifying all the facets - establishes the boundaries of the Story/
Feature
• Identifying all the variables - establishes the scope of the Story/
Feature
• Positive/Negative Scenarios – Ensures that we are coding to support
Errors
• Encourages conversations
• Assists with Leveling the Story/Feature (Is it too big, too small,
inclusive)
• Identifying potential New Stories/Features, because of project
commitments or cross project dependencies:
– Not supporting Business Accounts in the 1
st
Release.
– Not supporting Savings Accounts in the 1
st
Release.
OPOWER CONFIDENTIAL: DO NOT DISTRIBUTE
7 16 January 2012
BDD Training
» GIVEN, WHEN, THEN – Step 2 – Stepping It Out
» Given - some initial context
• Example: User Type
• Example: Set Up any Preconditions
» When – An Event Occurs
• Submit a page, click a link, select an option
» Then – The Expected Response
» And – Use with Given, When or Then when multiple steps need to be
executed. Provides the ability to create smaller, more repeatable patterns.
OPOWER CONFIDENTIAL: DO NOT DISTRIBUTE
8 16 January 2012
BDD Training
Feature/Story: As a customer, I want to withdraw cash from an ATM,
so that I don t have to wait in line at the bank.
Scenario 1 Account is in Credit
Given Statement Given I m a customer with a valid account
And My Account is in Credit
Scenario 2 Account is Overdrawn
Given Statement Given I m a customer with a valid account
And My Account is Overdrawn
» The GIVEN Steps
OPOWER CONFIDENTIAL: DO NOT DISTRIBUTE
9 16 January 2012
BDD Training
» The GIVEN Steps
»
Identify steps that can be used in other scenarios and/or User
Stories/Features where possible.
»
Check with the variables and pre-conditions identified during Step
1 and make sure that they are included in the Given Statement
»
Add preconditions to the steps where the following phrasing needs
to be used (Or, But, If ….), meaning call out each variable in a
declarative fashion. If you wrote the Acceptance Criteria in the
following fashion:
»
Given I m a customer OR a Business Account with a valid card And
My Account is in Credit…
»
When the test is executed in this format, only 1 of the 2 variables
would potentially ever get tested.
OPOWER CONFIDENTIAL: DO NOT DISTRIBUTE
10 16 January 2012
BDD Training
User Story: As a customer, I want to withdraw cash from an ATM,
so that I don t have to wait in line at the bank.
Scenario 1 Account is in Credit
Given Statement Given I m a customer with a valid account
And My Account is in Credit
When Statement When I withdraw money from my account
Scenario 2 Account is Overdrawn
Given Statement Given I m a customer with a valid account
And My Account is Overdrawn
When Statement When I withdraw money from my account
Then WHEN Step
OPOWER CONFIDENTIAL: DO NOT DISTRIBUTE
11 16 January 2012
BDD Training
» The WHEN Steps
»
Keep the WHEN statement one specific action (step) as much as
possible.
•
Reason: If there are too many steps in the WHEN Statement,
the Given is not set up properly OR the User Story/Feature is
not broken down enough OR the scope of the Scenario is too
large.
»
Review WHEN statements with multiple steps and determine if
moving a step to the Given Statement works better:
•
Example: When there is cash in the ATM dispenser AND I
withdraw Cash from My Account.
•
cash in the dispenser is not an action and can be removed as
a pre-condition in the Given statement.
»
All the Scenarios for a User Story/Feature should have the same
WHEN statement. (It s the same behavior…)
•
Reason: If there are various WHEN statements throughout the
Acceptance Criteria, it usually means that the User Story/
Feature is not at the right level.
OPOWER CONFIDENTIAL: DO NOT DISTRIBUTE
12 16 January 2012
BDD Training
User Story: As a customer, I want to withdraw cash from an ATM,
so that I don t have to wait in line at the bank.
Scenario 1 Account is in Credit
Given Statement Given I m a customer with a valid account
And My Account is in Credit
When Statement When I withdraw money from my account
Then Statement Then my account should be debited
And requested amount should be dispensed
Scenario 2 Account is Overdrawn
Given Statement Given I m a customer with a valid account
And My Account is Overdrawn
When Statement When I withdraw money from my account
Then Statement Then I should receive an error message
And requested amount should not be dispensed
» The THEN Steps – What Happens?
OPOWER CONFIDENTIAL: DO NOT DISTRIBUTE
13 16 January 2012
BDD Training
» The THEN Steps
»
Keep the THEN statements to the Expected Results (Assertions) of
the Action Identified in the WHEN statement.
»
Keep Assertions for Different Elements on Separate Lines
•
Focus on Clarity, Re-Use, and Automation
OPOWER CONFIDENTIAL: DO NOT DISTRIBUTE
14 16 January 2012
BDD Training
» Using Parameters and Example Patterns for Permutations
»
I have multiple iterations to execute for my scenarios, do I have to write
out a scenario for each one?
•
No - You can use parameters and example tables to test all the
permutations of a scenario.
»
Where Can I use Parameters?
•
Parameters can be located in any of the Given, or Then Steps
•
Parameters can be used in the When statements provided it isn t used
to alter the actual action. (Example: withdraw money to deposit money)
»
How are Parameters Identified in the Steps?
•
Parameters are identified by enclosing a parameter name within carets
•
Example: <user>
»
What are the guidelines for parameter naming conventions?
•
Parameter names should be all lower case
•
Use _ to concatenate parameters with more than 1 descriptive word
OPOWER CONFIDENTIAL: DO NOT DISTRIBUTE
15 16 January 2012
BDD Training
User Story: As a customer, I want to withdraw cash from an ATM,
so that I don t have to wait in line at the bank.
Before After
Given I m a customer with a valid
checking account
And My checking account is in
Credit
When I withdraw money from my
checking account
Then my checking account should
be debited
And the requested amount should
be dispensed
Given I m a <user_type> with a valid <account_type>
account
And my <account_type> account is in credit
When I withdraw money from my <account_type> account
Then my <account_type> account should be debited
And the requested amount should be dispensed
» Using Parameters and Example Patterns for Permutations
OPOWER CONFIDENTIAL: DO NOT DISTRIBUTE
16 16 January 2012
BDD Training
» Using Parameters and Example Patterns for Permutations
»
Create an Example table with all the Data Permutations
»
Example tables should be below the Scenario with Example: as the header
»
Use the Pipe character as delimiters for the columns
»
Parameter names are the Column Headers
OPOWER CONFIDENTIAL: DO NOT DISTRIBUTE
17 16 January 2012
BDD Training
» I m Done, Now What Do I Do?
» Where Should I Store Acceptance Criteria?
•
You can use Wiki, RubyMine or any other type of tool that allows
for the generation of BDD in the format described.
•
Most initial work on acceptance criteria has tended to happen in
Wiki format.
»
Who Needs to Review the Scenarios?
•
Business, BA s, PM s and Developers are the key roles that
should review and approve Acceptance Criteria.
OPOWER CONFIDENTIAL: DO NOT DISTRIBUTE
18 16 January 2012
BDD Training
» I m Done, Now What Do I Do?
» What is the Purpose of the Review?
•
Enables additional conversations between BA, QA and
Development
•
Make final modifications to the Acceptance Criteria
»
What Happens When the Acceptance Criteria is Approved?
•
Acceptance Criteria is considered in a final state and ready for
development to start.
