Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Related Books

Free with a 30 day trial from Scribd

See all
Authentic: A Memoir by the Founder of Vans Louise Maclellan
(4/5)
Free
Hot Seat: What I Learned Leading a Great American Company Jeff Immelt
(5/5)
Free
Ladies Get Paid: The Ultimate Guide to Breaking Barriers, Owning Your Worth, and Taking Command of Your Career Claire Wasserman
(5/5)
Free
The Ministry of Common Sense: How to Eliminate Bureaucratic Red Tape, Bad Excuses, and Corporate BS Martin Lindstrom
(3.5/5)
Free
Driven: The Race to Create the Autonomous Car Alex Davies
(0/5)
Free
Made in China: A Prisoner, an SOS Letter, and the Hidden Cost of America's Cheap Goods Amelia Pang
(4/5)
Free
How I Built This: The Unexpected Paths to Success from the World's Most Inspiring Entrepreneurs Guy Raz
(4.5/5)
Free
Believe IT: How to Go from Underestimated to Unstoppable Jamie Kern Lima
(4.5/5)
Free
No Filter: The Inside Story of Instagram Sarah Frier
(4.5/5)
Free
How Innovation Works: And Why It Flourishes in Freedom Matt Ridley
(5/5)
Free
Ask for More: 10 Questions to Negotiate Anything Alexandra Carter
(4/5)
Free
Your Turn: Careers, Kids, and Comebacks--A Working Mother's Guide Jennifer Gefsky
(0/5)
Free
Bezonomics: How Amazon Is Changing Our Lives and What the World's Best Companies Are Learning from It Brian Dumaine
(4.5/5)
Free
Blue-Collar Cash: Love Your Work, Secure Your Future, and Find Happiness for Life Ken Rusk
(0/5)
Free
Make Your Moment: The Savvy Woman’s Communication Playbook for Getting the Success You Want: The Savvy Woman’s Communication Playbook for Getting the Success You Want Dion Lim
(3.5/5)
Free
The Catalyst: How to Change Anyone's Mind Jonah Berger
(4.5/5)
Free

Related Audiobooks

Free with a 30 day trial from Scribd

See all
The Debt Trap: How Student Loans Became a National Catastrophe Josh Mitchell
(4.5/5)
Free
You're Invited: The Art and Science of Cultivating Influence Jon Levy
(4.5/5)
Free
An Ugly Truth: Inside Facebook’s Battle for Domination Sheera Frenkel
(4.5/5)
Free
We Should All Be Millionaires: Change Your Thinking, Build Bank, and Claim Your Independence Rachel Rodgers
(5/5)
Free
Big Vape: The Incendiary Rise of Juul Jamie Ducharme
(5/5)
Free
Twelve and a Half: Leveraging the Emotional Ingredients Necessary for Business Success Gary Vaynerchuk
(5/5)
Free
End of Bias, The: A Beginning: The Science and Practice of Overcoming Unconscious Bias Jessica Nordell
(3.5/5)
Free
Full Out: Lessons in Life and Leadership from America's Favorite Coach Monica Aldama
(4.5/5)
Free
Your Work from Home Life: Redefine, Reorganize and Reinvent Your Remote Work (Tips for Building a Home-Based Working Career) M.J. Fievre
(4/5)
Free
Just Work: How to Root Out Bias, Prejudice, and Bullying to Build a Kick-Ass Culture of Inclusivity Kimberly Scott
(3.5/5)
Free
Finance Secrets of Billion-Dollar Entrepreneurs: Venture Finance Without Venture Capital Dileep Rao
(4/5)
Free
The Way We Work: On the Job in Hollywood Bruce Ferber
(4.5/5)
Free
Fulfillment: Winning and Losing in One-Click America Alec MacGillis
(4.5/5)
Free
Subtract: The Untapped Science of Less Leidy Klotz
(4/5)
Free
Liftoff: Elon Musk and the Desperate Early Days That Launched SpaceX Eric Berger
(5/5)
Free
Flex: Reinventing Work for a Smarter, Happier Life Annie Auerbach
(4.5/5)
Free

