- This topic has 6 replies, 6 voices, and was last updated 6 years, 6 months ago by
.
-
Posts
-
If you are very close to release and found a major bug in your system what should you do
- Don’t report it since it may block the release and you may be blamed for reporting it too late
- Double check the bug vulnerability
- Report bug and inform Project manager
- If you running out of time for release suggest to add this to release letter.
- etc.
Share your approach / ideas.
I think in this types of situations like finding a major bug close to the release date, it will help a lot to have a meeting including experts and management team from QA, Engineering, Portfolio, and Release Coordination, in this way an agreed decision can be made regarding the issue found and the release.
Probable outcomes could be: Delay the release and fix the bug, Go ahead with the release and fix the bug for a later version and document it as known issue, etc.
Also, a risk evaluation should be made and take actions to try to avoid similar issues in the future (if that is possible!).
Regards.
It depends on rules/agreements/situation.
In any case I advise to notify those who lead the team, ask their opinion on what to do. Bug reported by you is better than bug reported by customers / users in any case.
Person(s) leading the team may have reasons why it should not be reported (“Oh, we decided to drop this requirement” — I heard that once).
If they don’t have reasons why it should not be reported, put it to bag tracker. Show managers or/and customers your issues list and let them decide. I had in practice case when I was overruled on one bug and customer decided to release knowing about other critical bug. Seeing user complains, customer asked the team to do more investigating on both bugs, and hotfix version was released week or two after the main release.
And I saw other case: tester on customer’s side did not report anything, but I reported 3 critical issues and said that issues should be fixed, and release should be postponed for one week. Customers decided to fire their tester and keep me.
@msalazar18 @rpwheeler Thanks your respective replies.
Simple. Raise it in the defect tracking system and inform your test / project manager. After that, it’s no longer your problem. It’s the project manager’s job to determine the response. You might decide to advocate for it a little, but ultimately it’s not your decision, it’s theirs. You have to raise it, at the very least for ass coverage. If it doesn’t get fixed, and the customer finds it, you don’t want to be in the position where your managers find out you knew and never told them.
- You must be logged in to reply to this topic.