BDD: What's in it for me?

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

more share options
Embed For WordPress.com

Without related presentations

Notes on slide 1

briefly introduce BDD
benefits for particular roles on team
experiences
demo cucumber, a BDD tool
ask questions but I'll keep the presentation moving
q time at the end

from Melbourne, Australia
agile for over 3 years
mainly in XP teams as a developer
doing BDD like things for a while
trying to practise BDD for about a year

collaboration aspect interests me most

who describes themselves as a customer?
product owner? business analyst?
I’m calling you a customer
you want something
paying the bills
you accept the system

who is a developer?
you are building the thing
you may have used Test Driven Development
... Domain Driven Design
... unit testing
... automated acceptance testing

who is a tester?
QA?
you make sure it works
you also think about ways it can work better

BDD offers things that should make all of you happy
some things are of interest to particular roles

heard about BDD before?
experimenting? used before?

simple definition: BDD == blend of goodies from DDD and TDD

DDD
Domain Driven Design
conceptual model of the problem domain
manages complexity and change in software
we make the software model the problem
we use the same language to describe:
things
behaviour
ubiquitous language - ubiq = everywhere at once
finding + changing things should be relatively easy
some technical guidelines
mainly theoretical
DDD can be used by everyone

TDD
Test Driven Development
designing code using automated behavioural tests
write tests for behaviour
run the tests - they break
enough code to make the test pass
pick the next thing
this means we only develop as much as we need
byproduct: nice test suite
used to design interactions
not terribly visible to anyone who isn't a dev
but the results are

BDD
Behaviour Driven Development combines best aspects of both of these things
test driven practises applied to WHOLE behaviour of the system
move the design practises of TDD outside further
encourages communication and collaboration

guiding principles of BDD
these principles drive how you practise it

its all behaviour
strong focus on behaviour
our code, tests/specs talk in terms of behaviour
we don't talk about Calculator object passing 1 and 2 to the addition method
we talk about Calculator adding
retain and strengthen the link with the problem we are solving
constantly focussed on it
ubiquitous language - no translation

deliver stakeholder value
agree that we should only do things that create value?
we should generally do the most valuable first?
sure we do
hard thing is figuring out whether they do or not
question rigorously the value something is creating
prioritise it against other things
build only the things that are important
build the most important first

enough is enough
only build what you need to build
plan as much as you need to
START building ASAP
STOP building ASAP

DDD influence
ubiquitous language one of the most beneficial parts
ubiquitous == everywhere at once
talk the same language about the thing we’re building
about behaviour
same problem, same system, same language

becomes easier to communicate
maximise our chances of building the right thing

what threatens to prevent this from happening?

multiple representations of the same behaviour

seen this in a number of projects

customer has a story about a new feature
purest form of the behaviour
(hopefully) not polluted with any technical jargon
everyone should be able to understand this

stored in a wiki, issue management system like JIRA, Pivotal tracker
some, I hear, even store it in a Microsoft Word document

at the best, at least everyone can read or change this
at the worst, its kept locked away
only a select few can change it

this is ONE representation of the system's desired behaviour

developer starts to work on the feature
must represent the problem in code
if they are practising DDD then they strive to maintain ubiquitous language in the code
unfortunately, this guy hasn't

hopefully also create automated tests, regardless of ubiq language
these basically act as a safety net to make sure nothing is broken

this is ANOTHER representation of the system's desired behaviour

testing time
tester needs to double check that each scenario passes

everyone has seen something like this? a procedural test?

mix of business domain and technical terms

they may be working from a manual test script
or maintain their own automated tests

this is YET ANOTHER representation

how does this look?
3 representations of the same behaviour
3 roles trying to communicate about the ONE thing
the one system

a customer states what they want in plain language
"market research, could be a untapped market in an automatic bill totaller”
totalling scenario

a developer takes this, uses their own version of language
tester takes it, represents it as a procedural test
developer finishes
feature goes into test
tester tests
"I added money to the bill as per steps 2 and 3 but the sum was wrong”
“it was 20 pounds"
dev - "bill? oh the cheque. that'll take a while to fix"
speak to customer - "when we summed the cheque it was wrong"
customer - "?”, you mean totalled the bill
and around it goes until everyone is on the same page
repeat at least once per bug or issue that comes up

divergence reinforced by 3 representations

the worst situation I have seen for this:

