behavior-driven development (bdd) in context
DESCRIPTION
Behavior Driven Development (BDD) is an essential part of an Agile implementation. What makes BDD so powerful is that it brings all members of a scrum team together in the common goal of defining and releasing a quality product. The talk will provide an introduction to BDD: Gherkin, writing BDD scenarios, common frameworks. The second part of the talk will focus on how BDD fits into the SCRUM team. We will concentrate on ways BDD can be used to bridge the communication gap often present between various SCRUM players to enable them to become more productive by using a common language.TRANSCRIPT
Behavior-Driven Development in ContextALEXANDER KRESS
TORONTO AGILE AND SOFTWARE 2014
About meDevelopment manager at
Worked with BDD based process for 5 years
Blog devmngr.wordpress.com
Twitter @al3xkress
The sales pitchBDD is a natural addition to an Agile process
BDD enhances communication in an agile group
BDD leads to fewer bugs and misunderstandings
BDD is easy to introduce and understand
Lots of open source tools exists to support a BDD roll out
Mанифест“Аджаил”-манифест разработки программного обеспечения
Люди и взаимодействие важнее процессов и инструментовРаботающий продукт важнее исчерпывающей документацииСотрудничество с заказчиком важнее согласования условий контрактаГотовность к изменениям важнее следования первоначальному плану
То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.
ManifestoManifesto for Agile Software Development
Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan
That is, while there is value in the items onthe right, we value the items on the left more.
Common languagePO Dev QA
BDD in Context
From User Stories to BDD
The user story
As a Twitter user I would like to be able to post status updates In order to alert my followers to my latest doings
How would you break this up?
Let’s add TDDAdd a test
Run all tests and see if the new one fails
Write some code
Run the automated tests and see them succeed
Refactor code
Repeat
Writing tests is hardTo consider:
Which parts of the story do we want to test?
How do we structure test names to make them readable?
Would specific keywords in test names better define what they do?
What if we stopped thinking about tests and start thinking about behaviors?
Behavior-Driven Development
BDD is a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agilemethodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.
Dan North
Also see http://dannorth.net/introducing-bdd/
BDD in Context
Nuts and Bolts
Gherkin – the languageFeature: Some terse yet descriptive text of what is desired In order to realize a named business value.
Scenario: Some determinable business situation
Given some precondition
And some other precondition
When some action by the actor
And some other action
And yet another action
Then some testable outcome is achieved
And something else we can check happens too
Behat documentation
Step
Body
Gherkin – Elevating ExerciseFeature: As a condo resident I want to use any of the two available elevators to get from floor to floor
Scenario: Getting into an elevator from the ground floor
GivenAnd
WhenAndAnd
ThenAnd
Gherkin – Elevating ExerciseFeature: As a condo resident I want to use any of the two available elevators to get from floor to floor
Scenario: Getting into an elevator from the ground floor
Given No Elevator is present on the ground floor
And An elevator has not been requested
And Elevator A is not moving, currently at floor 2
And Elevator B is going up, currently at floor 5
When I press the up button
Then Elevator A gets the call
And Elevator A arrives on the ground floor and opens doors
Gherkin – Elevating ExerciseFeature: As a condo resident I want to use any of the two available elevators to get from floor to floor
Scenario: Getting into an elevator from the ground floor
Given [No] Elevators are present on the [ground] floor
And An elevator has not been requested
And Elevator [A] is not moving, currently at floor [2]
And Elevator [B] is going up, currently at floor [5]
When I press the [up] button
Then Elevator [A] gets the call
And Elevator [A] arrives on the [ground] floor and opens doors
From Gherkin to CodeJava
Ruby
Python Lettuce --->
PHP
JavaScript
and many others API
From Gherkin to Code
BDD Step: Elevator A gets the call
BDD Framework: ElevatorAPI.callElevator(ground level, direction up);
BDD Framework: If(Not ElevatorAPI.callAcknowledged(ground level))
Throw new Exception(“Elevator not called”);
BDD Step: I press the [up] button
DemoFeature: User status update
Scenario: Normal flow, user is able to login and post a status update
Given I go to "www" with url "/"
And I fill in element "//*[@id='signin-email']" with value "agiledemo"
And I fill in element "//*[@id='signin-password']" with value
"demoagile"
And I click element "//*[@id='front-
container']/div[2]/div[2]/form/table/tbody/tr/td[2]/button"
And I verify current url path is "/"
And I verify text present "AgileDemo"
And I verify text present "@agiledemo"
And I ensure text not present "Writing a BDD presentation"
When I fill in element "//*[@id='tweet-box-mini-home-profile']"
with value "Writing a BDD presentation"
And I click element
"//*[@id='timeline']/div[1]/div/form/div[2]/div[2]/button"
Then I verify text present "Writing a BDD presentation"
BDD in Context
Tying into Agile
Common languagePO Dev QA
Common languagePO Dev QA
BDD as acceptance
criteria
BDD as requirements definition and Test First Then
Code methodology
BDD as functionality
definition and automated regression
Working together
Anyone can write a BDD!
Working together
We define our own language!
Working togetherOptimizing resource utilization
PO
DEV QAScenarios and steps
Adding BDD to your process
Work with POs to understand and learn to love BDDs
Work with developers to read and write BDDs
QA will be your biggest fan
Working with BDDMind the testing pyramid (Mike Cohn)
Write BDDs in the same sprint
Refactor, Refactor, Refactor
BDD -> CI -> Regression report
UI
Service
Unit
Sample Regression Report
FAQHow to create coverage for an existing system?
Which BDD framework language to pick?
Why not use QTP or some version of clicks recorder/capture?
Do POs really need to speak “fluent” Gherkin?
Behavior-Driven DevelopmentBDD is a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agilemethodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.
Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan
Questions
More slides this way
RedFlagDeals Case StudyQ1 2012 – Large code base, no unit test, manual QA only
Q2 2012 – BDD framework introduced, QA start to dabble in it
Q3 2012 – First new component to have 100% BDD code coverage
Q1 2013 – BDD roll out across the team, PO training
Q2 2013 – Over 60% coverage on legacy components
Today – 587 scenarios, 10,353 steps (executed)Full nightly regressionCommit triggered BDD executionAgreed on failure review and correction processAutomation being part of the Definition of Done
More Gherkin featuresTags
@DailyRegression
Feature: rss
@STORY-5859 @Staging @Local
Scenario: check vital signs
Given I go to …
TablesAnd call the url “www.site.com” with parameters
| Parameter Name | Parameter Value |
| search_string | agile |
| page_number | 5 |
Refactoring stepsWhen I click on the Submit button
When I click on the Clear button
When I click on the “Publish” button
When I hover over the “Help” button
When I “hover over” the “Help” button
When I “hover over” the “Avatar” image
When I “hover over” the control “image” called “Avatar”
Using MocksBDD driven automation behaves like a user, easy to start clicking on “real” or staging apps/sites/etc.
Somewhere, someone had just put up a prod database snapshot
Closing pitchCommon language!
Code based documentation that is readable by all.
Better resource utilization in the team.
A natural extension to an Agile process.