The 6 Trickiest Types of Software Bugs You Should Know
QA software testing is a hard business as software bugs can be surprisingly tricky at times. The trickiest of them even have names. So if you are overwhelmed with bugs constantly popping up where you never expected, chill out and look at the following 6 unusual software bugs that make QA testing almost unbearable since they are too difficult to track and fix.
1. Heisenbug
This is a type of bugs which disappear or change their characteristics as soon as somebody’s trying to study them. The examples of a heisenbug can sometimes be found in a program’s released version compile, but never in its debug-mode version.. Such a bug can also be caused by the race condition.
2. Bohrbug
This type of bugs manifests itself consistently only under some well-defined but often unknown or unique set of conditions or entered data. Luckily, these bugs don’t alter when researched, but they are pretty difficult to find and fix. Besides, they often persist in a product during its operational phase of development. Bohrbugs often sit in those pieces of source code which are invoked least often. Some even call them ghosts haunting the code.
3. Mandelbug
A computer bug of this kind has such complex causes that its behavior gets chaotic. Some use the term “mandelbug” to refer bugs with very complex causes which make it impossible to find some practical solution. Such a bug can be caused, for instance, by some flaw in the entire system’s fundamental design.
4. Schroedinbug
This bug only manifests when somebody using a program in some unusual way or reading source code notices it should have never worked at all, and at this point that program stops working promptly right until it’s fixed.
5. Phase of the Moon bug
“Phase of the moon” usually is something signifying a silly parameter a bug may depend on,. This bug is rare and especially irritating. One example is a appearing at some special time in a program vulnerable to some time-dependent failures.
6. Statistical bug
Such tricky bugs can be detected only in aggregates rather than in single code section runs. These bugs usually affect the code supposed to produce some random and pseudo-random output. It’s impossible to properly to trace this bug in a single run since its input is supposed to be random and there’s no way to say if the input is wrong.
