ACCU Agile Approach to Defect Management


Published on

Slides for my ACCU 2011 talk on "Limbo Lower Now" An Agile Approach to Defect Management"

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

ACCU Agile Approach to Defect Management

  1. 1. Limbo Lower Now: An Agile Approach to Defect Management ACCU 2011 Lisa Crispin With Material from Janet Gregory 1
  2. 2. IntroductionMy defect tracking background: As programmer – no DTS Tech support – DTS developed in-house Traditional QA – vendor DTS, customized Agile teams – variety of approaches 2 Copyright 2010: Lisa Crispin
  3. 3. Your Defect Tracking?How about you? How many use a DTS? How many don’t use one? How low is your “defect limbo” bar? 3 Copyright 2010: Lisa Crispin
  4. 4. Takeaways Defects and technical debt When to use a Defect Tracking System Alternatives Defect metrics Setting the bar lower 4 Copyright 2010: Lisa Crispin
  5. 5. Traditional View Bugs must be documented  Especially those found in production Provide information for root cause analysis Knowledge base – did similar bug occur earlier? DTS provides useful metrics 5 Copyright 2010: Lisa Crispin
  6. 6. Lean Development / Agile View Defect queues are queues of rework – waste (Poppendieck) Find, fix test-first, and forget Better yet, prevent  zero bug tolerance Bugs => Technical Debt Small experiments 6 Copyright 2010: Lisa Crispin
  7. 7. ChoicesAn agile approach: Understand the problem Do what works for your team Focus on goals: bug prevention Start simple, add as needed Explore alternatives 7 Copyright 2010: Lisa Crispin
  8. 8. Why Log Bugs – or notWhat are the advantages of using a DTS?What are the downsides to using a DTS? 8 Copyright 2010: Lisa Crispin
  9. 9. Some Advantages of Using DTS Knowledge base  Place to keep supplemental docs Prioritizing Traceability Distributed/large teams Customer ease, visibility, convenience Metrics  Redundant with test-first, frequent releases 9 Copyright 2010: Lisa Crispin
  10. 10. Some Disadvantages of using DTS Overhead Duplicates test Impedes communication Waste  Inaccurate or inadequate reports  Caught during development  Won’t get fixed Doesnt work towards goal  zero defects, bug prevention 10 Copyright 2010: Lisa Crispin
  11. 11. Defect Metrics Traditionally, tell us state of quality, release readiness Using tests to drive incremental, iterative development tells us this Trends more important than numbers Who cares how many bugs found in development? May be useful for team goals Careful how you use metrics 11 Copyright 2010: Lisa Crispin
  12. 12. Some Other Perspectives What we can learn from bugs Alternatives to logging bugs When tracking defects makes sense 12 Copyright 2010: Lisa Crispin
  13. 13. Bugs as the “Hidden Backlog” Acceptance tests = desired behavior Defect reports = misbehavior (Antony Marcano) Ignored defects = missed features  Misbehavior not addressed Defects prioritized over new features  Misbehavior over desired features Information can get lost in DTS 13 Copyright 2010: Lisa Crispin
  14. 14. Choosing to Not Log a Bug Unit-level bugs  Write a test, not a bug Higher-level regression failures  Test usually enough Bugs found during development  Fix immediately  Log on task card 14 Copyright 2010: Lisa Crispin
  15. 15. Choosing to Log a Bug Found in later iteration  Log if not fixed immediately Legacy bugs  Write new story/feature  Dont log if it wont be fixed Found in production  Fix immediately or  Prioritize, estimate, plan Non-bug production issues  “production support requests” 15 Copyright 2010: Lisa Crispin
  16. 16. Other Approaches To Log or Not? How do you decide? 16 Copyright 2010: Lisa Crispin
  17. 17. Alternative Ways to Track Bugs Cards DTS Tests 17 Copyright 2010: Lisa Crispin
  18. 18. Logging Bugs on CardsStory, task or bug cards – physical or online Tangible Visible – color coding Attach screen prints Use when:  Disciplined team  Bugs need high visibility 18 Copyright 2010: Lisa Crispin
  19. 19. Logging Bugs in DTSUse a DTS when Team is distributed Audit requirements Release notes Not all bugs will be fixed immediately Legacy system with lots of defects 19 Copyright 2010: Lisa Crispin
  20. 20. Logging Bugs with TestsUse the test written to reproduce the bug and verify the fix when: Everything learned from fixing bug is captured in test Test can be automated Team is disciplined and writes tests for every bug found 20 Copyright 2010: Lisa Crispin
  21. 21. When to Fix Bugs Fix now  cheaper  prevents technical debt Estimate, prioritize and fix later  complex, high effort  legacy code, may destabilize  customer decision Never fix  about to be rewritten  low risk  dont pretend youll fix if you wont! 21 Copyright 2010: Lisa Crispin
  22. 22. Lowering the Bar Exploring alternatives Preventing bugs in the first place 22 Copyright 2010: Lisa Crispin
  23. 23. Experiment ! Start a new project with no DTS, and see what you need. Set rules - “no more than 10 bugs at once” Use color-coded cards and stickers Fix all bugs Treat bugs as stories 23 Copyright 2010: Lisa Crispin
  24. 24. Make It a Team Problem Understand your needs Choose solution by team consensus  Cards and stickers (real or online)  Story board  Online DTS  Combo: DTS and cards Ask other teams 24 Copyright 2010: Lisa Crispin
  25. 25. Focus On Preventing Defects Teams have achieved zero-defects goal Whole team collaborates on ways to improve quality Use retrospectives Try small experiments 25 Copyright 2010: Lisa Crispin
  26. 26. Let’s Try an Experiment: Part 1 Pair up with the person next to you One of you take the “tester” role, the other is “programmer”. Stand back to back. Testers: Take the mini-schedule out of your badge & open to p. 10 Programmers: take a piece of paper and pen. You cannot ask questions or turn around. Testers: Get the programmer to draw what you see on p. 10 – 11 only by describing the shapes & where they are. Do not turn around! 26 Copyright 2010: Lisa Crispin
  27. 27. Let’s Try an Experiment: Part 2 Programmer: Get a new piece of paper. This time, you are allowed to ask questions. Tester: You may now watch what the programmer draws Point out “defects” immediately, and answer questions.  (Don’t show the actual pages, we’re trying to simulate real-life coding here!) 27 Copyright 2010: Lisa Crispin
  28. 28. Bug Prevention! Make testing integrated part of development Practice TDD and Specification by Example Gain domain expertise Exploratory testing by testing professionals Consider ripple effects of code changes Look at problem areas, experiment with solutions 28 Copyright 2010: Lisa Crispin
  29. 29. Action! Think of one thing your team can do to prevent defects, starting next week. Write it on an index card along with your email address. Exchange cards with the person next to you. Email each other every week for 4 weeks with encouragement, questions, support. Please let me know your results! 29 Copyright 2010: Lisa Crispin
  30. 30. How Low Can You Go? Experiment to find defect management approach that fits best Zero defects is achievable  But go for baby steps Focus on bug prevention Do what works for your team Test/code together Use retrospectives 30 Copyright 2010: Lisa Crispin
  31. 31. Agile TestingAgile Testing: A Practical Guide for Testers and AgileTeamsBy Lisa Crispin and Janet Gregorywww.agiletester.caBook signing after this sessionat the bookstore Copyright 2010: Lisa Crispin 31
  32. 32. All Proceeds to Charity!Beautiful Testing: Leading Professionals Reveal HowThey Improve SoftwareEdited by Tim Riley, Adam GoucherIncludes chapter by yours truly Copyright 2010: Lisa Crispin 32
  33. 33. Specification by ExampleHow successful teams deliver the rightsoftwareGojko AdzicCase studies from > 50 teams 33 Copyright 2010: Lisa Crispin Copyright 2008 Janet Gregory, DragonFire
  34. 34. RecommendedBridging the Communication Gap:Specification By Example and AcceptanceTestingGojko Adzic 34 Copyright 2010: Lisa Crispin
  35. 35. RecommendedThe Agile SamuraiJonathan RasmussenGreat intro to agileand agile testing 35 Copyright 2010: Lisa Crispin
  36. 36. Lean DevelopmentImplementing Lean Development:From Concept to CashMary and Tom Poppendieck Copyright 2010: Lisa Crispin 36
  37. 37. Some Agile Testing Resources 37 Copyright 2010: Lisa Crispin
  38. 38. Questions? 38 Copyright 2010: Lisa Crispin