Really I’d document it. Report it up to the Product Owner/Stake-holder… basically whoever is responsible for the actual feature. Give them the risk factors, explain the why and what could happen and from there it’s going to be up them. Since testers (whether it’s QAs other DEVs or BAs) it’s not up to them to delay the release. It’s up to the stake-holder. Document, assign risk, show case what that risk could cost the business (not just money, but client trust as well).
If the stakeholder signs off on the deploy, you have it documented well if something goes wrong, or the stakeholder will decide to hold off. Either way you did you part of it.
I worked as a tester on a cross-functional team, so I always brought this up to the entire team so we could discuss the best approach. I would often do a quick risk assessment or get together with other team members to do that. The ultimate decision, IMO and IME, should be made by the business stakeholders, usually represented by a product owner or product manager. Quality is in the eye of the customer.
We have a release manager and product owners who evaluate the risk and severity of the issue. We also have tech leads from several teams swarm the issue if it is deemed a release blocker. So far, in the past couple of years, we have not had a release delayed, but turning over the release to Ops has been delayed by hours.
We also try to avoid this with several layers of automation and limit the “last minute” commits to only absolutely critical stories.
This has happened few times actually, not anymore thankfully. If you are the person who signs off the release so decision is on you & and in my experience heres how we had handled it.
Do you escalate and have it fixed?
It really depend on the nature of the bug, critical bug does not necessary need to resolved right away if its not hurting trust & reputation of the system. However we should still treat it as a quality threat for sure.
Or do you delay the release?
If that issue is a blocker or P1 (threats the integrity of the product) - simply revert that change not the entire release.
Plan for a hotfix after the release?
Yes, few times HotFix also gets deployed, (if that particular feature was a showstopper of the release) its also fine depending upon few factors:
Promised item of the release
Blocker
Damages reputation
Creates lack of trust in the product
Or just allow it to pass if it is low-impact?
May be not - if we know for sure somethings breaking better to revert the change, raise it internally and make sure to get it fixed in the next release.
Given above the decision maker is you. However, if PO or EM is in position to take a final call - inform them everything, up to them how they plan it, you of course will still be the one to inform the impact.
