How to Deal with Non-Reproducible or Invalid Bugs

How to Deal with Non-Reproducible or Invalid Bugs

If a bug is non-reproducible always (for example, it occurs only after 3 failed attempts), you should include information on this inconsistency in your bug report.

In order not to create invalid bugs, you should look for such bugs in the issue tracking system (maybe someone already encountered it and created this INVALID variant). If a tester doubts whether it is a bug or not, you can read the software requirements, or ask your colleagues, lead management or developers for help or investigate the problem from other accessible point of view ( for instance, technical one): read the logs or log files, compare the behavior of interface’s different parts, exercise the settings.

You cannot be completely safeguarded against invalid bug as it isn’t that easy to avoid creating them. As a rule, invalid bugs are written mostly by testers unfamiliar with the functionality being tested (and if the functionality is new, then everyone has small knowledge of it). Therefore, you should not be afraid of writing invalid bugs, because an invalid bug is better than a missing one.

After the bug has been remarked as RESOLVED, the tester, as a rule, should check whether the bug has indeed been fixed (or whether it is actually a duplicate bug). This process is called verification, and based on its results, the tester must change the state of the bug from RESOLVED to VERIFIED (if he agrees to close the bug, for example, this bug hasn’t manifested itself anymore) or REOPENED (in the opposite case).

Good news! Cost-effective pen testing services are provided by a leading overseas company located in Cherkassy city! Now everyone in the world can test their security defenses in real-life conditions! Take your chance to identify and address cyber risks that could leave your enterprise open to attack.  

There are situations when testers and developers disagreeing with each other ping-pong a bug: a developer marks it INVALID, while a tester assigns it a status REOPENED. In such cases, if the tester does not approve the second resolution, you should not reopen the bug a second time: you should attract the lead management to analyze the situation and solve the problem with time. In the event that the bug is reopened a second time, lead management should cooperate with the testing and development teams to get the work done quickly and effectively.

Conflicts between testers and developers have long been the subject of anecdote, because, as a rule, those cannot be resolved by the immediate supervisor (the test leader and the development leader is not the same person ) and the boss at one rank higher or even two levels higher (depending on of the size of the organization).