Scrum Bangalore 13th meet up 13 june 2015 - behaviour driven development - vinay krishna - at prowareness
Behaviour Driven Development
Only an effective way to collaborate among three
Testing is just a by-product
• Often software development results surprises
at the end
– The business being unable to define the desired
– Ambiguity in the developer’s and tester’s
understanding of what needs to be built
– The business not able to understand the technical
challenges or unable to look at tester’s view on
• Three roles, three steps (document
specification, write code; develop the app,
write test plan; test the app)
• Three specs and three different lifecycles
– Mostly we maintain three different versions of
system’s need and many times find conflict among
• Functional Specification document
• Source Code
• Test case and test plan document
• Is it Bug?
• Is it Feature?
• No, it is Beature – Blame game
• Why beature?
– Misunderstanding at all level
– Lack of effective communication
– Difficulty in communication
– Lots of assumptions
• To understand the importance of
• To understand the challenge in
• Imagine we have been given a task to add an
‘include VAT and delivery cost to the total price of
the customer basket’ feature to an existing
eCommerce project with following set of business
– VAT is 20%
– Delivery cost for small basket (less than £20) is £3
– Delivery cost for medium basket (more than £20) is £2
• Can you use this information to deliver a working
• These rules do not specify whether to add VAT
before delivery cost to the basket total or
• How should you handle a situation where the
basket delivery cost is exactly £20?
• What happens if there are multiple products
in the basket?
What is BDD
• Exploring the unknown
• Sharing and understanding
• Individuals and interactions over processes
• Behavior Driven Development
– Describes what business wants the system to do
by talking through example behavior.
– Work from the outside-in to implement those
behaviors using the examples to validate the
• BDD is
– Example based
• To make sure that the whole team understand what's
wanted, the behavior is described in non-technical
– Gherkin language (given, when, then)
– Gherkin is a Business Readable, Domain Specific Language
that lets you describe software’s behaviour without
detailing how that behaviour is implemented.
– Simple syntax, few keywords
• Background, Tag
• Scenario, Scenario Outline
• Given, When, Then
– Localized to 35+ languages
• Every *.feature file conventionally consists of a
• Lines starting with the keyword Feature: (or its
localized equivalent) followed by three indented
lines starts a feature.
• A feature usually contains a list of scenarios.
• You can write whatever you want up until the first
scenario, which starts with Scenario: (or localized
equivalent) on a new line.
• You can use tags to group features and scenarios
together, independent of your file and directory
• Every scenario starts with the Scenario: keyword,
followed by an optional scenario title.
• Each feature can have one or more scenarios.
• Every scenario consists of a list of steps, which
must start with one of the keywords
– But or And
• The purpose of the Given steps is
– To put the system in a known state before the user (or external
system) starts interacting with the system (in the When steps).
• Avoid talking about user interaction in givens.
• If you have worked with use cases, givens are your
– To create records (model instances) or set up the database:
Given there are no users on site
Given the database is clean
– Authenticate a user (an exception to the no-interaction
recommendation. Things that “happened earlier” are ok):
Given I am logged in as "Everzet"
• The purpose of When steps is to describe the key
action the user performs
– Interact with a web page (Webrat/Watir/Selenium
interaction etc should mostly go into When steps).
– Interact with some other user interface element.
– Developing a library? Kicking off some kind of action
that has an observable effect somewhere else.
When I register
• The purpose of Then steps is to observe
• The observations should be related to the
business value/benefit in your feature
• The observations should inspect the output of
the system (a report, user interface, message,
– and not something deeply buried inside it (that has no
business value and is instead part of the
And / But
• If you have several Given, When or Then
steps, you can use And or But steps, allowing
your Scenario to read more fluently
• Steps may have some text or a table of data attached to them.
• Substitution of scenario outline values will be done in step data text or
table data if the “<name>” texts appear within the step data text or table
– Any text block following a step wrapped in “” lines will be associated with the
– You may associate a table of data with a step by simply entering it, indented,
following the step. This can be useful for loading specific required data into a
Given a set of specific users
| name | department |
| Barry | Beer Cans |
| Pudey | Silly Walks |
| Two-Lumps | Silly Walks |
Feature: Withdraw money from ATM
In order to avoid be in queue and save time
Customers should be able to
withdraw money from ATM all times
Scenario: Account has sufficient fund
Given Card is valid
And Account has 10000 Rs balance
When Customer enter 1000 Rs to withdraw
Then Customer should get 1000 Rs
AND Account should have 9000 remaining
AND system should return the card
• Think and identify more scenarios for same
• Discuss in your group each identified scenario
and write it using gherkin language
• Working together to find better solutions
• Use real-world examples to build a shared
understanding of the domain
• People understand requirements best using
• Examples clear up ambiguity and
• Examples expose missing requirements.
• Examples force everyone to think harder about a
• Shallow BDD
– Automation doesn’t mean, it’s BDD. Communication is
– It’s like people who say they’re doing BDD, but they just
use Cucumber/SpecFlow to automate scenarios without
actually talking to anyone
– That’s not Shallow BDD. That’s not BDD at all.
– In fact, if they do that, they’ll probably run into trouble.
Shallow BDD is when you just have conversations around
– The shallowest form of BDD consists of just having
conversations around scenarios – not capturing them, not
automating them, but just having the conversations.
• Avoid UI driven scenario
– Not recommended
Given I’m in user registration page
And I filled FirstName “Vinay”
And filled LastName “Krishna
And filled City “Bangalore”
And I choose to register as a developer
When I click on Register
Then I received successfully registered message
Given I am registering
When I fill in my basic information
Then I should be registered as a developer
• 5 why – Determining the root cause
– Problem Statement: Customers are unhappy because they are being shipped
products that don’t meet their specifications.
1. Why are customers being shipped bad products?
– Because manufacturing built the products to a specification that is different from what
the customer and the sales person agreed to.
2. Why did manufacturing build the products to a different specification than that of sales?
– Because the sales person expedites work on the shop floor by calling the head of
manufacturing directly to begin work. An error happened when the specifications were
being communicated or written down.
3. Why does the sales person call the head of manufacturing directly to start work instead
of following the procedure established in the company?
– Because the “start work” form requires the sales director’s approval before work can
begin and slows the manufacturing process (or stops it when the director is out of the
4. Why does the form contain an approval for the sales director?
– Because the sales director needs to be continually updated on sales for discussions
with the CEO.
• In this case only four Whys were required to find out that a non-value
added signature authority is helping to cause a process breakdown.
• BDD is automation of functional testing
– Automation of scenarios are just a by-product.
Remember Shallow BDD
• Using cucumber or specflow is BDD
– No, its just using a tool
• BDD is replacement of functional testing
– No, lets discuss