Using Behavior Driven Development and Feature Injection to Build Better Software Jeffrey Davidson @JeffreyGoodReq goodrequirements.com BBCCon2011:baf November 3, 2011
Using Behavior Driven Development
and Feature Injection to Build Better Software
Jeffrey Davidson @JeffreyGoodReq goodrequirements.com BBCCon2011:baf November 3, 2011
© Jeffrey Davidson, 2011
BDD Fundamentals
! I can teach you this in less than 1 minute . . .
! Are you ready?
! Seriously. Do you have your pencil ready?
! Can someone time me?
© Jeffrey Davidson, 2011
60 minutes in less than 60 seconds
! Without using any technical language…
! Describe who you are and what your condition is
! And what you do ! And how the system responds
© Jeffrey Davidson, 2011
– – Given You & You
r condition
What you do
What you see
Simple Structure
When Then
© Jeffrey Davidson, 2011
Given – When – Then
You now know enough to succeed.
Go! Enjoy another session.
© Jeffrey Davidson, 2011
Today’s Agenda…
! Fundamentals of BDD ! Formal definition ! What is BDD? ! How to use BDD ! Why being less specific is important ! Benefits ! Why you should care ! Why BDD isn’t testing ! More Fundamentals (Feature Injection) ! How to use Feature Injection ! How this directly relates to BDD
© Jeffrey Davidson, 2011
Not Today’s Agenda
! Discuss BDD Tools ! Give automation advice ! Share code quality practices
© Jeffrey Davidson, 2011
What is BDD?
“BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software
that matters.”
Dan North @ Agile Specifications, 2009
© Jeffrey Davidson, 2011
What is BDD?
! Fine grained, focused bits of behavior
! Told in a story format
No, really, what is it?
© Jeffrey Davidson, 2011
Stories & Story Format
! When you take a few minutes to talk to your co-workers, your boss, your spouse, and your family . . .
. . . do you give facts or context?
© Jeffrey Davidson, 2011
Stories & Story Format
! I dream of . . . adventure, challenge, success
© Jeffrey Davidson, 2011
Stories & Story Format
! Have you ever dreamed of . . . facts?
Yuck!
© Jeffrey Davidson, 2011
Stories
! We use stories to communicate.
© Jeffrey Davidson, 2011
Do you mean User Stories?
! “As a . . . , I want . . . , So . . . .”
© Jeffrey Davidson, 2011
User Stories are Statements
! User Stories do not give all the preconditions ! Or all the actors actions ! Or all the system responses
! Promise of a future conversation
© Jeffrey Davidson, 2011
Two Steps
! Start with business goals ! In Agile development, this is a
User Statement Story
! Build Scenarios
© Jeffrey Davidson, 2011
– – Given You & You
r condition
What you do
What you see
Simple Structure
When Then
© Jeffrey Davidson, 2011
Simple Structure
! Given [CONTEXT]
! When [EVENT OCCURS]
! Then [OUTCOME]
© Jeffrey Davidson, 2011
Given
OLD ! ?
NEW ! Given I am . . .
<<Who & Where & What has already happened & etc.>>
State your action in natural language
© Jeffrey Davidson, 2011
When
OLD ! ?
NEW ! When I <<perform
some action>>
State your action in natural language
© Jeffrey Davidson, 2011
NEW ! Then I see …
Then
OLD ! The system shall …
This is how you
observe the system’s
response
State your action in natural language
– OR – WRITE LIKE A
HUMAN
© Jeffrey Davidson, 2011
Be Like Aldi
! Generic behavior
! Don’t include design.
Imagine performing the same actions on a telephone interface!
© Jeffrey Davidson, 2011
Simple Structure
! Given [CONTEXT]
! When [EVENT OCCURS]
! Then [OUTCOME]
© Jeffrey Davidson, 2011
I want to withdraw $ from ATM (An example)
Scenario #1: Account has sufficient funds
! Given the account balance is 100 ! and the card is valid ! and the machine contains enough money ! When the account holder requests 20 ! Then the ATM should dispense 20 ! and the account balance should be 80 ! and the card should be returned
© Jeffrey Davidson, 2011
What is it?
! It’s a bunch of tiny stories, using a particular grammatical structure.
! It’s finding places of misunderstanding, and filling it with understanding.
! It’s a conversation, captured.
© Jeffrey Davidson, 2011
Why?
© Jeffrey Davidson, 2011
Simple Made Easy
! “We can only hope to make reliable those things that we can understand.
! We can only consider a few things at a time. ! Intertwined things must be considered
together. ! Complexity undermines understanding.”
Rich Hickey @ StrangeLoop 2011
© Jeffrey Davidson, 2011
Built right or Right product?
Gojko Adzic in Specification by Example, 2011
© Jeffrey Davidson, 2011
Benefits
To build the right product effectively, software dev practices need:
Gojko Adzic in Specification by Example, 2011
© Jeffrey Davidson, 2011
Benefits
To build the right product effectively, software dev practices need: ! Assurance all stakeholders & delivery
team members understand what needs to be delivered in the same way.
Gojko Adzic in Specification by Example, 2011
© Jeffrey Davidson, 2011
Benefits
To build the right product effectively, software dev practices need: ! Precise specifications so delivery teams
avoid wasteful rework caused by ambiguities and functional gaps.
Gojko Adzic in Specification by Example, 2011
© Jeffrey Davidson, 2011
Benefits
To build the right product effectively, software dev practices need: ! An objective means to measure when a
piece of work is complete.
Gojko Adzic in Specification by Example, 2011
© Jeffrey Davidson, 2011
Benefits
To build the right product effectively, software dev practices need: ! Documentation to facilitate change, in
terms of both software features & team structure.
Gojko Adzic in Specification by Example, 2011
© Jeffrey Davidson, 2011
Who Benefits?
! Everyone!
! Seriously, it helps everyone. • Business • Users • Testers • Developers • Analysts
© Jeffrey Davidson, 2011
Blah, Blah, Blah – Why should I care?
! Ferries & Bridges
© Jeffrey Davidson, 2011
Isn’t this just testing?
! Seems like TDD to me
! “Umm, what’s TDD?”
! If you’re doing TDD, then BDD is a great next step.
© Jeffrey Davidson, 2011
Acceptance Test Criteria
! Tests code or functionality
! Presumes the test is right
! Who really cares about the functionality? • It’s an IT term! • Users care about the behavior
© Jeffrey Davidson, 2011
BDD > TDD
! Presumes we don’t know everything
! So we ask about scenarios
! It’s about behavior • You can only learn about behavior from
conversation
! Behavior leads to design
“Can you give me an example?”
© Jeffrey Davidson, 2011
Is it like testing?
! Sort of…
! Specifications are written in such a precise way we can execute them
© Jeffrey Davidson, 2011
Testing Tools
! JBehave (java) ! RSpec, Cucumber (ruby) ! Lettuce (python) ! Nbehave & Nspec (.NET) ! FIT & FitNess (multiple) ! Etc.
There are lots of tools to use
© Jeffrey Davidson, 2011
It’s not about tools
“These tools are intended for use by programmers to guide coding, but they can also be used to express business facing tests that drive development, involving customers more closely in the process.”
Lisa Crispin in Agile Testing, 2009
© Jeffrey Davidson, 2011
Downsides
! May not help velocity
! New
! Tools (and all that jazz) may cause clutter, slow-down, new learning, other stuff
© Jeffrey Davidson, 2011
Wait a minute!
! What happened to Feature Injection?
© Jeffrey Davidson, 2011
Build Software That Matters
! Start with a business goal
Hint: Businesses want to increase, conserve, or protect $.
© Jeffrey Davidson, 2011
Feature Injection
! The value of an IT system is in it’s outputs / outcomes
! Model based on desired results
! Follow Information Smells to identify that may be missing from your model
© Jeffrey Davidson, 2011
Value is what matters
! If you want to add value . . .
! . . . don’t argue about features
! . . . ask about why
© Jeffrey Davidson, 2011
Think like an investor
! Every project is an investment.
! Picture a Business Investor
! Why does your Business Investor want to do this project?
© Jeffrey Davidson, 2011
Why invest?
! Avoid penalty ! Keep up with the market – competitor ! Always done this way ! Want to spend budget to keep it safe ! Bad PR via social media ! Et cetera
Whatever the reason, know the reason
© Jeffrey Davidson, 2011
Information Smells
1. Item on output, that are not on the model 2. Item on model, that are not on the output 3. Two pieces of information in one place 4. No relationship 5. One to one relationship. Are they the same thing? 6. Many to many ( missing information ) 7. Undefined functions ( missing information )
Chris Matts, to be published soon
© Jeffrey Davidson, 2011
It’s the same thing
! Discussing the Information Smells • Not about do we need this data? • Conversation about what business needs
! Changes the dynamic
! Transforms from push to pull
© Jeffrey Davidson, 2011
BDD: Recap
! Start with a goal or User Story
! Build scenarios
! Automate the testing
! Write the code
! Have a Coca-Cola and smile
© Jeffrey Davidson, 2011
Feature Injection: Recap
! Find the value
! Model the output
! Follow the Information Smells
! Have another Coke!
© Jeffrey Davidson, 2011
Questions
! If you waited until now to ask your questions, you missed the best chance for us to have a conversation.
! But you should ask anyway…
© Jeffrey Davidson, 2011
Experts
! Dan North @tastapod dannorth.net ! Chris Matts @PapaChrisMatts theitriskmanager.wordpress.com ! Liz Keogh @lunivore lunivore.com ! Gojko Adzic @gojkoadzic
gojko.net
© Jeffrey Davidson, 2011
Resources
http://www.lulu.com/product/ebook/real-options-at-agile-2009/17416200
This is a really
cool comic. You
should read it.
Using Behavior Driven Development
and Feature Injection to Build Better Software
Jeffrey Davidson @JeffreyGoodReq goodrequirements.com BBCCon2011:baf November 3, 2011
Using Behavior Driven Development
and Feature Injection to Build Better Software
Jeffrey Davidson @JeffreyGoodReq goodrequirements.com BBCCon2011:baf November 3, 2011