Behaviour Driven DevelopmentOnly an effective way to collaborate among three

amigos Testing is just a by-product

Vinay Krishna

vinaykris@gmail.comhttp://in.linkedin.com/in/vinaykrishna

6/10/2015 1

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

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

Introduction

• Is it Bug?• Is it Feature?• No, it is Beature – Blame game

6/10/2015 4

Introduction

• Why beature?

– Misunderstanding at all level

– Lack of effective communication

– Difficulty in communication

– Lots of assumptions

6/10/2015 5

Group Activity

• To understand the importance of communication

• To understand the challenge in communication

6/10/2015 6

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

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

BAs Testers

Developers

6/10/2015 9

What is BDD?

6/10/2015 10

What is BDD

• Exploring the unknown

• Sharing and understanding

• Individuals and interactions over processes and tools

6/10/2015 11

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

Conversation Focused• BDD is

– Conversation among Three amigos

• PO/BAs

• Developers

• Testers

– Example based

– Value-Driven

– Outside-in

6/10/2015 13

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

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

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

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 siteGiven 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

When

• The purpose of When steps is to describe the key action the user performs

• Examples:

– Interact with a web page (Webrat/Watir/Seleniuminteraction 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

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

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

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

Example

Feature: Withdraw money from ATMIn order to avoid be in queue and save timeCustomers should be able to withdraw money from ATM all times

Scenario: Account has sufficient fundGiven Card is validAnd Account has 10000 Rs balanceWhen Customer enter 1000 Rs to withdrawThen Customer should get 1000 RsAND Account should have 9000 remaining balance

AND system should return the card

6/10/2015 22

• 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

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

BDD framework

• Feature file

• Step Definition (Glue code)

• Actual implementation

Feat

ure

file

co

nta

inin

g Sc

enar

ios

Glu

e C

od

e (S

tep

Def

init

ion

s)

Act

ual

Imp

lem

enta

tio

n (

Ap

plic

atio

n)

Act

ual

Imp

lem

enta

tio

n (

Ap

plic

atio

n)

Act

ual

Imp

lem

enta

tio

n (

Ap

plic

atio

n)

Act

ual

Imp

lem

enta

tio

n (

Ap

plic

atio

n)

6/10/2015 25

Re-visit VAT example

6/10/2015 26

Glue Code

6/10/2015 27

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

Best Practices

• Avoid UI driven scenario– Not recommended

Given I’m in user registration page

And I filled FirstName “Vinay”And filled LastName “KrishnaAnd filled City “Bangalore” ………………………………….………………………………….And I choose to register as a developer When I click on RegisterThen I received successfully registered message

– RecommendedGiven I am registering When I fill in my basic information Then I should be registered as a developer

6/10/2015 29

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

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

6/10/2015 32