A recurring Agile situation — and a very common interview question — where a story is code-complete but not fully tested as the sprint deadline arrives. How a QA engineer handles it reveals their grasp of Definition of Done, risk communication, and team collaboration over heroics.
The wrong instinct is to either rubber-stamp the story as done to hit the sprint goal, or to silently keep testing past the sprint while it's reported as complete. Both hide risk. The Agile-correct response rests on a few principles: a story that isn't fully tested does not meet the Definition of Done, so it should not be marked done; the situation is a team problem surfaced transparently, not a QA failure to absorb quietly; and the decision about what to do (carry over, de-scope, accept risk) belongs to the team and Product Owner with QA providing a clear risk picture. Practically, QA should have raised the risk mid-sprint at standup rather than at the deadline, prioritize remaining testing by risk so the most critical paths are covered first, and give the PO an honest status: what's tested, what isn't, and the risk of releasing as-is. The underlying interview signal is whether you protect quality and communicate risk without becoming a bottleneck or a blocker.
Two days before sprint end, a payments story is code-complete but only the happy path is tested. The QA engineer raises it at standup, tests the highest-risk paths (declined cards, double-charge protection) first, and gives the PO a written risk summary. The team decides to carry the remaining edge-case testing into the next sprint rather than ship partially-verified payment code.
STORY STATUS — Sprint 34, Payments checkout
Tested & passing:
- Successful card payment (happy path)
- Basic validation (empty fields)
NOT yet tested (risk if released):
- Declined / expired card handling [HIGH]
- Double-submit / double-charge guard [HIGH]
- Currency rounding on multi-item cart [MED]
- Timeout / retry on gateway error [MED]
Recommendation: carry HIGH items into Sprint 35;
do NOT mark story Done. Release risk if shipped as-is:
potential incorrect charges on non-happy paths.Scenario: It's the last day of the sprint. A developer asks you to 'just mark the story done' because the code is merged and the demo is tomorrow, even though you've only tested the happy path of a payments feature. The Product Owner is pushing to hit the sprint commitment. What do you do?
Interviewers want collaboration + risk communication, not 'I refuse to sign off' or 'I'd just work overtime' — show you make risk visible and let the team decide.