story descriptions in JIRA
devs automated scenarios using selenium and JUnit
testers automated using QTP
of 3, selenium tests only thing updated properly
changed in line with the code
JIRA neglected - no apparent value in updating
QTP ran nightly, broke every second day, eventually dropped

how do we fix this?

ubiquitous language
a good chunky, woody sounding word
same thing, same language

ONE representation of behaviour
lessens the chance for language to diverge

language is shared
we develop it together

how do we achieve it?

discussion, not just the problem but vocab.
model the problem
flush out new things

build understanding of the problem together
more we understand, better we can model it in code
better we model it in code, easier it is to change

story kickoff process

nut out scenarios and wording as a group
(devs, customer, testers)

standard scenario format = Given, When, Then
Given == starting state
When == stimulus that changes something
clicking a button or whatever
Then == the state we expect after

doing this together...
improves the quality of our description of behaviour
cements everyone's understanding of the problem
irons out inconsistencies in language

shared language and understanding
== more effective communication
== more maintainable systems

main benefit of BDD

better communication and collaboration
we create a shared understanding of the problem
we find it easier to talk about the system

we should all be on the same page

all agree, only build things that are valuable?
value + cost helps us decide when we build
or if we build at all

how do you know when something is valuable?
need to ask a lot of questions

dig for value

write features together as a team
act of writing a feature
== uncovering why it is valuable
== uncovering how valuable it is

one tool you can use to uncover value is popping the why stack
term originally attributed to Luke Barrett at Thoughtworks
related to the 5 whys root cause analysis

Stop when you get to:

# Protect revenue
# Increase revenue
# Manage cost

if you can't get there then why are you playing the feature?
maybe you've dug up an old shoe instead of treasure
ditching a feature is a great feeling

"in order to" is very important - spend time on analysing it

reducing waste
build the most important things first
chuck others out completely

should be able to trace each feature back to the strategic purpose of the project
if you haven't got one of those then you have bigger problems

also about avoiding waste
do the bare minimum
again, sounds like common sense?

how do we know when to stop?
when are we done?

when do I stop?

who has heard of red, green, refactor?
TDD mantra
simpifies things, breaks things down into simple steps
do the bare minimum
also gives you a place to start, first broken test

describe process, practical example next

to implement a feature:
pick first pending (yellow) scenario
pick first pending step
step is pending if it hasn't yet been implemented
step breaks once implemented
make sure your step is doing its job, need the red
behaviour is not implemented yet
make it pass
build only the functionality needed
refactor if necessary, stays green
repeat for each step
scenario goes green
repeat for next pending scenario
all scenarios passing == feature is passing

done when all scenarios pass
none of the previous ones are broken
may need to add or change scenarios as you go

quick demo of cucumber
show what I'm talking about when I mention features and steps
we are going to build the bill totalling feature

reiterate

helps you know "are we there yet?"
isn't foolproof
BUT forces you to continually ask, are we there yet
the features say we’re there, are we really?
do we need more scenarios?

everyone recognise the process we followed?

where to START
what to do NEXT
when to STOP

even when "done", there may be more scenarios to discover
a guideline but a good one

when can we start building stuff?
when we have enough information to start

code is what matters
you need to do some planning, design
only need to do so much

has anyone heard of bare sufficiency?
normally applied to software dev methodologies
says it should be just sufficient to get the job done
possibly with some gaps
they get filled in as we build

how we'd flesh out a feature:
planning for next iteration
enough detail to the level required at the time
to be able to estimate
keep it as bare as possible
cover enough scenarios to estimate
scenarios
assumptions
estimate
may result in other stories being created
also spikes
file it away - normally done on a printing whiteboard

when the story was kicked off we'd review the feature
go over it again, see if we had learnt anything in the meantime
adjust or add new scenarios
make sure the size was the same
when we had enough to start, we’d just start
new scenarios would come in later
often as a result implementing the initial ones

get to a point where you can build it
a working system gives you valuable feedback:
how will it work?
how could it work better?
will it work at all?

anyone had devs waiting on analysis to be done before they can start?
analyse together to remove that bottleneck
tight feedback about whether you have analysed enough

just build it
your understanding grows as you have something to play with

generates more knowledge
generates more questions about how it should work

questions are valuable
they help grow knowledge of the feature

everyone is responsible for asking questions
a tester or QA specialises in this
they will be the ones asking most of these questions

