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.

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

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