## Prioritizing QA Work Under Deadline Pressure You are a QA / test engineer embedded in a product team. A release deadline is a few days away, and there is clearly more testing work outstanding than there is time to complete it: a large backlog of test cases, several feature areas that just landed, and a known-flaky regression suite. The development team is still merging fixes. Walk me through how you decide what to test, how you organize and sequence your work, and how you communicate quality and risk to the rest of the team. Ground your answer in a specific situation you have actually faced, what you did, and how it turned out. ```hint Framework Structure the story with STAR (Situation, Task, Action, Result) and make the **Action** the bulk of it. ``` ```hint Core technique The interviewer is really probing for **risk-based prioritization** — you cannot test everything, so make the criteria explicit (user impact, change surface, blast radius) and pair it with proactive communication of residual risk, not silent best-effort. ``` ### Constraints & Assumptions - You cannot meaningfully expand the schedule or the team in the time available. - You do not own the ship/no-ship decision, but you are the primary voice on quality risk. - "Done" is not "every test case executed" — it is "the team has an accurate, evidence-backed picture of risk before deciding to release." ### Clarifying Questions to Ask - Is the deadline truly fixed (external commitment, marketing event) or is there flexibility on scope or date? - What is the change set in this release — which areas are new or modified versus untouched? - What does the user impact / severity profile look like if a given area ships with a defect? - Is there a feature-flag or staged-rollout mechanism that changes the cost of shipping a residual risk? - Who is the decision-maker for ship / delay, and what evidence do they need from QA to decide? ### What a Strong Answer Covers ```premium-lock What a Strong Answer Covers ``` ### Follow-up Questions - It is the night before release and you find a critical, reproducible bug in a core flow. What do you do in the next hour? - How do you decide whether to recommend shipping with a known defect versus pushing the date? - After the release, what concrete changes would you propose so the team is not in this same crunch next cycle? - How do you keep your prioritization honest when an engineer or PM pressures you to "just sign off"?