BDD in Action - building software that matters
 

BDD in Action - building software that matters

on

  • 2,961 views

Behaviour-driven development (BDD) started as an improved variation on test-driven development, but has evolved to become a formidable tool that helps teams communicate more effectively about ...

Behaviour-driven development (BDD) started as an improved variation on test-driven development, but has evolved to become a formidable tool that helps teams communicate more effectively about requirements, using conversation and concrete examples to discover what features really matter to the business. BDD helps teams focus not only on building features that work, but on ensuring that the features they deliver are the ones the client actually needs.

Learn what BDD is, and what it is not
Understand that the core of BDD is around conversation and requirements discovery, not around tools.
Understand the difference and similarities between BDD at the requirements level, and BDD at the coding level.
Learn what BDD tools exist for different platforms, and when to use them

Statistics

Views

Total Views
2,961
Views on SlideShare
1,551
Embed Views
1,410

Actions

Likes
17
Downloads
70
Comments
3

22 Embeds 1,410

http://java.dzone.com 944
https://weblogs.java.net 130
http://feedly.com 128
https://twitter.com 71
http://www.wakaleo.com 62
http://wakaleo.com 21
http://www.inoreader.com 9
http://www.feedspot.com 7
http://johnsmart2.rssing.com 5
http://www.gayanb.com 5
https://www.inoreader.com 5
http://rss.any.ge 4
http://www.java.net 3
http://www.javahammer.com 3
http://www.linkedin.com 3
http://digg.com 2
http://posts2599.rssing.com 2
http://localhost 2
http://reader.aol.com 1
http://www.dzone.com 1
http://127.0.0.1 1
https://www.linkedin.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Thanks for uploading this so quickly just after agileaus. :)
    Are you sure you want to
    Your message goes here
    Processing…
  • I'd be more than happy to help out - ping me and we can sort something out!
    Are you sure you want to
    Your message goes here
    Processing…
  • Really awesome pack. We really need to get you back into CBA again to help out.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

BDD in Action - building software that matters BDD in Action - building software that matters Presentation Transcript

  • BDD
