Testing as Communication, Real-World Techniques

Download Testing as Communication, Real-World Techniques

Post on 28-Nov-2014




0 download

Embed Size (px)




<ul><li> 1. Testing as Communication Real-World Techniques Jon Lark Larkowski @L4rk Sunday, March 1, 2009 1 </li> <li> 2. Walk of the Talk Subset of Obies The Hashrocket Way talk Our tools &amp; techniques How they support communication And save time &amp; money At the end: where were headed Sunday, March 1, 2009 2 </li> <li> 3. We value agility &amp; transparency Therefore, we value testing &amp; communication And, this all saves you cash money, ideally The Way Sunday, March 1, 2009 3 </li> <li> 4. Test All the f-ing time. (Hi, Bryan!) If we test all the time And testing is communication Then we Sunday, March 1, 2009 4 </li> <li> 5. Communicate All the f-ing time. (Only if we keep the overhead low.) Theres three lines of communication... 1. C2D: client to developer 2. D2D: developer to developer 3. DnD: [not covered in this talk] Sunday, March 1, 2009 5 </li> <li> 6. Fiscal Responsibility Testing is communication Both are baked in to our agile process That is, with low overhead This saves you dough Walk through our process, rst tool is... Sunday, March 1, 2009 6 </li> <li> 7. Pivotal Tracker We live in it. Whos using it? We dont code unless its for a story. Lets look at some screenshots... Sunday, March 1, 2009 7 </li> <li> 8. Sunday, March 1, 2009 8 </li> <li> 9. Sunday, March 1, 2009 9 </li> <li> 10. Pivotal Tracker Communication aspects... C2D: transparency, scheduling D2D: estimation, who's doing what right now Sunday, March 1, 2009 10 </li> <li> 11. Pivotal Tracker Fiscal aspects Real-time web collaboration lowers overhead, both to clients at-distance, and developer across room Reporting &amp; projection tools allow for reasonable estimates, off real-world data So thats Tracker, but at its core its all about Sunday, March 1, 2009 11 </li> <li> 12. Stories All our work is driven by stories. Stories are like tiny use cases. Really, stories are tests. Because they contain acceptance criteria. Sunday, March 1, 2009 12 </li> <li> 13. Stories Communication aspects... C2D: stories are tokens of a conversation D2D: make sure to write stories at a level developer can actually implement Sunday, March 1, 2009 13 </li> <li> 14. Stories Techniques we use Direct capture to Tracker Standard forms: In order to / As a / I want to Given / When / Then Written together with client, with close developer aide Sunday, March 1, 2009 14 </li> <li> 15. Stories Fiscal aspects Well, theyre a part of agile in general Delivery working software early &amp; often Constant cost of change Tight response to change Ability to recoup investment at any time So, thats stories. Now, when we actually start coding stories, we Sunday, March 1, 2009 15 </li> <li> 16. Pair all the f-ing time. Sunday, March 1, 2009 16 </li> <li> 17. Pair Programming Communication aspects Whos pairing? (Some, most, all.) Hopefully, you know the benets already. D2D: keep focused, honest, high quality D2C: redundancy, bus sensitivity Sunday, March 1, 2009 17 </li> <li> 18. Pair Programming Techniques we use Two developers, one screen. Ping Pong, both metaphorical and literal Daily stand-ups Sunday, March 1, 2009 18 </li> <li> 19. We take ping pong very seriously. Sunday, March 1, 2009 19 </li> <li> 20. Get up, stand up... Sunday, March 1, 2009 20 </li> <li> 21. Pair Programming Fiscal aspects Oh, boy. I could tell you, Studies show Or I could just tell you, Do it. No, no. Seriously. Do it. Sunday, March 1, 2009 21 </li> <li> 22. Sunday, March 1, 2009 22 </li> <li> 23. Testing Communication aspects C2D: express stories as acceptance criteria, then tests (MVC tests) D2C: RSpec specdoc format, cucumber D2D: more durable system specication Examples Sunday, March 1, 2009 23 </li> <li> 24. Sunday, March 1, 2009 24 </li> <li> 25. Sunday, March 1, 2009 25 </li> <li> 26. Testing Techniques we use RSpec Selenium MVC, yes... V RSpactor Factory Girl/Object Daddy Continuous Integration Cucumber Clicking on stuff Sunday, March 1, 2009 26 </li> <li> 27. Testing Fiscal aspects Whos heard, We dont have time to test! Quit that job, immediately. Unless its Obie who says it. You dont have time not to test. Sunday, March 1, 2009 27 </li> <li> 28. Testing Fiscal aspects continued Respond to change quickly, be more daring in yourrefactorings Less regression, no rework xing old bugs Supports collective ownership, guards against misuse Serves as built-in documentation (low overhead) Supports continuous integration and deliverability Sunday, March 1, 2009 28 </li> <li> 29. Continuous Delivery All the f-ing time. We deliver nished stories multiple times a day. Communication aspects C2D: very tight feedback loop with client D2D: smoke test together to demo features Sunday, March 1, 2009 29 </li> <li> 30. Continuous Delivery Techniques we use The usual, capistrano Supported by continuous integration Deploy to Engine Yard staging slice Also, Amazon EC2 instances Sunday, March 1, 2009 30 </li> <li> 31. Continuous Delivery Fiscal aspects Respond to market, recoup investment at any time, when it makes business sense, or you run out of money, or nd better things to do with it Once weve delivered Sunday, March 1, 2009 31 </li> <li> 32. Client Acceptance The Final Test Communication aspects C2D: youre doing it wrong C2D: youre doing it right Sunday, March 1, 2009 32 </li> <li> 33. ur doin it rong Sunday, March 1, 2009 33 </li> <li> 34. Client Acceptance Techniques we use Developer-assisted acceptance Ideally, on-site Video chats Daily stand-up Sunday, March 1, 2009 34 </li> <li> 35. Client Acceptance Fiscal aspects Verify you got what you paid for Sooner rather than later Change direction anytime So, thats what were up to now Sunday, March 1, 2009 35 </li> <li> 36. Where Were Headed Jakob Nielsen says, waterfall method user specs are always wrong...</li></ul>