← Back to libraryQuestion 266 of 273
🌀Agile & QAIntermediate

A Critical Bug Found on Release Day (Scenario)

📌 Definition:

A high-pressure scenario where a serious defect is discovered just before (or during) a release. The interview intent is to see whether you stay calm, assess impact objectively, communicate clearly, and help the team make a sound go/no-go decision rather than panicking or hiding the issue.

📖 Detailed Explanation:

The key is a structured response rather than a reflex. First, assess and reproduce: confirm it's real, understand the exact conditions, and determine the blast radius — how many users, which flows, is there data corruption or a security/financial impact. Second, classify severity and priority objectively so the conversation is about facts, not fear. Third, communicate immediately to the stakeholders who own the decision (PO, release manager, dev lead) with a concise summary: what's broken, who's affected, the risk of shipping, and the options. Fourth, present options with trade-offs: block the release and fix, ship with the fix fast-tracked, ship with the risky feature disabled via a flag, or ship and hotfix with a rollback plan. The decision is the team's/business's, informed by QA's assessment. Finally, whatever is decided, ensure a mitigation (rollback plan, monitoring) and capture a follow-up (how did it reach release day — a retro item). Panicking, unilaterally blocking, or staying quiet are all wrong; calm, factual, options-driven communication is right.

🔑 Key Points:
  • Reproduce and scope the blast radius before raising alarm — facts, not panic
  • Classify severity/priority objectively so the discussion is about impact, not fear
  • Communicate immediately to the decision owners with a concise impact summary
  • Offer options with trade-offs: block, fast-fix, disable via flag, or ship+hotfix with rollback
  • The go/no-go call is the team's/business's; ensure a mitigation and a retro follow-up
🌍 Real-World Example:

An hour before release, QA finds that applying two discount codes can make an order total negative. The QA engineer reproduces it, confirms it affects only the rare double-code path, writes a two-line impact summary for the release manager, and recommends disabling multi-code entry via a feature flag so the release proceeds while the fix is developed — a measured decision instead of a blanket block or a risky ship.

📎 Code Example:
RELEASE-DAY DEFECT REPORT  (send to PO / release manager / dev lead)

What:     Applying 2 discount codes yields a NEGATIVE order total
Severity: Critical (financial impact — refunds owed / revenue loss)
Scope:    Only the multi-code path (~2% of orders attempt it)
Data risk: Orders can persist with negative totals
Repro:    Add item > apply CODE10 > apply CODE15 > total < 0

Options:
  A) Block release, fix + retest       (delay ~1 day, zero risk)
  B) Ship with multi-code DISABLED via  (ship today, feature off)
     feature flag; fix next release
  C) Ship + hotfix within hours         (risk window exists)

QA recommendation: B — ship on time, disable the risky path,
fix properly next sprint. Decision is yours.
🎯 Scenario-Based Interview Question:

Scenario: 30 minutes before a major release, you discover a critical bug: under a specific condition, users can see another user's order data. The team is excited to ship and the deadline is firm. Walk through exactly what you do.