There is a strong opinion that if a bug is difficult to reproduce, we shouldn’t spend a lot of time on it. It would be better to move on and check something else.

However, some QA specialists spend lots of time looking for the causes of such a bug. Hence, they simply leave the testing process paused. But is there a middle ground for all this?

First and foremost, it all depends on the current circumstances. It is possible to distinguish both the reasons for continuing to detect an error and the reasons for postponing such a process for later.

Pro Arguments

1. It’s Bad When the Defect Occurs

You, as a tester, may check software where everything is properly configured and functions correctly. But if a defect occurs, the system simply breaks down, or an important piece of information disappears. Such things should be prevented in any way. Even if the error is reproduced only in 2% of test cases, it is extremely important to understand what exactly is happening since one small error can cause the failure of the entire system.

2. The Bug Is Unstable but It Occurs Very Often

Let’s say we have software that will only be used in a systematic manner (irregularly). When authorizing, the product accepts the entered data in 50% of cases and fails in the rest cases.

You’ll agree, this is a rather unpleasant situation. No one wants their product to be criticized, given poor ratings, and changed to some other products after being used only several times.

In other words, any bug, even if it is not always visible, is still worth fixing to avoid potentially negative user attitudes.

3. The Bug Is Related to Important Technical Problems

The software under test may function well with multiple test users but while common use, there are total technical failures. QA mustn’t pass over such things and say, “everything worked fine when I tested it”.

Such defects indicate the fact that the software has certain problems when working with the load. These can be problems with memory leaks, or requests to the server take a long time, and the error is getting worse with an increasing number of requests.

But regardless of the real reason, it is extremely important to find such a bug and fix it until real users start interacting with the product.

Cons Arguments

1. Testing Is Performed for a Long Time but the Bug Was Reproduced Only Once

Software is an unstable thing and certainly not ideal in its functioning. It can have the most unpredictable technical troubles (power drops, problems with the Internet connection, etc.).

The defect detected only once can be connected with absolutely everything. We should remember about it but probably not to look for it intentionally. Nevertheless, if we see it again then we should definitely ask developers to fix it.

2. Time Is Short but You’re Sure That the Detected Bug Isn’t Risky

You must admit that this is bad when real users found a bug. And when asked why it wasn’t fixed during testing, the quality control companies reply that everyone was in hurry and there was simply no time to explore the problem.

Nevertheless, if the defect is connected with something a user will never do, and there’s really a lack of time, it’s a good choice to wait till the final release and solve the problem later.

An illustrative example: a development department is going to release the functionality for a user account. Several testers checked it and they didn’t find any critical defects. But on the day the functionality is released, it turns out that the personal account does not work if you enter more than 16 special characters in the “password” field. In such a case, you should release this functionality, and fix that issue later.

3. Was There a Bug? (Instead of Conclusion)

Usually, when QA faces a very strange defect, he/she should ask oneself – can it wait or he/she must deal with it right now? Bug severity, its frequency of occurrence, and its possible presence during real usage will help a QA specialist to make the most important and correct decision right now.