To Log, or Not to Log: That is the Question - A Comprehensive Guideline for Testers When to Abstain from Logging Defects

1. Bug VS Defects

When the developed code or a piece of software feature has deviated from the idea or the requirements, it is called defects, it is a broader term. On the other hand, bugs are flaws in a system that produce unintended behaviour or results, mainly because the function is not working as intended.

2. When testers should abstain from logging a bug/Defect

• Bug not reproducible: When a bug couldn't be reproducible and the root cause is unknown for the bug

• Known Issue: If the bug/Defect is known to the team and it is already called out then the bug should not be logged by the testers it is the dev team's responsibility to log the bug because they already know the root cause of the bug and logging and investigating the bug by a tester will cost more time.

• User- Misuse: GIGO is a term which means garbage in and garbage out, when a user misuses the software and the software doesn't perform as intended because of the misuse, should not get logged as a bug or defect.

• Cosmetic Bugs: Every cosmetic defect should not logged against any bug ticket, Testers could open a general ticket with the title with "cosmetic bug" or "UI change" and all the issues should be logged in that ticket

• Documentation Gap: If the documentation does not contain information about certain things in the features and if it does not briefly show how it should impact the software, testers should refrain from logging any bugs on this matter rather the activity should divert to enriching the documentation or requirements.

• Feedback or Feature requests: If the testers propose any feedback or request for a feature it should not be logged as a bug, it should be an enhancement ticket.

• ML algorithm enhancement: If in any ML algorithm the model misses some classification problem if it is not vital or does not have proper documentation about its occurrence in software it should not logged as defects it should be mentioned in a team meeting and proper documentation should be done on how frequently the problem occurs, if it occurs frequently and the problem is severe it should be logged as bug/defect.

• Duplication of a bug or Root Cause: If a bug is duplicated it should not get logged, the Root cause of a bug could be the same, if the root cause of several bugs is the same testers should refrain from logging bugs for every defect.

• Network Issue: If the issue is only persistent through the unstable network connection or there is not anything to do from the software side it should not be logged as a bug.

When a bug should go to the backlog or block a ticket could be another discussion. Hopefully, we will talk about this in future

In conclusion, for robust and efficient software development we should have careful consideration when to log a bug or not. This comprehensive guideline aims to empower testers with the discernment to differentiate between scenarios where logging is imperative and instances where abstaining might be the wiser course of action.