Great! another bug

  1. Great! We found a bug! Pascal Van Cauwenberghe
  2. Hello Consults Programs Manages projects Creates Games Organises conferences NAYIMA We make play work www.nayima.be blog.nayima.be
  3. SAFETY WARNING
  4. Safety Warning • This presentation contains code – No guarantee that it actually compiles • This presentation may contain bugs – Avoid if suffering from entomophobia
  5. Based on true stories • In different countries • In different projects • With different teams • Using different (programming) languages
  6. Great! Another bug! Or how to spend all day with the whole team to fix a tiny bug
  7. Mummy.... Where do bugs come from?
  8. Well.... Once upon a time there was a project
  9. Context • Global company • Large public web application • Mission critical, 24/7 • Major revenue source for the company • First agile project for this team • I coach the team • We need to modify and extend a small section of the application
  10. The project The application US
  11. Scene 1: a developer spots a bug
  12. How do you react when someone says “I’ve found a bug” ?
  13. MERCI! Thank You!
  14. 11 steps to perfect code 1. SPOT A PROBLEM 2. THANK THE REPORTER 3. ...
  15. MERCI! Thank You!
  16. Scene 2: What do we do now?
  17. THIS IS NOT A BUG
  18. THIS IS AN OPPORTUNITY
  19. TIPS • Never BLAME • No need to find the “guilty” • Watch your language: – “Exercise”, “Experiment”, “Learn”, “Improve” – “We”, “Our code”, “Our problem” • “Solution Focus” approach
  20. Scene 3: The team performs a Root Cause Analysis 5 developers + architect
  21. Business rule: “The customer can ask for a refund until delivery”
  22. Who can spot the problem? boolean refundAllowed(Product product) { Datetime now = Datetime.now; Datetime final = Datetime.parse("yyyy-MM-dd“, product.deliveryAt()); return now <= final ; }
  23. MERCI! Thank You!
  24. Let’s test the application • Delivery on 27/10/2012 at 16:00 • It is now 26/10/2012 10:20 • 26/10/2012 10:20 <= 27/10/2012 00:00 ?
  25. Let’s test the application • Delivery on 27/10/2012 at 16:00 • It is now 26/10/2012 10:20 • 26/10/2012 10:20 <= 27/10/2012 00:00 ? Refund? YES
  26. Let’s test the application • Delivery on 26/10/2012 at 16:00 • It is now 26/10/2012 10:20 • 26/10/2012 10:20 <= 26/10/2012 00:00 ?
  27. Let’s test the application • Delivery on 26/10/2012 at 16:00 • It is now 26/10/2012 10:20 • 26/10/2012 10:20 <= 26/10/2012 00:00 ? Refund? NO
  28. 11 steps to perfect code 1. SPOT A PROBLEM 2. THANK THE REPORTER 3. REPRODUCE THE PROBLEM 4. ...
  29. Can we fix the bug? The fix is really simple!
  30. 11 steps to perfect code 1. SPOT A PROBLEM 2. THANK THE REPORTER 3. REPRODUCE THE PROBLEM 4. ADD (AT LEAST) ONE FAILING TEST 5. ...
  31. A new test void testRefundGivenWhenDeliveryLaterToday() { Datetime now = DateTime.now ; String endofDay = now.strftime(“yyyy-MM-dd") + " 23:59" ; Product product = ... product.deliveryAt(endOfDay) ; BusinessRule businessRule = ... bool refund = businessRule.refundAllowed(product); assertTrue(refund,“Refund allowed until delivery, even on the day of delivery") ; }
  32. A new test void testRefundGivenWhenDeliveryLaterToday() { Datetime now = DateTime.now ; String endofDay = now.strftime(“yyyy-MM-dd") + " 23:59" ; Product product = ... product.deliveryAt(endOfDay) ; BusinessRule businessRule = ... bool refund = businessRule.refundAllowed(product); assertTrue(refund,“Refund allowed until delivery, even on the day of delivery") ; }
  33. Can we fix the bug? The fix is really simple!
  34. We finally fix the bug boolean refundAllowed(Product product) { Datetime now = Datetime.now; Datetime final = Datetime.parse("yyyy-MM-dd HH:MM”, product.deliveryAt()); return now <= final ; }
  35. Rerun the test void testRefundGivenWhenDeliveryLaterToday() { Datetime now = DateTime.now ; String endofDay = now.strftime(“yyyy-MM-dd") + " 23:59" ; Product product = ... product.deliveryAt(endOfDay) ; BusinessRule businessRule = ... bool refund = businessRule.refundAllowed(product); assertTrue(refund,“Refund allowed until delivery, even on the day of delivery") ; }
  36. 11 steps to perfect code 1. SPOT A PROBLEM 2. THANK THE REPORTER 3. REPRODUCE THE PROBLEM 4. ADD (AT LEAST) ONE FAILING TEST 5. CORRECT THE PROBLEM 6. AND RERUN ALL TESTS UNTIL THEY PASS 7. ...
  37. “This agile thing is going to be very slow if we do this for every bug!” “Yes, but at least now we have some confidence that the bug is fixed correctly and that we haven’t broken anything else.”
  38. “We’ve really applied our team value of ‘quality without compromise’. We took the time to do it right, even if no customer has complained yet.”
  39. “We should contact the team that’s responsible for this code and inform them of our correction.” “There may have been customer complaints already. We should contact the customer support people to see if there are complaints and inform them of the existing problem”
  40. TIPS • Define and make the team values visible at all times • Keep a list of things to do after the Root Cause Analysis (RCA) • Language: – “We should...” => “We will...”
  41. WE WILL... • Contact the development team responsible for this code • Inform the customer support team
  42. 11 steps to perfect code 1. SPOT A PROBLEM 2. THANK THE REPORTER 3. REPRODUCE THE PROBLEM 4. ADD (AT LEAST) ONE FAILING TEST 5. CORRECT THE PROBLEM 6. AND RERUN ALL TESTS UNTIL THEY PASS 7. PERFORM THE ACTIONS OF THE RCA 8. ...
  43. “GOOD JOB!” “Now, back to work!”
  44. THE END And they lived happily ever after...
  45. It’s not over yet!
  46. Scene 4: After the fix The tester joins the developers and architect
  47. 11 steps to perfect code 1. SPOT A PROBLEM 2. THANK THE REPORTER 3. REPRODUCE THE PROBLEM 4. ADD (AT LEAST) ONE FAILING TEST 5. CORRECT THE PROBLEM 6. AND RERUN ALL TESTS UNTIL THEY PASS 7. PERFORM THE ACTIONS OF THE RCA 8. IMPROVE YOUR TESTS 9. ...
  48. How can we improve our tests? We should have found this bug sooner
  49. How can we improve our tests? We should have will fouind this type of bug sooner
  50. How can we improve our tests? We will find this type of bug sooner
  51. Context (2) • Almost 80% code coverage with automated unit tests in the whole application • This module has 100% test coverage • But still contains (at least) one bug • Why? • Let’s look at the tests...
  52. Who can spot the problem? void testRefundGiven() { Product product = ... product.deliveryAt(“2050-12-31 19:00”) ; BusinessRule businessRule = ... bool allowed = businessRule.refundAllowed(product) }
  53. MERCI! Thank You!
  54. How can we improve our tests? • There’s no ASSERT ! – It’s easy to get 100% code coverage that way • Why 2050? – What happens on January 1st 2051? • We need at least 4 tests – Delivery before today – Delivery today before now – Delivery today after now – Delivery after today
  55. Why? • Developers don’t know how to test date and time (and timezone!)-related code – Lots of tests use dates in 2050 • Few developers with unit testing experience • Agile coaching in the past did not include technical practices
  56. We will... • Contact the development team responsible for this code • Inform the customer support team • Add more tests about dates that can serve as examples • Show our example tests to other teams
  57. Developers: “we have a lot to learn about unit testing” Architect: “I’ve always had doubts about our automated tests. Now I know why.” Tester: “If you want, I can help you to define and improve tests”
  58. Let’s dig deeper... Why tests without ASSERT? • Goal: “increase code coverage of automated tests” instead of “increase quality” • Pressure to “do more with less (money and time)” • Not much experience with unit testing • TEST LAST development instead of Test First • No training or coaching on technical practices • Not all Agile coaches in the company have experience with technical practices
  59. We will... • Contact the development team responsible for this code • Inform the customer support team • Add more tests about dates that can serve as examples • Show our example tests to other teams • Apply TDD by pairing with the coach and tester • Raise « lack of technical practice coaching » risk at coach meeting
  60. Systems Thinking
  61. 11 steps to perfect code 1. SPOT A PROBLEM 2. THANK THE REPORTER 3. REPRODUCE THE PROBLEM 4. ADD (AT LEAST) ONE FAILING TEST 5. CORRECT THE PROBLEM 6. AND RERUN ALL TESTS UNTIL THEY PASS 7. PERFORM THE ACTIONS OF THE RCA 8. IMPROVE YOUR TESTS 9. IMPROVE THE WAY YOU WRITE TESTS 10. ...
  62. The End They lived happily ever after... “We have a lot to learn”
  63. It’s not over yet!
  64. Scene 5: After the tests A bug never travels alone...
  65. Is this bug unique?
  66. Let’s search the code... • We find 10 cases where this datetime is parsed – 5 times with “yyyy-MM-dd HH:MM” – 5 times with “yyyy-MM-dd” • Each developer analyses one case • Result: two more bugs
  67. What do you say?
  68. MERCI! Thank You!
  69. And again...
  70. MERCI! Thank You!
  71. 11 steps to perfect code 1. SPOT A PROBLEM 2. THANK THE REPORTER 3. REPRODUCE THE PROBLEM 4. ADD (AT LEAST) ONE FAILING TEST 5. CORRECT THE PROBLEM 6. AND RERUN ALL TESTS UNTIL THEY PASS 7. PERFORM THE ACTIONS OF THE RCA 8. IMPROVE YOUR TESTS 9. IMPROVE THE WAY YOU WRITE TESTS 10. LOOK FOR SIMILAR PROBLEMS. GOTO 2 11. ...
  72. “Quality without compromise”. Easy to say, hard to do “Writing tests and correcting problems is starting to become routine. It goes faster each time we do it.”
  73. Finally, The End? Can we live happily ever after now?
  74. It’s not DONE !
  75. Did you spot another problem?
  76. MERCI! Thank You!
  77. Digging deeper... Why did we introduce the bug? • We aren’t aware that there’s a date+time • We have 10x the same parsing code • => 10 opportunities to make a mistake • Let’s remove the duplication that leads to mistakes
  78. Improving Product class Product { ... // Deprecated: Remove when obsolete String deliveryAt() ; // New: gradually refactor all clients DateTime deliveryAtDateTime() ; ... } From “stringly typed” to “strongly typed”
  79. 11 steps to perfect code 1. SPOT A PROBLEM 2. THANK THE REPORTER 3. REPRODUCE THE PROBLEM 4. ADD (AT LEAST) ONE FAILING TEST 5. CORRECT THE PROBLEM 6. AND RERUN ALL TESTS UNTIL THEY PASS 7. PERFORM THE ACTIONS OF THE RCA 8. IMPROVE YOUR TESTS 9. IMPROVE THE WAY YOU WRITE TESTS 10. LOOK FOR SIMILAR PROBLEMS. GOTO 2 11. MAKE THIS TYPE OF PROBLEM IMPOSSIBLE
  80. TIP • If you think you have to comment your code, think again
  81. With comments class A { void methodA() ; // Call methodA before calling these void methodB() ; void methodC() ; } ... a.methodB() ; // ERROR a.methodA() ; // ERROR!!
  82. Without comment class A { B methodA() ; } class B { void methodB() ; void methodC() ; } a.methodA().methodB() ;
  83. Mummy.... Where do strings come from?
  84. The application ABCDEFGHIJKLMNO ABCDEFGHIJKLMNO System A ABCDEFGHIJKLMNO ABCDEFGHIJKLMNO Application ABCDEFGHIJKLMNO ABCDEFGHIJKLMNO ABCDEFGHIJKLMNO ABCDEFGHIJKLMNO System B
  85. The application(vision) ABCDEFGHIJKLMNO System A L’application ABCDEFGHIJKLMNO System B
  86. We will... • Contact the development team responsible for this code • Inform the customer support team • Add more tests about dates that can serve as examples • Show our example tests to other teams • Apply TDD by pairing with the coach and tester • Raise « lack of technical practice coaching » risk at coach meeting • Encapsulate data coming from outside
  87. LARGE REFACTORING
  88. A3 proposal
  89. A3 Proposal Problem description BEFORE AFTER STEPS: Visualisation 1. .jdlkjds 2. Kmlkdmlkd 3. Dkqjdlkjds 4. Sqkjlkdlksqmk 5. BEER !
  90. TIPS • Keep the A3 visible during the whole refactoring • Put the A3 where it can’t be missed • Limit the number of A3s that can be published
  91. Scene 6: Final act
  92. Looking back 1. 7 team members + one coach have spent all afternoon to correct a 6-character bug? Is this reasonable? 2. In the end, there were a lot less bugs found in test than on “normal” projects. Is there a link? 3. This project was delivered in 5 months instead of the 8 that were estimated. How can you finish faster by going slower?
  93. Theory of Constraints in a nutshell
  94. How much do they deliver? Test & Analysis: Dev: 20 10 Deploy: 15 ???
  95. How much do they deliver? Test & Analysis: Dev: 20 10 Deploy: 15 <= 10
  96. How much do they deliver? Test & Analysis: Dev: 20 10 Deploy: 15 ??? Analysis: Dev: 10 12
  97. How much do they deliver? Test & Analysis: Dev: 20 10 Deploy: 15 <= 15 Analysis: Dev: 10 12
  98. What if development speeds up? Test & Analysis: Dev: 20 20 Deploy: 15 ??? Analysis: Dev: 10 12
  99. Nothing happens? Test & Analysis: Dev: 20 20 Deploy: 15 <= 15 Analysis: Dev: 10 12
  100. Buffers start to fill up! Test & Analysis: Dev: 20 20 Deploy: 15 < 15 Analysis: Dev: 10 12
  101. How much do they deliver? Test & Analysis: Dev: 20 10 Deploy: 15 <= 15 Analysis: Dev: 10 12
  102. What if we go slower? Test & Analysis: Dev: 20 8 Deploy: 17 <= 17 Analysis: Dev: 10 12
  103. Why are we analysing so fast? Test & Analysis: Dev: 20 8 Deploy: 17 <= 17 Analysis: Dev: 10 12
  104. We do less Test & Dev: <= 17 Analysis: 10 Deploy: 8 17 Analysis: Dev: 10 12
  105. Play The Bottleneck Game
  106. Reading tips
  107. How much does quality cost?
  108. TIPS • Once you run out of reported bugs... Apply IDD™ Irritation Driven Development Contact me if you want to become a Certifiable Irritating Person
  109. TIPS • Pair with the bottleneck – ToC calls this “subordinating” • Walk a mile in their shoes – Carefully observe and note irritations – Quietly remove the irritations • Example: pair-installing dev-ops
  110. Summary
  111. 11 steps to a life with less stress 1. SPOT A PROBLEM 2. THANK THE REPORTER 3. REPRODUCE THE PROBLEM 4. ADD (AT LEAST) ONE FAILING TEST 5. CORRECT THE PROBLEM 6. AND RERUN ALL TESTS UNTIL THEY PASS 7. PERFORM THE ACTIONS OF THE RCA 8. IMPROVE YOUR TESTS 9. IMPROVE THE WAY YOU WRITE TESTS 10. LOOK FOR SIMILAR PROBLEMS. GOTO 2 11. MAKE THIS TYPE OF PROBLEM IMPOSSIBLE
  112. But, most importantly...
  113. MERCI! Thank You!
  114. The End And they lived happily ever after
  115. SESSION FEEDBACK
  116. MERCI! Thank You!
  117. Thank you, Dank u, Merci, Danke, Tak, Kiitos, Gracias, Grazie, Tack, Obrigado Consults Programs Manages projects Creates Games Organises conferences NAYIMA We make play work http://www.nayima.be http://www.agilecoach.net

Editor's Notes

  • Portia and Pascal introduce themselves by sharing a bit about their background.
  • Portia and Pascal introduce themselves by sharing a bit about their background.

    • ×