Scrum Bangalore 13th meet up 13 june 2015 - behaviour driven development - vinay krishna - at prowareness

1. Behaviour Driven Development
Only an effective way to collaborate among three
amigos
Testing is just a by-product
Vinay Krishna
vinaykris@gmail.com
http://in.linkedin.com/in/vinaykrishna
6/10/2015 1

2. Introduction
• Often software development results surprises
at the end
– The business being unable to define the desired
outcomes
– 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
the requirement
6/10/2015 2

3. Introduction
• 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
them
• Functional Specification document
• Source Code
• Test case and test plan document
6/10/2015 3

4. Introduction
• Is it Bug?
• Is it Feature?
• No, it is Beature – Blame game
6/10/2015 4

5. Introduction
• Why beature?
– Misunderstanding at all level
– Lack of effective communication
– Difficulty in communication
– Lots of assumptions
6/10/2015 5

6. Group Activity
• To understand the importance of
communication
• To understand the challenge in
communication
6/10/2015 6

7. Discuss
• 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
rules:
– 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
feature?
6/10/2015 7

8. Discuss
• These rules do not specify whether to add VAT
before delivery cost to the basket total or
after.
• How should you handle a situation where the
basket delivery cost is exactly £20?
• What happens if there are multiple products
in the basket?
6/10/2015 8

9. BAs Testers
Developers
6/10/2015 9

10. What is BDD?
6/10/2015 10

11. What is BDD
• Exploring the unknown
• Sharing and understanding
• Individuals and interactions over processes
and tools
6/10/2015 11

12. Introduction
• 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
development.
6/10/2015 12

13. Conversation Focused
• BDD is
– Conversation
among Three
amigos
• PO/BAs
• Developers
• Testers
– Example based
– Value-Driven
– Outside-in
6/10/2015 13

14. Ubiquitous Language
• To make sure that the whole team understand what's
wanted, the behavior is described in non-technical
language.
– 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
• Feature
• Background, Tag
• Scenario, Scenario Outline
• Given, When, Then
– Localized to 35+ languages
6/10/2015 14

15. Feature
• Every *.feature file conventionally consists of a
single feature.
• 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
structure.
6/10/2015 15

16. Scenario
• 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
– Given
– When
– Then
– But or And
6/10/2015 16

17. Given
• 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
preconditions.
• Example
– 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"
6/10/2015 17

18. When
• The purpose of When steps is to describe the key
action the user performs
• Examples:
– 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
6/10/2015 18

19. Then
• The purpose of Then steps is to observe
outcomes.
• The observations should be related to the
business value/benefit in your feature
description.
• The observations should inspect the output of
the system (a report, user interface, message,
command output)
– and not something deeply buried inside it (that has no
business value and is instead part of the
implementation).
6/10/2015 19

20. 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
6/10/2015 20

21. Step Data
• 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
cells.
• Text
– Any text block following a step wrapped in “” lines will be associated with the
step.
• Table
– 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
model.
Given a set of specific users
| name | department |
| Barry | Beer Cans |
| Pudey | Silly Walks |
| Two-Lumps | Silly Walks |
6/10/2015 21

22. Example
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
balance
AND system should return the card
6/10/2015 22

23. • Think and identify more scenarios for same
feature.
• Discuss in your group each identified scenario
and write it using gherkin language
6/10/2015 23

24. Summary
• Working together to find better solutions
• Use real-world examples to build a shared
understanding of the domain
• People understand requirements best using
concrete examples.
• Examples clear up ambiguity and
misunderstandings.
• Examples expose missing requirements.
• Examples force everyone to think harder about a
problem.
6/10/2015 24

25. BDD framework
• Feature file
• Step Definition (Glue code)
• Actual implementation
FeaturefilecontainingScenarios
GlueCode(StepDefinitions)
ActualImplementation(Application)
ActualImplementation(Application)
ActualImplementation(Application)
ActualImplementation(Application)
6/10/2015 25

26. Re-visit VAT example
6/10/2015 26

27. Glue Code
6/10/2015 27

28. Best Practices
• Shallow BDD
– Automation doesn’t mean, it’s BDD. Communication is
must
– 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
scenarios.
– The shallowest form of BDD consists of just having
conversations around scenarios – not capturing them, not
automating them, but just having the conversations.
6/10/2015 28

29. Best Practices
• 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
– Recommended
Given I am registering
When I fill in my basic information
Then I should be registered as a developer
6/10/2015 29

30. Best Practices
• 5 why – Determining the root cause
• Example
– 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
office).
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.
6/10/2015 30

31. BDD Myths
• 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
6/10/2015 31

32. 6/10/2015 32