The release ships tomorrow and you are only halfway through regression. What do you do?

Spend the first thirty minutes not testing

The reflex answer is to test faster, and it is the answer that loses the interview. Working through the remaining half in the order it happens to be written treats every case as equally valuable, which is the assumption that got you here. The first move is to find out what this release actually is.

Get the list of changes. Not the release notes, the changed code: which modules, which services, which database migrations, which configuration and feature flags. Then get the deployment shape — is this all-or-nothing, or can it go out behind flags, to a canary, or as a staged percentage rollout — because that changes what "untested" costs. And check what has already run without you: the automated suite results, the last nightly, whatever ran in the previous environment. There is often more evidence available than the manual regression sheet suggests, and reconciling it takes minutes.

Now you can re-plan the remaining hours. Nothing about that plan should resemble the original order.

Order the remaining time by risk, not by the test plan

Risk here is the ordinary product of two things: how likely something is to be broken, and how bad it is if it is. Likelihood is dominated by proximity to the change, so anything touched by this release, anything sharing a module or a table with what was touched, and anything with a history of defects in that area goes to the front. Impact is dominated by consequence, so money movement, authentication and authorisation, anything that writes or migrates data, anything a regulator or an auditor cares about, and anything a customer cannot work around.

That gives you a first band that you test regardless: the changed functionality end to end, the paths that take payment, the login and permission boundaries, one full journey for each major user type, upgrade and migration from the current production version, and rollback. Rollback is on that list deliberately and is the one candidates forget; if you cannot get back, every other risk on the page gets worse.

The second band is what you sample rather than cover. Unchanged areas already covered by automation get their automated result cited and no manual repeat. High-traffic areas far from the change get one representative journey rather than the full matrix. And you should be explicit that a sample is a sample.

The third band is what you consciously drop: cosmetic issues, rarely-used administrative screens, edge-case permutations of unchanged logic, browsers or devices with negligible share. Dropping these is a decision with a reason attached, which is different from running out of time before you reached them.

Two things are worth doing in parallel. Ask for help with a specific scope rather than in general — "can two developers each take one of these two areas for ninety minutes, here are the charters" gets a yes far more often than "we need more resource". And stop logging low-severity cosmetic defects into a triage queue nobody will read tonight; note them for after the release and keep your remaining attention on finding things that would change the ship decision.

Report coverage as a list, never as a percentage

This is where the scenario is really being marked, because it is the part with a wrong answer that feels like a right one. "Regression is 78 percent complete and we have found no blockers" is a sentence that will be read as "it is fine". It implies that the missing 22 percent is uniformly distributed and unimportant, and it converts your incomplete testing into an implied assurance you did not give.

Write it as three distinct categories instead, with the third one impossible to skim past.

Status	Meaning	Example
Tested, passed	Executed this build, result recorded	Checkout with card and wallet, all changed order APIs
Tested, issues known	Executed, defects open, severity stated	Bulk export: totals correct, column order wrong (sev 3, DEF-4412)
Not tested	Not opened at all this cycle	Refunds, saved-address management, IE-equivalent legacy browser pack

Then for each item in the third row, say what it would look like if it were broken and how you would find out. "Refunds were not retested. The refund service was not changed this release, but it reads the order table that the migration altered. If it is broken, the symptom is a refund failing with a 500 rather than a wrong amount, and it would show in the payment error alert within minutes." That paragraph is worth more than the rest of the report, because it converts an unknown into a monitored risk.

The phrases to refuse to write are the ones that borrow credibility you have not earned: "no major issues found", "regression complete", "no blockers", and "signed off" — when what happened is that you did not look. A tester whose green reports have historically meant "we checked" and who then issues one meaning "we sampled" has spent the only asset the role has.

Alongside the risk, bring the things that make it survivable

A report that only contains bad news puts the decision-maker in a corner, and it is not the most useful thing you can do with what you know. Every untested area has a cheap mitigation, and proposing them is what makes you a participant in the release rather than an obstacle to it.

Put the untested feature behind a flag that ships off, so the code deploys and the behaviour does not. Roll out to a small percentage or a single internal cohort first, so the first users of the untested path are ones you can call. Add a targeted alert on the specific paths you could not cover, rather than trusting general dashboards. Confirm the rollback has been rehearsed, not just documented. Brief support on what to escalate and how to recognise it. Schedule the deferred testing for the day after with a named owner, so "not tested" does not quietly become "never tested".

Options are also better than a verdict. "Ship all of it tonight", "ship with the export feature flagged off and test it Thursday", "ship to ten percent and hold", and "delay 24 hours and complete band two" are four positions with different costs, and presenting them with your recommendation attached is a materially more useful contribution than a yes or a no.

Recommending is your job; deciding is not

The last thing the question tests is whether you know the boundary of your authority, and candidates miss it in both directions.

One failure is the martyr: "I would work through the night and get it done." It answers a different question, it is usually not true, and it says you would rather absorb a planning failure personally than surface it. The other failure is the gatekeeper: "I would refuse to sign off and block the release." Testers do not have a veto, and asserting one you do not have gets the decision made without you next time.

What you own is the quality information and a clear recommendation based on it. What you do not own is the trade-off between that risk and a contractual date, a marketing commitment, a dependent partner launch, or a security fix that is more dangerous to hold than to ship. The person who carries that consequence — product owner, release manager, whoever your organisation names — makes the call, and they are entitled to make it against your recommendation with the facts in front of them.

Record it, and be honest about why. It is not to build a file for the day it goes wrong; that motive is transparent and it poisons the relationship. It is because a risk that was accepted in a corridor conversation gets no mitigation, no monitoring, and no follow-up test, whereas a risk written into the release ticket gets all three. A short note that says what was untested, what was recommended, what was decided, and by whom is the difference between a managed risk and an accident waiting to be reconstructed.

Then fix the cause afterwards. A regression pack that cannot complete inside its own release window is not a story about a tester being slow, it is a strategy defect: the pack has grown by accretion, it repeats manually what automation already covers, or the window was set without reference to how long testing takes. That belongs in the retrospective with an owner, and it belongs there even if this release went out perfectly clean, because next time the dice may land differently.

The strongest version of this answer never argues about whether to ship. It makes the untested surface impossible to misread, attaches a mitigation to each part of it, and hands a genuine decision to the person whose decision it is.