Release is in two days and you cannot test everything. How do you decide what to test?

I would switch from “test everything” to “reduce the most important risk first”, and make the leftover risk visible. Testing cannot prove the absence of defects, so with two days the real deliverable is a clear picture of what we know, what we do not know, and how bad it would be if we are wrong. The release decision belongs to the stakeholders, but they need that picture from me.

Step 1: build a quick risk map (an hour, not a day)

For each feature area or user journey, estimate:

• Impact if it fails: revenue (checkout, payments), legal or compliance, data loss, security, number of users affected, reputational damage.
• Likelihood of failure: how much changed (read the diff or release notes and talk to developers), code complexity, integration points, new third-party dependencies, defect history of the area, how well it is covered by existing automation.

Score each roughly (1 to 3 is enough) and sort by impact times likelihood. The precision does not matter; the conversation does. I would do this with a developer and the product owner in the room, because they know things I do not, such as “we refactored the tax calculation”.

Step 2: allocate effort by tier

• High risk (changed and critical): deep testing, including negative paths, data variations and integration with downstream systems. Exploratory sessions with clear charters.
• Medium risk: the main scenarios and known edge cases.
• Low risk (unchanged, low impact): rely on the automated regression suite and a smoke pass.

Run the automated suite immediately and in parallel so humans spend their time where automation is weak. Testers can split by area to avoid overlap.

Step 3: reduce risk in other ways

Testing is not the only mitigation. I would ask:

• Can the risky change ship behind a feature flag, or roll out to a small percentage of users first?
• Is there a tested rollback plan?
• Is monitoring and alerting in place for the critical journeys on release day?
• Can a non-critical risky item be descoped to the next release?

Step 4: report clearly

Twice a day, a short status that stakeholders can read in a minute:

Tested deeply: checkout with new tax engine (12 scenarios, 2 bugs fixed, 0 open)
Smoke only: profile, wishlist (unchanged this release)
Not tested: CSV export in Safari (low usage, known workaround)
Open risks: refund flow for partial shipments untested end to end. Mitigation: behind flag, off by default
Recommendation: go, with flag off and on-call watching payment error rate

The go/no-go decision is the business’s, made with known residual risk rather than false confidence.

What interviewers look for

• An explicit risk model (impact and likelihood), grounded in what changed.
• Collaboration with developers and product to build it.
• Using automation and non-testing mitigations (flags, rollback, monitoring).
• Transparent reporting of what was not tested, and not quietly cutting corners.

Follow-up questions

• What would make you recommend “no-go”? (An open critical defect in a high-impact flow with no mitigation.)
• How do you avoid being in this position next release? (Earlier involvement, risk discussion in refinement, investment in fast automated regression.)