I’m talking about, essentially all the non-functional type bugs I think. Google lists things like Latent bugs, dormant bugs, heisenbugs, masked bugs, and zero-day bugs. Which is a great way to start. So I’m thinking about all the bugs that customers will either be incredibly unlucky to find because they are either in unreachable or dead code-paths. Code that might be pruned by the building process even, code that is just plain sloppy and bad style, things that a linter would complain about. For example comparing a variable to const without the const being on the lefthand side, and all the way up to inefficient loop code that is unlikely to have impacts. Duplicated code, where the code is duplicated literally in 2 places for instance… I would like to also throw in any non-functional bugs you would not want to fix, because the fix would do nothing tangible, and would generate a huge code-diff that just messes up the blame history. Things that even unit tests are unlikely to detect.
Hidden performance bugs, and security bugs have their own spaces really, calling them invisible/undetectable bugs just feels wrong when many of them are visible with extreme code-review or linter tooling. Has anyone ever come across a good all-in-one category or name for bugs that are just so low risk they are not worth fixing unless the code-police come down hard?
What about emergent bugs? A bit like emergent requirements.
i’d separate hidden defects from code quality debt.
if the behavior can produce an incorrect user or system outcome under some reachable condition, even a rare one, “latent defect” works. stale sessions, unusual permission combinations, race conditions, or feature-flag paths fit there.
duplicated code, awkward comparisons, dead code, and inefficient loops are usually code smells or technical debt until you can connect them to a failed quality attribute. calling all of them bugs makes the backlog impossible to reason about.
i’d track three fields instead of chasing one label: reachability, consequence, and detectability. “emergent defect” is useful when the failure only appears from interactions between otherwise acceptable parts.
I love how testers always want to classify things down into detail 
I think this was one thing I wanted to do with this, but I was also looking at what is the general catch-all for these latent defects, But in order to use them and give them any kind of statistical meaning and size, you do have to break them down into each area or category, and then pop them all together in a corner and say, this is stuff we know might be a problem in future, but might also go away entirely in future.
An interesting picture to have is when you have a super simple system. Just for example. In a simple system, it becomes possible to go into fine detail and perhaps say that you might have 5 big defects, 10 small know bugs you don’t intend to fix and then a few talking point where you know there are Heisen-bugs. I guess there will always be people who will defend code-quality-bugs. I might be one of those people, so I think , these known code static-analysis issues actually need to be in a basket alongside real bugs, because you know what you need to do about the code-quality bugs already. And so in a way code quality is not “undetectable”, because your linter already detected them.
I’m pretty sure if I boiled this for longer, I would find ways to separate and address quality issues that might have been just lost in a corner and left there because I did not have a way to address them, so I just did not try to quarantine them in the first place.
Latent Defects - simple, clear.