Quality is delighting customers
Developer Rejected the bug when---
--Ths Bug is not Genuine.
--Result are not same
Developer Deferred the bug when---
--Priority Of bug may be low
--Lack of time for release
--The bug may not major effect on our application
DEFERRED: If a valid NEW or ASSIGNED bug is decided to be fixed in upcoming releases instead of the current release it is DEFERRED. This bug is ASSIGNED when the time comes.
DROPPED / REJECTED: Test / Development/ Project lead studies the NEW bug and if it is found to be invalid, it is DROPPED / REJECTED. Note that the specific reason for this action needs to be given.
Here the answer:
1. Tester will raised the bug with reproduction steps. Project Team will analysis whether the raised bug is valid or not. If the bug is not able to reproduced in the application . then Project team will "Reject" the bug.
2. If the bug is not so important for the present release, then Project Team will " Deferred" the Bug.
Deferred or Rejected status can be used for both Bugs and Change Requests.
In case of bugs reported, the usage would be as following:
A defect reported holds/attracts the status 'Rejected' if and only if its expectations not comply with specifications (written or implied). However a defect which is not reproducible holds Non Repeatable status.
Note: Even some critical defects may be rejected as intended environment does not allow such a case of crazy usage.
Coming to deferred status, it depends upon several factors like severity & probability, design impact analysis result, time required to fix it, impact on other features, time required to retest bug-fix, unable to judge, stage of product/application to release, etc., so based on these factors stake holders may defer fixing defect or implementing feature in future releases.
Usually to defer an issue it requires approval.