a question may be "why doesn't it work like expected" - a bug
a question may also be "should we expect it to work like this?" - change to a feature
a question is not necessarily a bug

lots of questions == good
better quality product

questions lead to more questions
exploring the feature leads to more being raised
this flattens off at the end as potential questions are exhausted
there is a very juicy curve in the middle

we can’t uncover all questions
uncover as many as we can

we all need to ask questions
testing == really driving them out
testing window is the “quality time” between tester and system
more time spent == more questions asked

here we uncover 2 questions during the window

doubling our window leads to uncovering 4x questions
bigger window == more coverage of juicy part of curve
we want to maximise our chance of hitting that flat spot
we can all agree that this is a good thing?

otherwise we risk things being discovered later
like in production

this doesn't always work out though

who has used a story wall before?
tracks flow of work between different stages
ready for dev, in dev and in test then DONE

who has seen this on the second last day?
who can tell me what is wrong with this one?

pile everything onto the testers on the last day of iteration

start testing earlier
regulate the flow of work
avoid testing being the bottleneck

BDD facilitates this
gives feedback on which scenarios are done
they can then be tested
we work on one scenario at a time
when it is passing we should be able to let the testers at it

previous project:
demo a scenario to a tester as soon as it was done
they would often dig things up immediately

the test stage became a final check
the bulk of the scenarios had been verified earlier

move start of testing window earlier
maximise it, maximise chance of exhausting questions

exploring early leads to more questions being asked
higher quality

everyone gets earlier feedback about bugs
potential new scenarios and changes

how else can we free up time for exploring?

useful byproducts

bran is a useful byproduct of processing cereals
we are really interested in refined grains
but bran is still terribly terribly useful

we have a similar situation with BDD

discovering and implementing behaviour byproduct == automated tests
automated tests are an awesome byproduct of BDD
these tests are like bran: they're great stuff, we love them
BUT discovering and implementing behaviour is our primary focus

but the fact remains; automated tests are a great byproduct

byproduct is automated test suite

who is familar with unit testing/automated testing?

tightrope metaphor:
making changes to code is like walking a tightrope
automated tests are a safety net that tell us when we have broken something

if we have no safety net we walk very, very slow
if we have a safety net we can move a lot faster
we know that if we fall, we'll be safe
we have more confidence to try new tricks

automated tests act like a safety net around the code

anyone had something fail in the app but "the unit test passes?"
move the safety net out further in the layers of the application
when we add or change behaviour, we MUST keep our automated tests green

more chance of catching things

automated tests are great
having automated tests that describe behaviour is even better

developers using automated tests should be able to see the benefit of this

is this interesting to testers?

testers:
who uses manual regression testing in their team?
who likes it?

manual regression testing can eat a lot of time and resources
cost grows exponentially with:
the size of the system
number of releases
rely on frequent releases to make things work; they must be cheap

would it not be awesome to have testers do less manual regression testing?

need to look at how we can make this work

this is not strictly part of BDD
a way to get more benefit out of automated testing
Cucumber model

shared ownership

everyone owns features
they encode our shared understanding of the behaviour
both developers and testers need to own the step defs
need visibility if they are going to be asked to rely on them
how do they know what is covered?
how do they know how it is covered?

need to be able to work on them with developers

testers need more programming skills
devs need more testing skills
hopefully working together will achieve this

I haven't yet seen this really work properly on a team
I would very much like to

what if we do get this to work?

regression testing time is freed up for exploratory testing
doesn't replace manual regression testing but should reduce it greatly
increases testing window
increase the number of questions

regression testing becomes cheaper and faster

specifications
specifications document how the system should behave

people like to know how their system behaves
especially as it grows bigger
we used to rely on written specifications for this
you'd update them when you change the code, right?
packed away in a warehouse like the lost ark
out of sight == out of mind
it becomes dead information
its connection with the system is severed and it dies
the document becomes useless

the place I was working did not like this
provided more confusion than information
this is one of the reasons they became interested in Cucumber and BDD

a BDD feature is "live" information
specification is executable
you can see if it still describes how the system actually behaves
if you use continuous integration, you can make it a part of your build
in fact, you should

executable specs retain their relationship to the system that they describe

you need to put a lot of effort into style
you need to make sure that generated documentation makes sense
best way is to get customers into habit of using it

you should look at this generated documentation regularly
make sure it it good enough for your customer, if it isn't then fix it
you probably aren't specifying behaviour well enough

