This number surprised me. In all 3 projects (every project has a different size, complexity and team) there’s a 75% rate of open non-reproducible bugs.

What does this mean?

I know we’re not doing enough to reproduce bugs. I take that as a given. I also think that since it’s more easy to fix reproducible bugs, the focus is more on them.

But what we’re seeing is that only 1 of 4 non-reproducible bugs actually gets fixed. So the accumulating numbers of open bugs includes the other 3.

Unless it actually gets reproduced at the customer’s(apparently, the ones that do are not high-severity, and not that traumatic) they get “stale” and not discussed regularly.

So in reality, we do treat non-reproducible bugs differently. Should we target to lower them?
Let’s say we set a goal: no more than 25% open reproducible. What can happen?

• Tester will not report them. (gaming the system).
• Testing effort will concentrate on reproduction, instead on other facets of the application. I expect at this point, the PMs will not like that, and eventually will revert to the current status

My favorite option goes back to the developers. If they produce less buggy code, testers will have to concentrate more on those bugs, since there will not be much other stuff to work on. So I don’t think will settle for a non-reproducible goal now. Need to concentrate more on developer goals.