In such situation, Firstly, I with my team members, will try to find out the cause for it. And with discussion with developers also, we will try to fix that out. And will work extra hours to get it fixed, and do testing again.
And if the defect will take time to be resolved, then we will talk to Project Manager, that we can't send this release, as it has this defect, and we are working on it.
Its better to send the release late, but it should be bug free. Whats the fun, if we send the release on time, but it has many defects, that the customer is not satisfied.
1 User has rated as useful.
Login to rate this answer.
One thing we have to do is measure the severity and frequency of that defect .
If it is having High Severity and low frequency of occurance then we can make the bug as known issue and move it to maintainance phase.
If it is having high severity and high occurence then we have to fix the bug immediately and test.
Correct me , if i am wrong
1 User has rated as useful.
Login to rate this answer.
@ gsrmohan: I agree with you.
Qa needs to know what is the frequency of the bug even if it has high severity or high priority. You can check the frequency by visiting user traffic data such as : how many users visit this feature through the route described in the bug report; how many user actually visit this feature; etc.
If this bug occurrence frequency is high then I would estimate the EXTRA time and budget needed to (a) fix the bug (b) run end-to-end business scenarios (c) perform some regression testing. Of course my wonderful QA team will help me with all the efforts estimation
I will then hold a meeting with PM and BA and discuss about the impact and risk of going live with the bug, and how much money and time will be required to fix the bug should the client decide to go live with this major bug.
I totally agree with Preetchana "Its better to send the release late, but it should be bug free. Whats the fun, if we send the release on time, but it has many defects, that the customer is not satisfied."
Login to rate this answer.
we have to raise a defect and gave seniority as S2 and discussed with IT people explain the situation and try them as much as possible in case those people are not yet complete then that is not a problem to go for release because at release time the entire build will having 2% S1 defects 5% S2 defects then also our project will go live.those defects will be removed at normalization level.
Login to rate this answer.