this is Cucumber output
rspec and other frameworks can also output nice content like this

documentation on demand

tools like Cucumber, Rspec and others have ability
use it; generate reports from your latest build

tells you two things:
what the system should do under certain scenarios
what the system actually does under these scenarios (green steps/examples)

don't try and keep documents in synch - it just doesn't work

if the format doesn’t suit, change it
write a custom formatter
ensure it can be used as the documentation for the system

a better understanding of the problem
this is by far and beyond the big one

a better chance of getting what I really need
more efficient development
quicker feedback
live behavioural documentation

knowing where to start, what to do next and when to finish
awesome, TDD-like flow
the chance to start building something earlier
safety net when I’m making changes
more confidence when making changes

more time to explore
automate regression testing as much as possible
something to explore earlier
guidelines for which scenarios can be tested
also means we tend to work on one scenario at a time

sounds pretty good right?
it will not solve all of your problems

this is what can happen when you do it well
closer you get the more you should start seeing benefits

I've presented a lot of positive things here
it may seem a bit idealistic
like most agile approaches, the main negative == hard to implement properly
requires more thought and communication than traditional methods
need to be committed to continual improvement

BDD is not about tools
it is about communication and collaboration
this is what allows you to make better software
BDD just facilitates that

1 Favorite

hongjoo favorited this 2 weeks ago
Tags bdd

BDD: What's in it for me? - Presentation Transcript

