BDD: There's more to it than you think

2,094 views
1,818 views

Published on

"Given..When..Then"...a common perception of Behaviour Driven Development focuses on writing and automating SpecFlow-style scenarios. In fact this is just a small part of BDD: the full scope of BDD ranges from requirements discovery and description, through to driving technical design and implementation, helping testers focus their testing efforts more effectively, and even providing reliable, useful and accurate technical documentation. In this talk, you will learn about how much more there is to BDD than just "Given..When..Then"!

Published in: Technology
3 Comments
9 Likes
Statistics
Notes
  • And you are right - collaboration requires a change in *team* behavior, which is harder, but the leverage you get ('building the right product') is much more significant.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Thanks!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Congratulations! Good presentation. I always saw BDD as a way to write tests thinking about what is important, behavior. But the collaboration between developer, business analyst and tester is still something difficult, even in agile teams because it requires a change in the process.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
2,094
On SlideShare
0
From Embeds
0
Number of Embeds
33
Actions
Shares
0
Downloads
45
Comments
3
Likes
9
Embeds 0
No embeds

No notes for slide

BDD: There's more to it than you think

  1. 1. BDD It’s not just ‘given-when-then’
  2. 2. John Ferguson Smart Consultant   Trainer   Mentor   Author   Speaker   Coder
  3. 3. So what is this BDD thing? Scenario:  Learning  About  Qantas     Given  I  am  on  the  Wikipedia  home  page     When  I  search  for  'Qantas'  in  'English'     Then  I  should  see  the  'Qantas'  wikipedia  entry A  Test  Automa6on  Tool?
  4. 4. So what is this BDD thing? Scenario:  Learning  About  Qantas     Given  I  am  on  the  Wikipedia  home  page     When  I  search  for  'Qantas'  in  'English'     Then  I  should  see  the  'Qantas'  wikipedia  entry A  way  to  write  acceptance  criteria?
  5. 5. So what is this BDD thing? Scenario:  Learning  About  Qantas     Given  I  am  on  the  Wikipedia  home  page     When  I  search  for  'Qantas'  in  'English'     Then  I  should  see  the  'Qantas'  wikipedia  entry A  way  to  define  requirements?
  6. 6. BDD Feature Injection Automated Acceptance Criteria API and code design Collaboration Building the software right Building the right software Living Documentation
  7. 7. “Having  the  conversa/on     is  more  important  than     recording  the  conversa/on   is  more  important  than     automa/ng  the  conversa/on”   -­‐  Liz  Keogh BDD  starts  with  conversa6on
  8. 8. Feature  Injec6on Hunt  the  value!
  9. 9. Why do we build any feature? Increase  Revenue Protect  Revenue Reduce  Costs Avoid  Future  Costs
  10. 10. Examples/Scenarios Stories Features Capabilities Goals Acceptance Criteria Where do features come from?
  11. 11. Features guide the development process
  12. 12. But knowing why we build a feature is even better To increase ticket sale revenue Why Who How travellers take the train more often suggest taking the train to friends What online booking social network integration concessions credit card payment
  13. 13. Story bug  reports Working   code boring   manual   tes:ng WASTE BA Developer Tester Many teams build features like this… Collabora6on
  14. 14. …but a little cooperation goes a long way… Working  code     and     Working  Automated   Acceptance  Tests Exploratory  tes:ng,   usability  tes:ng... Shared   understanding Story Examples Automated   acceptance   criteria Collabora6on
  15. 15. We call this “The Three Amigos” BA  and/or  product  owner Tester Developer Automatable   Acceptance   Criteria Shared   understanding Collabora6on
  16. 16. Collabora6on We call this “The Three Amigos”
  17. 17. “Automation without collaboration is empty”
  18. 18. Scenario Step  Defini6ons Low  level  specifica6ons   (aka  “unit  tests”) Applica6on  Code API  and  Code  Design
  19. 19. Oh, the things you can learn… API  and  Code  Design
  20. 20. What  would  we  like  the  API  to  look  like? API  and  Code  Design
  21. 21. Then  write  low-­‐level  specifica6ons  for  the  code API  and  Code  Design
  22. 22. Then  write  low-­‐level  specifica6ons  for  the  code API  and  Code  Design
  23. 23. “Every class is an API for someone”
  24. 24. Living  Documenta6on
  25. 25. Living  Documenta6on A  star:ng  point  for  manual  tests Illustrates  delivered  features Func:onal  and  technical  documenta:on Progress  repor:ng
  26. 26. Living  Documenta6on Scenario: Searching by keyword Given Sally wants to buy a puppy for her son When she looks for ads in the Pets & Animals category containing puppy Then she should obtain a list of ads for puppies for sale
  27. 27. Living  Documenta6on
  28. 28. Living  Documenta6on High level requirements (capabilities)
  29. 29. Living  Documenta6on A capability Features that support this capability
  30. 30. Living  Documenta6on Details for a feature Stories for this feature
  31. 31. Living  Documenta6on Pending story Acceptance criteria for this story
  32. 32. Living  Documenta6on Acceptance criteria Acceptance criteria details
  33. 33. “Living Documentation completes the circle”
  34. 34. In conclusion… It’s  behaviour  all  the  way  down
  35. 35. Thank You John Ferguson Smart john.smart@wakaleo.com wakaleo http://www.wakaleo.com

×