I see 5 cases: Code | Test | Result -------------------------------------------------- fine | fine | a) We have a regression test, yay! fin

I see 5 cases: Code | Test | Result -------------------------------------------------- fine | fine | a) We have a regression test, yay! fine | buggy | b) Someone breaks the code to make the test work. Oops. c) Someone fixes the test, we have a regression test, yay! buggy | fine | d) We'll fix the code, and we have a regression test, yay! buggy | buggy | e) Bug remains in code. Oops. If the probability of introducing an error is p, Code | Test | Probabilities | p = .01 (one in ten) -------------------------------------------------- fine | fine | a) (1-p) * (1-p) | .9801 fine | buggy | b) (1-p) * p * .5 | .00495 c) (1-p) * p * .5 | .00495 buggy | fine | d) p * (1-p) | .0099 buggy | buggy | e) p * p | .0001 So we see, probability for: no harm done .9801 (a) bugs found + fixed .01485 (c,d) bugs introduced / not found .00505 (b,e) The above completely ignores the fact, that depending on the code base there will be significantly more test code than production code. But then test code is quite often highly redundant, and might actually have a lower defect rate itself. Also the probability on introducing an error in the production code and the test code, might actually not be statistically independent, which I assumes here. So take with a grain of salt. [Edit] Actually d) could also end negatively. Guess a working model would have to take into account that on failing test cases, a sensible developer should take a step back and reason about why this happened. So the negative outcomes would be (hopefully) less likely than the positive ones here.