The document describes a presentation by Sheetal Patel of The Vanguard Group on using Behavior-Driven Development (BDD) to improve communication between business and development teams. BDD uses examples in plain language to formalize requirements and validate software behavior. The Vanguard used BDD and Cucumber to engage business, development, and testing in collaborative sessions to define stories and test scenarios upfront. This helped address miscommunications over software features and reduced unused features from 64% to a lower percentage.
3. They Said, We Said:
Bridge the Communication Gap with
Behavior-Driven Development
TechWell DevOps East
November 2017
Sheetal Patel
sheetal-patel
@sheetalBAPS
About Vanguard
Vanguard’s core
purpose:
To take a stand for all
investors,
to treat them fairly,
and to give them the best
chance for investment
success.
Vanguard key facts
Founded May 1, 1975
Assets under
management
$4.4 trillion global assets under management
Number of funds 175 funds in the U.S. and 144 funds in markets outside
of the U.S.
Number of clients More than 20 million investors worldwide
Number of crew More than 14,000 crew worldwide
Number of IT crew Over 2,500
4. About Vanguard
A Virtual Company
– 370K log on per day
– 10 million phone calls
– 1.4 million e-mails
– 30-60K transactions per day
IT Teams
2000+ IT Professionals
200+ IT Agile Teams
About Me
IT Program Manager
“Shift Left”
B.S Computer Science
Held various roles in IT: Designer, Developer,
Scrum Master, Test Manager, Transformational
Program Manager
Leading team of Automation Engineer and
Developer to transform how we develop and
test software.
Advocate of Shift Left and Continuous Testing;
Empower teams to experiment
6. Causes of Miscommunications
• Misaligned Vocabularies
• Messy Thinking
• Faulty Definitions
• Government Speak and Legalese
Source: http://www.moneycrashers.com/causes-miscommunication-use-plain-language/
Traditional Method
Business Analyst gathers requirements and
documents it for each agile story
• Developers, testers, and the Business all come up
with different test scenarios
• The developer interprets the requirements
differently than the Business
• Story completion isn't clearly defined
No Common Understanding
7. Behavior Driven Development (BDD)
A framework to understand each
other “ubiquitous language”
Use English like sentence to express
behavior and outcomes of a system
Outside in Development
Cucumber is a Collaboration Tool
(Not an automation tool)
Business
Business Analyst, Product Owner
Development
Developer, Tech Lead
Testing
Tester, Automation Engineer
8. Collaboration Session – When?
Depends on the team
• Timebox the session
• Be consistent
• Do not start coding until collaboration session
Every day after scrum for 30 min
2 to 3 times a week for 45 min
Impromptu
• Whenever stories are ready to be picked up
How BDD Fits into Agile
BIG
idea
PO BSA PM
stories rules
FEATURES
EXAMPLE MAPPING
Rule Rule Rule
example example example
example example
?
?
?
StoryQuestions
Feature File
Given
When
Then
SCRUM
BSA
DEV
SAT
3 Amigos
Concrete
Examples
PO
BSA
PM
DEV TEST TL
Prod Ready
25 minutes
9. Scale it Enterprise Wide
Our Agile Journey
~2015
~2015 - present
~2015 - present
~ 2008
Product
Centered
Waterfall to Agile
Team Org
Changes Shifting Left
CI/CD, Products, LEAN
10. Traditional Requirements
Practice
Single Source of Truth – Hard pill to swallow
• Pride in documentation
• “This is how we have been doing for years”
• Financial Regulatory Industry
• Skill evolution
• Shift Left is about Testing not requirements
11. Common Resistance
• Collaboration is painful, takes too long
• Team member want to know why am I here, I just want to code.
- Developers tend to be introvert
• Want to use team members time effectively
• Team needs more desk time
• There are already too many meetings
Bottom Up
Top Down
Agile Teams
14. Use Cucumber for everything
Feature File are too technical or not able to automate
Given, When, Then created without collaboration
Not re-using step definitions – repeating across feature files
Organization of Feature file
Too much business logic in one Feature file
Not using Tags to drive automation runs
Common Pitfalls
Feature File Tips and Best Practices
• Feature Files should reflect “What” the system does not “How”
• Avoid Inconsistencies with Domain Language
• Use Tags
• Make Scenarios Independent and Deterministic
• Be DRY ( reuse step defs)
• Single When
• Use “Should” in the Then step
• Max 5 steps per scenario
• Write Given in past tense
15. Business vs Technical Requirements
Cucumber is not a silver bullet
• Conversation is more important than
the tool
Technical tests do not need to be
wrapped in cucumber
Program-level lessons learned
• Help individuals and teams be outcomes driven
• Change is evolution not revolution
• Need to repeat concepts as program - teams are at
different places
• Being “lean” to allow space to respond to needs has
helped us serve teams better
• At the end of the day we’re working with humans
26
16. References
• The world’s most misunderstood collaboration tool
• ATDD vs BDD … by Liz Keogh
• BDD By Example by Dan North
• Cucumber for Java Book
• The BDD Books Discovery Explore behavior using
examples by Gasper Nagy and Seb Rose
• Best Practice on Cucumber
Appendix: Example of Feature File
@AdHoc
Feature: Rule 100, 105, 1090, 111 Date Rules
Description: As an user, I select the review button and the date rules
run.
Scenario: Case 1 Rule100StartDateGreaterThanStopDate
Given Setup Withdrawal Plan
And current date of “10/16/2017”
And start date of “11/1/2017”
And stop date of “10/30/2017”
When Date rules are executed
Then the rule “100” fires and rule severity is “VALID”
@Business Capability
@IntegrationTest
Feature: Validate Rule 100 Start Date for setting up withdrawal plan.
Description: This feature is validating business rule for start date are
running and validating my entries for the withdrawal plan.
Business Rule: The Start Date cannot be after the Stop date for a
withdrawal plan.
Scenario: User is unable to setup withdrawal plan because start date is
after the stop date
Given User is setting up Withdrawal Plan
And current date is <current date>
And start date is <start date>
And stop date is <stop date>
When User reviews and validates the withdrawal plan setup
Then the rule “100” fires and rule severity is <severity>
Examples:
|current date | start date | stop date | severity |
|10/16/2017 | 11/1/2017| 10/30/2017| “ERROR” |