BDD: What's in it for me?
•
15 j'aime•1,726 vues
Behaviour Driven Development and some of the benefits it offers for developers, customers and testers. Originally presented at Skills Matter: http://skillsmatter.com/event/agile-testing/bdd-whats-in-it-for-me
Recommandé
Contenu connexe
En vedette
En vedette (9)
Plus de fuglylogic
Plus de fuglylogic (10)
Dernier
Dernier (20)
BDD: What's in it for me?
- 1. Behaviour Driven Development what’s in it for me? Brent Snook Thursday, 15 October 2009
- 2. 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
- 3. Audience Thursday, 15 October 2009
- 4. Audience Customer Thursday, 15 October 2009
- 5. Audience Customer Developer Thursday, 15 October 2009
- 6. Audience Customer Developer Tester Thursday, 15 October 2009
- 7. BDD ≈ DDD + TDD Thursday, 15 October 2009
- 8. Principles of BDD • It’s all behaviour • Deliver stakeholder value • Enough is enough Thursday, 15 October 2009
- 9. Principles of BDD • It’s all behaviour • Deliver stakeholder value • Enough is enough Thursday, 15 October 2009
- 10. In order to speed billing As a waiter I want to calculate bill total story descriptions (JIRA,Wiki,Word) Thursday, 15 October 2009
- 11. cheque.sum .should == 12.0 automated unit and acceptance tests Thursday, 15 October 2009
- 12. 1. Add £2.00 to bill 2. Add £10.00 to bill 3. Verify sum is £12.00 test procedures Thursday, 15 October 2009
- 13. Translation Thursday, 15 October 2009
- 14. Translation Thursday, 15 October 2009
- 15. DO Translation NOT WANT!! Thursday, 15 October 2009
- 16. 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
- 17. 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
- 18. Principles of BDD • It’s all behaviour • Deliver stakeholder value • Enough is enough Thursday, 15 October 2009
- 19. Principles of BDD • It’s all behaviour • Deliver stakeholder value • Enough is enough Thursday, 15 October 2009
- 20. In order to ... speed up billing ... why? so that billing is cheaper ... why? so that I can manage cost DING! Thursday, 15 October 2009
- 21. 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
- 22. Principles of BDD • It’s all behaviour • Deliver stakeholder value • Enough is enough Thursday, 15 October 2009
- 23. Principles of BDD • It’s all behaviour • Deliver stakeholder value • Enough is enough Thursday, 15 October 2009
- 24. Are We There Yet? Scenario Step Thursday, 15 October 2009
- 25. Demo Thursday, 15 October 2009
- 26. Are We There Yet? Scenario Step Thursday, 15 October 2009
- 27. A Place to Start, A Place to Stop Knowing where to start, what to do next and when to stop. Bonza! And less superfluous stuff! Thursday, 15 October 2009
- 28. (Barely) Sufficient 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
- 29. Just Build It I can start building something as soon as possible. Grouse! Something to play with earlier! Thursday, 15 October 2009
- 30. Questions Asked 12 12 11 Total Questions 8 4 2 Time Thursday, 15 October 2009
- 31. Questions Asked Testing window 12 12 11 Total Questions 8 4 2 Time Thursday, 15 October 2009
- 32. Questions Asked Testing window 12 12 11 Total Questions 8 4 2 Time Thursday, 15 October 2009
- 33. Spread the Load 2 DAYS LEFT !!! Ready Dev Test Done Thursday, 15 October 2009
- 34. 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
- 35. Useful Byproducts Thursday, 15 October 2009
- 36. Safety Net Thursday, 15 October 2009
- 37. Automated Tests I can make changes with greater confidence and speed. W00t! Hmm...could I use those? Thursday, 15 October 2009
- 38. Manual Regression Testing Thursday, 15 October 2009
- 39. Shared Ownership Step Definitions Feature Thursday, 15 October 2009
- 40. Automated Regression Suite I can focus more on exploratory testing. Zipidee do da! Regression testing is cheaper and faster. Thursday, 15 October 2009
- 41. Dead Specifications Here Lies Total Bill Slipped away Out of sight Out of mind Won’t be remembered Thursday, 15 October 2009
- 42. Live Specifications 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
- 43. 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
- 44. What’s in it for me? • better understanding of the problem • a better chance of getting what I really need • more efficient development • quicker feedback • live behavioural documentation Thursday, 15 October 2009
- 45. What’s in it for me? • better understanding of the problem • knowing where to start, what to do next and when to finish • the chance to start building something earlier • safety net when I’m making changes Thursday, 15 October 2009
- 46. What’s in it for me? • better understanding of the problem • more time to explore • something to explore earlier Thursday, 15 October 2009
- 47. Whoah There! Thursday, 15 October 2009
- 48. Questions? • brent@fuglylogic.com • brentsnook • pub Thursday, 15 October 2009
- 49. 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+sufficiency Thursday, 15 October 2009
- 50. 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
Notes de l'éditeur
- 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
- 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
- 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