From Defect Reporting To Defect Prevention

1,368 views

Published on

A talk given at DANSK-IT's Softwaretest 2010 conference.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,368
On SlideShare
0
From Embeds
0
Number of Embeds
18
Actions
Shares
0
Downloads
65
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Vi kommer med udviklerbaggrund. Det skal være i jeres gode ret at mene vi har jord i hovedet. Vi prøver at anlægge et helhedorienteret perspektiv.
  • En gammel klassiker Den er få vel uenige i...?
  • Når fejlrettelser bliver eksponentielt dyrere over tid, er det et under at vandfaldsmodellen er i brug - Her tester vi, med vilje, så sent som muligt
  • Selvom vi kunne bruge timevis på det, så skal det jo ikke bare handle om at sige grimme ting om vandfaldsmodellen. Som den gode statistiker George Box sagde...
  • Hvor mange har så mange prioritet 1 og 2 fejl, at der reelt aldrig bliver rettet prioritet 3 fejl. Grov prioritering er god - men man risikerer at holde folk for nar, hvis man beder dem registrere defects, som alle ved aldrig vil blive fikset.
  • En fælles kollega gav os lidt defect statistik (baseret på overslag)
  • Den ekstra omkostning er nem at beregne: 20x gennemsnitlig årsløn. Detaljerne er sværere at regne på - men de er ikke små. * Større lønudgifter * Manglende indtjening * Faldende tillid * Organisatorisk træghed * Kortsigtet prioritering
  • Det lyder som en floskel, men... Ethvert problem er en mulighed. Uhensigtsmæssighed (f.eks. defekter) Uhensigtsmæssigheder er en perfekt anledning til at stoppe op, og spørge sig selv: Lærer vi i dag af vores fejl? Hvad kunne vi lære af vores fejl? Hvor hurtigt lærer vi af vores fejl?
  • Hvordan navngiver vi rollen? Lars har sagt at det er en 20 år gammel diskussion i test-kredse. Jeg (Sune) er ikke rigtigt stødt på før.
  • Når *vi* hører Test vs. QA tænker vi følgende... Test: Noget der burde automatiseres.
  • Det vil vi gøre op med Softwaretestere skal i mindre grad end tidligere  finde fejl. Fejl er et udtryk for en dysfunktionel process. En process der ikke resulterer i den ønskede kvalitet. Videre til "En ny hypotese"
  • Testere bør finde færre fejl pr. feature, over tid. Hvis de ikke finder færre er det måske tegn på at kvaliteten af udviklingsprocessen ikke bliver bedre. Vi mener ikke at  testere ikke skal finde fejl. Men når de gør.. er det et tegn på at der er gået noget galt et andet sted.
  • Kvalitet skal indbygges fra starten (i modsætning til at "teste" det ind senere) Hvis kvaliteten skal indbygges fra start...
  • Så må vi spørge os selv - Hvilke faktorer har indflydelse på kvaliteten? Materiale: f.eks. krav - hvordan afgøres kvaliteten af indkomne krav? Mennesker: Er de rette kompetencer til stede? og på det rette tidspunkt? Værktøjer: F.eks.miljø (automatisk build og test).  Har vi testværktøjer der understøtter den process vi ønsker os? For mig er det vigtigt at værktøjsvalg ikke bliver et spørgsmål om vi *kan* teste, men om vi kan teste *effektivt*. Skalerer testmetoden? I hvilken grad skaber vi en vedligeholdelsesbyrde? Process: Process er altafgørende - ethvert resultat er en direkte konsekvens af den forudgående process. Det gælder også kvaliteten.
  • Ukendt udestående arbejde. D.v.s. opgaver i endnu ikke har identificeret (f.eks. fejlrettelser)
  • From Defect Reporting To Defect Prevention

    1. 1. From Defect Reporting  to Defect Prevention A Lean Approach to Software Testing Sune Gynthersen & Lars Thorup BestBrains
    2. 2. Who are we? <ul><li>Sune Gynthersen </li></ul><ul><li>Lean/Agile software consultant </li></ul><ul><li>Lars Thorup </li></ul><ul><li>Founder </li></ul>
    3. 3. Cost of correcting defects Price Time
    4. 4. A brilliant solution
    5. 5. No bashing of Waterfall today <ul><li>&quot;All models are wrong; Some models are useful&quot; </li></ul><ul><li>- George Box </li></ul>
    6. 6. A quick status... <ul><ul><li>Number of currently open defects? </li></ul></ul><ul><ul><ul><li>10? </li></ul></ul></ul><ul><ul><ul><li>50? </li></ul></ul></ul><ul><ul><ul><li>100? </li></ul></ul></ul><ul><ul><ul><li>1000? </li></ul></ul></ul>
    7. 7. A quick status... <ul><ul><li>Prioritization of defects? </li></ul></ul><ul><ul><ul><li>Priority 1 </li></ul></ul></ul><ul><ul><ul><li>Priority 2 </li></ul></ul></ul><ul><ul><ul><li>Priority 3 </li></ul></ul></ul>
    8. 8. Is it really that bad? <ul><li>&quot;Current software projects spend about </li></ul><ul><li>40 to 50 percent of their effort on avoidable rework&quot; </li></ul><ul><li>- Barry Boehm (2001) </li></ul>
    9. 9. A true story (2010) <ul><ul><li>9000 defects </li></ul></ul><ul><ul><ul><li>3 hours per defect (reporting, prioritization, fixing, retest, accept) </li></ul></ul></ul><ul><ul><ul><li>6 effective hours a day </li></ul></ul></ul><ul><ul><ul><li>220 work days a year </li></ul></ul></ul><ul><li>         = 20 man-years! </li></ul>
    10. 10. It reminds me of... <ul><li>How many americans does  </li></ul><ul><li>it take to make a toast? </li></ul>
    11. 11. It reminds me of... <ul><li>How many americans does  </li></ul><ul><li>it take to make a toast? </li></ul><ul><li>Two!  </li></ul><ul><li>One to burn it, one to scrape it </li></ul>
    12. 12. What is the cost of delay? <ul><ul><li>A one month delay? </li></ul></ul><ul><ul><li>A one year delay? </li></ul></ul>Greater salary expenses Lower financial return Decreasing organisational inertia Decreasing trust Short-term prioritization
    13. 13. Vi believe... <ul><ul><li>Any undesirable result represents a starting point for generating new learning. </li></ul></ul>
    14. 14. We believe... <ul><li>Or in plain english... </li></ul><ul><li>Every problem is an opportunity </li></ul>
    15. 15. The small details... <ul><ul><li>Test versus Quality Assurance? </li></ul></ul>
    16. 16. The small details... <ul><ul><li>Test </li></ul></ul><ul><ul><ul><li>Verification </li></ul></ul></ul><ul><ul><ul><li>Test-driving </li></ul></ul></ul><ul><ul><ul><li>Something that should be automated </li></ul></ul></ul><ul><ul><li>Quality Assurance </li></ul></ul><ul><ul><ul><li>Early involvement </li></ul></ul></ul><ul><ul><ul><li>Proactivity </li></ul></ul></ul><ul><ul><ul><li>Help building the right system in the right  quality </li></ul></ul></ul>
    17. 17. Conventional wisdom <ul><li>Test/QA should find defects </li></ul>
    18. 18. A new hypothesis <ul><li>Prevention is far more effective than fault-finding. </li></ul><ul><li>Rationale? </li></ul>
    19. 19. Focus <ul><li>If </li></ul><ul><li>Prevention is far more effective than fault-finding </li></ul><ul><li>That means </li></ul><ul><li>Quality should be built-in from the beginning </li></ul><ul><li>Which should produce </li></ul><ul><li>Significantly higher profitability </li></ul>
    20. 20. What factors influence the quality?
    21. 21. What can I do? <ul><li>Do more of this </li></ul><ul><ul><li>Strive to create a common understanding </li></ul></ul><ul><ul><ul><li>no later than just before development starts </li></ul></ul></ul><ul><ul><li>Exploratory testing </li></ul></ul><ul><ul><ul><li>as soon as possible </li></ul></ul></ul><ul><ul><li>Stop feature work </li></ul></ul><ul><ul><ul><li>until defects have been corrected </li></ul></ul></ul><ul><ul><li>Find, understand and remove the causes behind defects </li></ul></ul><ul><li>  </li></ul><ul><li>Do less of this </li></ul><ul><ul><li>Manuel regression testing </li></ul></ul>
    22. 22. 4 questions for you... <ul><ul><li>What is the most important output from Test/QA? </li></ul></ul><ul><ul><li>What is the avg. lead-time for defects? (&quot;found&quot; to &quot;fixed&quot;) </li></ul></ul><ul><ul><li>How much  undiscovered rework does your team have? </li></ul></ul><ul><ul><li>How do you reduce the amount of  undiscovered rework ? </li></ul></ul>

    ×