Bugs are a gentle reminder to respective developer and a sort of alarm for him to check nothing has been skipped as per user and business perspective. Bugs also act as useful and productive communication initiators between tester and developer till the individual loop gets closed either by execution or rejection of a bug. Bugs should be just on surface as close to the product developer as possible. That way it would be quite sensible and meaningful.
A tester must check the purpose of bug reported before submitting it in his/ her list of bugs. A bug is meant to highlight non easing spots in the software built where end user may feel uncomfortable to work. These spots need to be relooked into by developer so as to improvise on it.
An unnecessary or non purposeful bug may act as nothing but an unwanted noise in the sweet tunes of product built. It not only wastes time of tester but of all associated within bug lifecycle chain. These sort of noisy bugs reported may also act as distance creators between tester and developer which will be of no use to anyone in the teams.
Tester must be very cautious while report a bug which itself loses its sanctity being distant from the primary goal or purpose of a product or software.
A tester before adding or reporting a bug in his/ her list of bugs must be very clear about the gravity of problem being reported. As far as possible he/ she must add only those bugs which he/ she is very much clear about. Preferably while reporting a bug, a tester with his/ her knowledge of product being tested must propose a possible solution to development team which should be clear and crisp in nature. If development team finds it useful, there is no point they will not be in agreement to tester(s).
A bug reported goes meaningless most of the time if it is not clearly stated with an indication of benefits from its fixing.