Differences

This shows you the differences between two versions of the page.

--- how_can_we_determine_how_many_undiscovered_defects_we_have [2025/06/30 09:56] – Updated the link hans
+++ how_can_we_determine_how_many_undiscovered_defects_we_have [2025/06/30 09:56] (current) – hans
@@ Line 7: / Line 7: @@
 The problem is that while we can find / fix defects and use things like rate of discovery / fix to look at trends, it really doesn’t tell us anything about end quality from the end user perspective.
-I found this page by Troy Magennis - [https://observablehq.com/@troymagennis/latent-defect-estimation|Latent Defect Estimation]] - where he talks about a way to estimate the amount of total defects we have based on collecting defect data in a slightly different way (basically set up two groups to look at defects in area of interest, and record all duplicates). The approach gives you an estimate for how many undiscovered defects you have which then can be used to improve decision making (eg do we release now?).
+I found this page by Troy Magennis - [[https://observablehq.com/@troymagennis/latent-defect-estimation|Latent Defect Estimation]] - where he talks about a way to estimate the amount of total defects we have based on collecting defect data in a slightly different way (basically set up two groups to look at defects in area of interest, and record all duplicates). The approach gives you an estimate for how many undiscovered defects you have which then can be used to improve decision making (eg do we release now?).
 It seems to me that the approach could be applied in many situations, especially where there is manual or serial testing involved such as many regression test situations, final UAT in projects and so on.