The document discusses moving from a defect reporting approach in software testing to a defect prevention approach using lean principles. It notes that preventing defects from the beginning is far more effective than finding faults later. It asks questions about the current state of testing and defect handling to determine opportunities to focus more on prevention activities like exploratory testing earlier and removing the root causes of defects.

1. From Defect Reporting to Defect Prevention A Lean Approach to Software Testing Sune Gynthersen & Lars Thorup BestBrains

2. Who are we? Sune Gynthersen Lean/Agile software consultant Lars Thorup Founder

3. Cost of correcting defects Price Time

4. A brilliant solution

5. No bashing of Waterfall today "All models are wrong; Some models are useful" - George Box

6. A quick status... Number of currently open defects? 10? 50? 100? 1000?

7. A quick status... Prioritization of defects? Priority 1 Priority 2 Priority 3

8. Is it really that bad? "Current software projects spend about 40 to 50 percent of their effort on avoidable rework" - Barry Boehm (2001)

9. A true story (2010) 9000 defects 3 hours per defect (reporting, prioritization, fixing, retest, accept) 6 effective hours a day 220 work days a year = 20 man-years!

10. It reminds me of... How many americans does it take to make a toast?

11. It reminds me of... How many americans does it take to make a toast? Two! One to burn it, one to scrape it

12. What is the cost of delay? A one month delay? A one year delay? Greater salary expenses Lower financial return Decreasing organisational inertia Decreasing trust Short-term prioritization

13. Vi believe... Any undesirable result represents a starting point for generating new learning.

14. We believe... Or in plain english... Every problem is an opportunity

15. The small details... Test versus Quality Assurance?

16. The small details... Test Verification Test-driving Something that should be automated Quality Assurance Early involvement Proactivity Help building the right system in the right quality

17. Conventional wisdom Test/QA should find defects

18. A new hypothesis Prevention is far more effective than fault-finding. Rationale?

19. Focus If Prevention is far more effective than fault-finding That means Quality should be built-in from the beginning Which should produce Significantly higher profitability

20. What factors influence the quality?

21. What can I do? Do more of this Strive to create a common understanding no later than just before development starts Exploratory testing as soon as possible Stop feature work until defects have been corrected Find, understand and remove the causes behind defects Do less of this Manuel regression testing

22. 4 questions for you... What is the most important output from Test/QA? What is the avg. lead-time for defects? ("found" to "fixed") How much undiscovered rework does your team have? How do you reduce the amount of undiscovered rework ?