Bug Status

You Opened a Defect, for that you got a comment that "Its not a defect, this is according to new changes in requirement, later this point will added in requirement document"

What status you will provide for this bug until the requirement update?

Questions by mathan_vel   answers by mathan_vel

Showing Answers 1 - 4 of 4 Answers


  • Oct 10th, 2010

After raising the bug ,when it is informed that it is as per the new requirement and the SRS will be updated soon,the CCB should consider this bug as a document charm(it should not be raised as a product charm) and assign it to the requirement engineer for updating the requirement specification document.

Also this bug can be moved to the deferred state if the CCB finds that there is very less time left for the release and consider it for the next release.


  • Oct 11th, 2010

Bug stataus should be "Wontfix" , because in testing cycle reported bug is bug but in case of developer the bug is new enhancement or new feature by client that's why the bug status be "Wontfix".

  Was this answer useful?  Yes


  • Feb 16th, 2011

There are 2 parts to this answer:

1) The bug that was reported was on Build X which is developed and deployed
based on a frozen set of requirements.

If the product deployed does not confirm to the requirements then the bug is
valid and its incorrect resolution that the developer has provided

Developer should have resolved the bug as Deferred sighting justification on
updated requirements for the feature under question (on which bug is raised).

Once the CR is submitted and accepted for implementation PM has to tag the CR
to a specific release say Y and link the deferred bug to the requirement or vice
versa to enable traction. During the implementation phase once the CR is
implemented the bug needs to be resolved as either Fixed or Won’t Fix (Only in
case the updated requirement is contradicting the initial requirement against
which the defect was reported) Once the build for release Y is released to test,
Tester should retest the specific scenario that caused the defect to regress the
issue. Outcome of regression would be to Close the defect if the proper fix is
provided or reactivate it.

2) In case the Bug is resolved as Won’t Fix. Verify if the requirement is
genuinely updated to contradict the original version as claimed by the developer
in the bug resolution.

Ex: Original Requirement: Word Processor application should support English,
Chinese, French, German Languages and the bug raised was that French language is
not supported. If the CR submitted is dropping French language from the language
set then the bug can be Closed. And in the Test Metric reporting discount this
bug from the Bug Noise as the originally reported bug was genuine. If during
regression you find that the CR is not contradicting the original requirement
moreover the issue reported originally is also fixed in the Build Y. Which is
often the case, Reactivate the bug asking the status to be updated as Fixed
Note: Bug should not be resolved as Won’t Fix in the initial build X it can only
be resolved to this status in Build Y

  Was this answer useful?  Yes


  • Feb 21st, 2011

The developer set the status as "Wont Fix" for this .

We don't have to close the defect.

Once SRS is updated we can reopen the defect by adding comment to the defect.

  Was this answer useful?  Yes

Give your answer:

If you think the above answer is not correct, Please select a reason and add your answer below.


Related Answered Questions


Related Open Questions