Release is tomorrow and you have two days of testing to do. How do you handle it?

Switch to risk based testing and make the tradeoff visible rather than silently cutting corners. Rank areas by likelihood of failure times impact, test the highest risk paths first, and use exploratory testing where scripted coverage is too slow. Then report clearly what was covered, what was not, and what the residual risk is, so the release decision sits with whoever owns it.

I stop trying to run everything and start ranking. The goal in a compressed window is to buy the most risk reduction per hour, not to work through the suite in order. So I look at what actually changed and what it touches, then rate areas by likelihood of failure times impact if it fails. Payment and authentication get tested even if the change is nowhere near them, because the downside is unbounded. A cosmetic tweak to a settings page does not. Automated regression runs in the background while I spend my hands on exploratory testing of the changed areas, because charter based exploration covers ground much faster than writing and executing scripted cases when time is short. Then, and this matters most, I report honestly. Here is what I covered, here is what I did not, here is the residual risk in plain language: we have not tested the refund path on mobile, and if it is broken, customers cannot get their money back. I do not block the release and I do not quietly bless it. The accountable person makes the call with real information, and I make sure that decision is written down.