in action Building software that matters
  • John Ferguson Smart Consultant   Trainer   Mentor   Author   Speaker   Coder
  • John Ferguson Smart Consultant   Trainer   Mentor   Author   Speaker   Coder
  • John Ferguson Smart Consultant   Trainer   Mentor   Author   Speaker   Coder
  • John Ferguson Smart Consultant   Trainer   Mentor   Author   Speaker   Coder
  • So what is this BDD thing?
  • Using examples So what is this BDD thing?
  • Using examples a shared understanding So what is this BDD thing?
  • Using examples a shared understanding software that matters So what is this BDD thing?
  • BDD So what is this BDD thing?
  • BDD Collaboration So what is this BDD thing?
  • BDD Hunting out value Collaboration So what is this BDD thing?
  • BDD Hunting out value Collaboration Building the right software So what is this BDD thing?
  • BDD Hunting out value Automated Acceptance Criteria Collaboration Building the right software So what is this BDD thing?
  • BDD Hunting out value Automated Acceptance Criteria API and code design Collaboration Building the right software So what is this BDD thing?
  • BDD Hunting out value Automated Acceptance Criteria API and code design Collaboration Building the software right Building the right software So what is this BDD thing?
  • BDD Hunting out value Automated Acceptance Criteria API and code design Collaboration Building the software right Building the right software Living Documentation So what is this BDD thing?
  • The business owner tells the business analyst what he wants 1 2 The business analyst writes a requirements document 3 The developer translates the requirements into software 4 The tester translates the requirements into test cases 5 The technical writer translates the software into functional and technical documentation BDD in a nutshell A traditional development process
  • The business owner tells the business analyst what he wants 1 2 The business analyst writes a requirements document 3 The developer translates the requirements into software 4 The tester translates the requirements into test cases 5 The technical writer translates the software into functional and technical documentation BDD in a nutshell A traditional development process
  • The business owner tells the business analyst what he wants 1 2 The business analyst writes a requirements document 3 The developer translates the requirements into software 4 The tester translates the requirements into test cases 5 The technical writer translates the software into functional and technical documentation BDD in a nutshell A traditional development process
  • The business owner tells the business analyst what he wants 1 2 The business analyst writes a requirements document 3 The developer translates the requirements into software 4 The tester translates the requirements into test cases 5 The technical writer translates the software into functional and technical documentation BDD in a nutshell A traditional development process
  • The business owner tells the business analyst what he wants 1 2 The business analyst writes a requirements document 3 The developer translates the requirements into software 4 The tester translates the requirements into test cases 5 The technical writer translates the software into functional and technical documentation BDD in a nutshell A traditional development process
  • The business owner tells the business analyst what he wants 1 2 The business analyst writes a requirements document 3 The developer translates the requirements into software 4 The tester translates the requirements into test cases 5 The technical writer translates the software into functional and technical documentation BDD in a nutshell A traditional development process
  • The business owner tells the business analyst what he wants 1 2 The business analyst writes a requirements document 3 The developer translates the requirements into software 4 The tester translates the requirements into test cases 5 The technical writer translates the software into functional and technical documentation BDD in a nutshell A traditional development process
  • The business owner tells the business analyst what he wants 1 2 The business analyst writes a requirements document 3 The developer translates the requirements into software 4 The tester translates the requirements into test cases 5 The technical writer translates the software into functional and technical documentation BDD in a nutshell A traditional development process
  • The business owner tells the business analyst what he wants 1 2 The business analyst writes a requirements document 3 The developer translates the requirements into software 4 The tester translates the requirements into test cases 5 The technical writer translates the software into functional and technical documentation BDD in a nutshell A traditional development process
  • The business owner tells the business analyst what he wants 1 2 The business analyst writes a requirements document 3 The developer translates the requirements into software 4 The tester translates the requirements into test cases 5 The technical writer translates the software into functional and technical documentation BDD in a nutshell A traditional development process
  • The business owner tells the business analyst what he wants 1 2 The business analyst writes a requirements document 3 The developer translates the requirements into software 4 The tester translates the requirements into test cases 5 The technical writer translates the software into functional and technical documentation BDD in a nutshell A traditional development process
  • The business owner and the business analyst have a conversation about what he needs. 1 2 3 4 The tester uses these scenarios as the basis for her tests 5 The automated tests provide feedback on progress and help document the application The business analyst, the developer and the tester elaborate the requirements together. The scenarios guide the developer and act as automated tests They define requirements as structured, English- language format "scenarios" BDD in a nutshell A BDD development process
  • The business owner and the business analyst have a conversation about what he needs. 1 2 3 4 The tester uses these scenarios as the basis for her tests 5 The automated tests provide feedback on progress and help document the application The business analyst, the developer and the tester elaborate the requirements together. The scenarios guide the developer and act as automated tests They define requirements as structured, English- language format "scenarios" BDD in a nutshell A BDD development process
  • The business owner and the business analyst have a conversation about what he needs. 1 2 3 4 The tester uses these scenarios as the basis for her tests 5 The automated tests provide feedback on progress and help document the application The business analyst, the developer and the tester elaborate the requirements together. The scenarios guide the developer and act as automated tests They define requirements as structured, English- language format "scenarios" BDD in a nutshell A BDD development process
  • The business owner and the business analyst have a conversation about what he needs. 1 2 3 4 The tester uses these scenarios as the basis for her tests 5 The automated tests provide feedback on progress and help document the application The business analyst, the developer and the tester elaborate the requirements together. The scenarios guide the developer and act as automated tests They define requirements as structured, English- language format "scenarios" BDD in a nutshell A BDD development process
  • The business owner and the business analyst have a conversation about what he needs. 1 2 3 4 The tester uses these scenarios as the basis for her tests 5 The automated tests provide feedback on progress and help document the application The business analyst, the developer and the tester elaborate the requirements together. The scenarios guide the developer and act as automated tests They define requirements as structured, English- language format "scenarios" BDD in a nutshell A BDD development process
  • The business owner and the business analyst have a conversation about what he needs. 1 2 3 4 The tester uses these scenarios as the basis for her tests 5 The automated tests provide feedback on progress and help document the application The business analyst, the developer and the tester elaborate the requirements together. The scenarios guide the developer and act as automated tests They define requirements as structured, English- language format "scenarios" BDD in a nutshell A BDD development process
  • The business owner and the business analyst have a conversation about what he needs. 1 2 3 4 The tester uses these scenarios as the basis for her tests 5 The automated tests provide feedback on progress and help document the application The business analyst, the developer and the tester elaborate the requirements together. The scenarios guide the developer and act as automated tests They define requirements as structured, English- language format "scenarios" •Specifica8ons  are  elaborated  collabora8vely   •Specifica8ons  use  a  common  language   •Executable  specifica8ons  provide  fast  feedback BDD in a nutshell
  • “software that matters” Building the thing right Building the right thingWhat How Misaligned requirements Poor craftsmanship
  • “software that matters” Building the thing right Building the right thingWhat How Misaligned requirements Poor craftsmanship Solves the wrong problem well
  • “software that matters” Building the thing right Building the right thingWhat How Misaligned requirements Poor craftsmanship Solves the wrong problem well Solves the right problem poorly
  • “software that matters” Building the thing right Building the right thingWhat How Misaligned requirements Poor craftsmanship Buggy and useless Solves the wrong problem well Solves the right problem poorly
  • “software that matters” Building the thing right Building the right thingWhat How Misaligned requirements Poor craftsmanship Buggy and useless Slow to change Solves the wrong problem well Solves the right problem poorly
  • “software that matters” Building the thing right Building the right thingWhat How Misaligned requirements Poor craftsmanship Buggy and useless Hard to maintain Slow to change Solves the wrong problem well Solves the right problem poorly
  • “software that matters” Building the thing right Building the right thingWhat How Misaligned requirements Poor craftsmanship Buggy and useless Hard to maintain Slow to change Does what the business needs Reliable Easy to maintain Solves the wrong problem well Solves the right problem poorly
  • You don’t know what you don’t know Understanding of what needs to be delivered Time
  • You don’t know what you don’t know Understanding of what needs to be delivered Time Requirements phase done Analysis Phase done
  • You don’t know what you don’t know Understanding of what needs to be delivered Time Requirements phase done Analysis Phase done
  • You don’t know what you don’t know Understanding of what needs to be delivered Time Requirements phase done Analysis Phase done •Our  ignorance  decreases  over  8me   •It  does  not  decrease  at  a  linear  rate   •It  does  not  always  decrease  in  a  predictable  way
  • Business Goal Business Goal Business Goal “software that matters” We  start  with  a  business  goal
  • Business Goal Business Goal Business Goal “software that matters” We  start  with  a  business  goal “Increase  *cket  sales  by  5%  over  the  next  year   by  encouraging  travelers  to  fly  with  Flying  High   rather  than  with  a  rival  company.”
  • Business Goal Business Goal Business Goal “software that matters” What  features  will  enable  us  to  deliver  this  goal? FeaturesFeaturesFeatures
  • Business Goal Business Goal Business Goal “software that matters” What  features  will  enable  us  to  deliver  this  goal? FeaturesFeaturesFeatures Earn  Frequent  Flyer  points  from  flights
  • Business Goal Business Goal Business Goal “software that matters” What  features  will  enable  us  to  deliver  this  goal? FeaturesFeaturesFeatures Earn  Frequent  Flyer  points  from  flights Earn  Frequent  Flyer  points  from  purchases
  • Business Goal Business Goal Business Goal “software that matters” What  features  will  enable  us  to  deliver  this  goal? FeaturesFeaturesFeatures Earn  Frequent  Flyer  points  from  flights Earn  Frequent  Flyer  points  from  purchases View  Frequent  Flyer  account  balance  online
  • Business Goal Business Goal Business Goal “software that matters” We  use  conversa8ons  around  examples  to  build  up  our   understanding  of  these  features   FeaturesFeaturesFeatures FeaturesFeaturesExamples
  • Business Goal Business Goal Business Goal “software that matters” We  use  conversa8ons  around  examples  to  build  up  our   understanding  of  these  features   FeaturesFeaturesFeatures FeaturesFeaturesExamples “A  new  Frequent  Flyer  member   starts  off  with  Bronze  status”
  • Business Goal Business Goal Business Goal “software that matters” We  use  conversa8ons  around  examples  to  build  up  our   understanding  of  these  features   FeaturesFeaturesFeatures FeaturesFeaturesExamples “A  new  Frequent  Flyer  member   starts  off  with  Bronze  status” “If  she  earns  300  points,  she  becomes  a   Silver  Frequent  Flyer  member”
  • “Using examples”
  • “Using examples” •Explore  requirements   •Discover  what  we  don’t  know   •Clarify  ambigui8es   •Iden8fy  assump8ons  and  misunderstandings  
  • “Using examples” “A  new  Frequent  Flyer  member   starts  off  with  Bronze  status” •Explore  requirements   •Discover  what  we  don’t  know   •Clarify  ambigui8es   •Iden8fy  assump8ons  and  misunderstandings  
  • “Using examples” “A  new  Frequent  Flyer  member   starts  off  with  Bronze  status” “If  she  earns  300  points,  she  becomes  a   Silver  Frequent  Flyer  member” •Explore  requirements   •Discover  what  we  don’t  know   •Clarify  ambigui8es   •Iden8fy  assump8ons  and  misunderstandings  
  • “Using examples” “A  new  Frequent  Flyer  member   starts  off  with  Bronze  status” “If  she  earns  300  points,  she  becomes  a   Silver  Frequent  Flyer  member” “If  I  ask  for  the  details  about  the  flight  FH-­‐102,  I  should  see  that   it  is  a  Sydney  to  Hong  Kong  flight  that  leaves  at  11:55pm  ” •Explore  requirements   •Discover  what  we  don’t  know   •Clarify  ambigui8es   •Iden8fy  assump8ons  and  misunderstandings  
  • “Using examples” We  express  the  examples  in  a  structured   format  using  simple  English  phrases
  • “Using examples” We  express  the  examples  in  a  structured   format  using  simple  English  phrases
  • “Using examples” We  express  the  examples  in  a  structured   format  using  simple  English  phrases
  • “Using examples” We  express  the  examples  in  a  structured   format  using  simple  English  phrases
  • “Using examples” The  automated  acceptance  criteria   guide  the  development  process
  • “Using examples” The  automated  acceptance  criteria   guide  the  development  process
  • “Using examples” The  automated  acceptance  criteria   guide  the  development  process
  • “a shared understanding”
  • “Having  the  conversa/on     is  more  important  than     recording  the  conversa/on   is  more  important  than     automa/ng  the  conversa/on”   -­‐  Liz  Keogh “a shared understanding”
  • BA Developer Tester Many teams build features like this… “a shared understanding”
  • Story BA Developer Tester Many teams build features like this… “a shared understanding”
  • Story Working   code BA Developer Tester Many teams build features like this… “a shared understanding”
  • Story Working   code boring   manual   tes5ng BA Developer Tester Many teams build features like this… “a shared understanding”
  • Story bug  reports Working   code boring   manual   tes5ng BA Developer Tester Many teams build features like this… “a shared understanding”
  • Story bug  reports Working   code boring   manual   tes5ng WASTE BA Developer Tester Many teams build features like this… “a shared understanding”
  • …but a little cooperation goes a long way… Story “a shared understanding”
  • …but a little cooperation goes a long way… Story “a shared understanding”
  • …but a little cooperation goes a long way… Story “a shared understanding”
  • …but a little cooperation goes a long way… Story “a shared understanding”
  • …but a little cooperation goes a long way… Story Examples “a shared understanding”
  • …but a little cooperation goes a long way… Story Examples Automated   acceptance   criteria “a shared understanding”
  • …but a little cooperation goes a long way… Shared   understanding Story Examples Automated   acceptance   criteria “a shared understanding”
  • …but a little cooperation goes a long way… Working  code     and     Working  Automated   Acceptance  Tests Shared   understanding Story Examples Automated   acceptance   criteria “a shared understanding”
  • …but a little cooperation goes a long way… Working  code     and     Working  Automated   Acceptance  Tests Exploratory  tes5ng,   usability  tes5ng... Shared   understanding Story Examples Automated   acceptance   criteria “a shared understanding”
  • We call this “The Three Amigos” BA  and/or  product  owner Tester Developer Automatable   Acceptance   Criteria Shared   understanding “a shared understanding”
  • We call this “The Three Amigos” “a shared understanding”
  • We call this “The Three Amigos” “a shared understanding”
  • We call this “The Three Amigos” “a shared understanding”
  • We call this “The Three Amigos” “a shared understanding”
  • We call this “The Three Amigos” “a shared understanding”
  • “Automation without collaboration is empty”
  • Living Documentation
  • Living Documentation
  • Living Documentation Illustrates  delivered  features
  • Living Documentation A  star5ng  point  for  manual  tests Illustrates  delivered  features
  • Living Documentation A  star5ng  point  for  manual  tests Illustrates  delivered  features Progress  repor5ng
  • Living Documentation A  star5ng  point  for  manual  tests Illustrates  delivered  features Func5onal  and  technical  documenta5on Progress  repor5ng
  • Automated test results tell us…
  • Automated test results tell us… How  many   tests  passed
  • Automated test results tell us… How  many  failed How  many   tests  passed
  • Automated test results tell us… How  many  failed How  many   tests  passed How  many  weren’t  run
  • Automated test results tell us…
  • Automated test results tell us… What  tests  exist  for   a  given  feature
  • Automated test results tell us… What  tests  exist  for   a  given  feature How  stable  the  feature  is
  • Automated test results tell us…
  • Automated test results tell us… How  a  feature  was   tested
  • Automated test results tell us…
  • Automated test results tell us… What  a  feature  looks  like
  • Automated test results tell us…
  • Automated test results tell us… What  a  feature  looks  like
  • Automated test results tell us… What  a  feature  looks  like
  • Test results do not tell us what was not tested
  • Feature Coverage
  • Feature Coverage What  stories  are  defined   for  this  feature?
  • Feature Coverage What  stories  are  defined   for  this  feature? How  many  stories  have  automated   acceptance  criteria?
  • Feature Coverage What  stories  are  defined   for  this  feature? How  many  stories  have  automated   acceptance  criteria? What  acceptance  criteria  have   been  automated?
  • “Living Documentation completes the circle”
  • Business Goal Business Goal Business Goal We  can  automate  these  examples  in  the  form  of   “executable  specifica8ons” FeaturesFeaturesFeatures FeaturesFeaturesExamples Low level specifications Low level specifications Low level specifications Executable specifications “building the software right”
  • Business Goal Business Goal Business Goal We  can  automate  these  examples  in  the  form  of   “executable  specifica8ons” FeaturesFeaturesFeatures FeaturesFeaturesExamples Low level specifications Low level specifications Low level specifications Executable specifications “building the software right”
  • Business Goal Business Goal Business Goal We  can  automate  these  examples  in  the  form  of   “executable  specifica8ons” FeaturesFeaturesFeatures FeaturesFeaturesExamples Low level specifications Low level specifications Low level specifications Executable specifications “building the software right”
  • Business Goal Business Goal Business Goal We  use  low-­‐level  BDD  or  TDD  tools  to  define  the   behavior  of  components,  classes  etc. FeaturesFeaturesFeatures FeaturesFeaturesExamples Low level specifications Low level specifications Low level specifications Executable specifications “building the software right” Low level specifications Low level specifications Low level specifications Low level specifications Low level specifications
  • Business Goal Business Goal Business Goal We  use  low-­‐level  BDD  or  TDD  tools  to  define  the   behavior  of  components,  classes  etc. FeaturesFeaturesFeatures FeaturesFeaturesExamples Low level specifications Low level specifications Low level specifications Executable specifications spock RSpec “building the software right” Low level specifications Low level specifications Low level specifications Low level specifications Low level specifications
  • Business Goal Business Goal Business Goal We  use  low-­‐level  BDD  or  TDD  tools  to  define  the   behavior  of  components,  classes  etc. FeaturesFeaturesFeatures FeaturesFeaturesExamples Low level specifications Low level specifications Low level specifications Executable specifications spock RSpec “building the software right” Low level specifications Low level specifications Low level specifications Low level specifications Low level specifications
  • “building the software right”
  • Acceptance  criteria  tell  us  what  we  need  to  build… “building the software right”
  • “building the software right”
  • What  would  we  like  the  API  to  look  like? “building the software right”
  • What  would  we  like  the  API  to  look  like? “building the software right”
  • What  would  we  like  the  API  to  look  like? “building the software right”
  • “building the software right”
  • Then  write  low-­‐level  specifica8ons  for  the  code “building the software right”
  • Then  write  low-­‐level  specifica8ons  for  the  code “building the software right”
  • “building the software right”
  • “building the software right” These  low  level  specifica8ons  become  technical   documenta8on  for  your  APIs
  • “Every class is an API for someone”
  • BDD Gotchas 1 2 3 4
  • BDD Gotchas 1 2 3 4 An8-­‐paQern  1   The  business  analyst  writes  the  scenarios  and  then  gives   them  to  the  other  team  members.
  • 1 2 3 4 BDD Gotchas
  • 1 2 3 4 BDD Gotchas An8-­‐paQern  2   The  tester  writes  the  scenarios  at  the  end   to  implement  an  automated  test  suite.
  • 1 2 3 4 5 BDD Gotchas
  • 1 2 3 4 5 BDD Gotchas An8-­‐paQern  3   The  “Three  Amigos”  sessions  don’t  result  in  usable  scenarios,  so  the   developer  invents  them  a?erwards.
  • 1 2 3 4 5 BDD Gotchas An8-­‐paQern  3   The  “Three  Amigos”  sessions  don’t  result  in  usable  scenarios,  so  the   developer  invents  them  a?erwards.
  • 1 2 3 4 5 BDD Gotchas
  • 1 2 3 4 5 BDD Gotchas An8-­‐paQern  4   The  scenarios  are  too  UI-­‐centric  or  detail-­‐focused,  and  neglect  to  express   the  core  business  value.
  • 42 Benefits of BDD •Focus  effort   •Reduce  waste  and  misaligned  requirements
  • 43 Benefits of BDD Deliver  more  valuable  soYware
  • 44 Benefits of BDD Make  changes  safely
  • 45 Benefits of BDD Faster  and  more  reliable  releases
  • 46 Benefits of BDD Reduced  maintenance  costs
  • BDD  requires  high  business  engagement  and  collabora8on   Adoption challenges
  • BDD  works  best  in  an  Agile  or  Itera8ve  context   Adoption challenges
  • BDD  does  not  work  well  in  a  silo   Adoption challenges
  • Adoption challenges Skill  and  prac,ce  required:   •Wri,ng  good  scenarios  takes  prac,ce   •Poorly  wri:en  tests  can  lead  to  higher  test-­‐maintenance  costs   •Need  to  treat  test  automa,on  code  like  produc,on  code  
  • In conclusion… It’s  behaviour  all  the  way  down
  • Want to learn more?
  • Want to learn more?
  • Want to learn more? http://thucydides.info/
  • Want to learn more? http://thucydides.info/ https://code.google.com/p/spock/
  • Thank You John Ferguson Smart john.smart@wakaleo.com wakaleo http://www.wakaleo.com