Behaviour Driven Development what’s in it for me? Brent Snook Thursday, 15 October 2009
Brent who? • from Melbourne, Australia • self confessed Agile weenie • working with BDD for about a year • available for dev, coaching, children’s parties • fuglylogic.com • brentsnook Thursday, 15 October 2009
Audience Thursday, 15 October 2009
Audience Customer Thursday, 15 October 2009
Audience Customer Developer Thursday, 15 October 2009
Audience Customer Developer Tester Thursday, 15 October 2009
BDD ≈ DDD + TDD Thursday, 15 October 2009
Principles of BDD • It’s all behaviour • Deliver stakeholder value • Enough is enough Thursday, 15 October 2009
Principles of BDD • It’s all behaviour • Deliver stakeholder value • Enough is enough Thursday, 15 October 2009
In order to speed billing As a waiter I want to calculate bill total story descriptions (JIRA,Wiki,Word) Thursday, 15 October 2009
cheque.sum .should == 12.0 automated unit and acceptance tests Thursday, 15 October 2009
1. Add £2.00 to bill 2. Add £10.00 to bill 3. Verify sum is £12.00 test procedures Thursday, 15 October 2009
Translation Thursday, 15 October 2009
Translation Thursday, 15 October 2009
DO Translation NOT WANT!! Thursday, 15 October 2009
Mmmmm.....Ubiquitous Given an empty bill When I add £2.00 And I add £10.00 Then the total is £12.00 Thursday, 15 October 2009
Speak the Same Language We can understand each other. We are more likely to gain a deeper insight of the problem. We have a better chance of building the right thing. Cool bananas! Thursday, 15 October 2009
Principles of BDD • It’s all behaviour • Deliver stakeholder value • Enough is enough Thursday, 15 October 2009
Principles of BDD • It’s all behaviour • Deliver stakeholder value • Enough is enough Thursday, 15 October 2009
In order to ... speed up billing ... why? so that billing is cheaper ... why? so that I can manage cost DING! Thursday, 15 October 2009
Reduce Waste I waste less time and money building things that aren't really needed and uncovering value helps me to prioritise properly. Fantabulous! Thursday, 15 October 2009
Principles of BDD • It’s all behaviour • Deliver stakeholder value • Enough is enough Thursday, 15 October 2009
Principles of BDD • It’s all behaviour • Deliver stakeholder value • Enough is enough Thursday, 15 October 2009
Are We There Yet? Scenario Step Thursday, 15 October 2009
Demo Thursday, 15 October 2009
Are We There Yet? Scenario Step Thursday, 15 October 2009
A Place to Start, A Place to Stop Knowing where to start, what to do next and when to stop. Bonza! And less superﬂuous stuff! Thursday, 15 October 2009
(Barely) Sufﬁcient Detail Scenario: Simple bill total Given an empty bill When I add 2 pounds And I add 10 pounds Then the total is 12 pounds Thursday, 15 October 2009
Just Build It I can start building something as soon as possible. Grouse! Something to play with earlier! Thursday, 15 October 2009
Questions Asked 12 12 11 Total Questions 8 4 2 Time Thursday, 15 October 2009
Questions Asked Testing window 12 12 11 Total Questions 8 4 2 Time Thursday, 15 October 2009
Questions Asked Testing window 12 12 11 Total Questions 8 4 2 Time Thursday, 15 October 2009
Spread the Load 2 DAYS LEFT !!! Ready Dev Test Done Thursday, 15 October 2009
Explore Early Less chance of getting swamped and I get to uncover more problems. O' Frabjous day! Bugs and new scenarios earlier! Thursday, 15 October 2009
Useful Byproducts Thursday, 15 October 2009
Safety Net Thursday, 15 October 2009
Automated Tests I can make changes with greater conﬁdence and speed. W00t! Hmm...could I use those? Thursday, 15 October 2009
Manual Regression Testing Thursday, 15 October 2009
Shared Ownership Step Deﬁnitions Feature Thursday, 15 October 2009
Automated Regression Suite I can focus more on exploratory testing. Zipidee do da! Regression testing is cheaper and faster. Thursday, 15 October 2009
Dead Speciﬁcations Here Lies Total Bill Slipped away Out of sight Out of mind Won’t be remembered Thursday, 15 October 2009
Live Speciﬁcations Feature: Total a bill In order to speed billing As a waiter I want to calculate bill total Scenario: Simple bill with two items Given an empty bill When I add 2 pounds And I add 10 pounds Then the bill total will be 12 pounds Scenario: Remove item from bill Given an bill totalling 20 pounds When I remove 4 pounds Then the bill total will be 16 pounds Thursday, 15 October 2009
Documentation on Demand A comprehensive description of how my system should and does behave? On demand?! Splendiferous! Handy for verifying behaviour too. Thursday, 15 October 2009
What’s in it for me? • better understanding of the problem • a better chance of getting what I really need • more efﬁcient development • quicker feedback • live behavioural documentation Thursday, 15 October 2009
What’s in it for me? • better understanding of the problem • knowing where to start, what to do next and when to ﬁnish • the chance to start building something earlier • safety net when I’m making changes Thursday, 15 October 2009
What’s in it for me? • better understanding of the problem • more time to explore • something to explore earlier Thursday, 15 October 2009
Whoah There! Thursday, 15 October 2009
Questions? • brent@fuglylogic.com • brentsnook • pub Thursday, 15 October 2009
Links • http://skillsmatter.com/podcast/agile-testing/bdd- whats-in-it-for-me • http://behaviour-driven.org/ • http://dannorth.net/whats-in-a-story • http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd • http://en.wikipedia.org/wiki/5_Whys • http://pragprog.com/titles/achbd/the-rspec-book • http://www.infoq.com/minibooks/domain-driven-design-quickly • http://cukes.info • http://alistair.cockburn.us/Balancing+lightness+with+sufﬁciency Thursday, 15 October 2009
Images/Fonts • Blender - http://www.flickr.com/photos/lintmachine/2987986325 • Steering Wheel - http://www.flickr.com/photos/wheatfields/290438580 • Drinky Bird - http://www.flickr.com/photos/sfmike22/2326128380/ • Post It Note - http://www.flickr.com/photos/flatcat/3555774083/ • Digging for Treasure - http://www.flickr.com/photos/wessexarchaeology/51568417/ • Table Setting and Napkin - http://www.flickr.com/photos/sifu_renka/2789833722/ • Gravestone - http://www.flickr.com/photos/36041246@N00/3419197777/ • Bran - http://www.flickr.com/photos/trekkyandy/3316748814 • Tightrope - http://www.flickr.com/photos/marquette/1812518264/ • Repeat Icon - http://www.iconarchive.com/show/aesthetica-2-icons-by-dryicons/repeat-icon.html • Silver Bullet - http://www.flickr.com/photos/annguyenphotography/3268547290 • “No” Sign - http://commons.wikimedia.org/wiki/File:No_sign.svg • Avatar Editor - http://myavatareditor.com/ • Whiteboard Font - http://callsignkatejones.deviantart.com/art/House-Whiteboard-font-64929545 • Napkin Font - http://www.1001fonts.com/font_details.html?font_id=2178 Thursday, 15 October 2009