A frequent real-world and interview scenario where the story or requirement is unclear, missing cases, or open to interpretation. The tester's response reveals whether they seek clarity proactively rather than guessing, assuming, or blocking.
Ambiguous requirements are the norm, not the exception, and how QA handles them separates strong testers from weak ones. The wrong responses are: guessing what was meant and testing against an assumption (which produces false confidence and rework), or downing tools and waiting passively. The right approach is proactive clarification: identify the specific gaps and questions (what happens for an expired input, a boundary value, a concurrent action, an error path), and take them to the source of truth — the Product Owner, business analyst, or designer — ideally during refinement before coding, but at any point once discovered. Framing questions with concrete examples ('if the user does X with an expired code, should they see A or B?') gets faster, clearer answers than abstract complaints. Where a quick answer isn't available, QA can propose a reasonable default, state the assumption explicitly, and get it confirmed — never leaving assumptions silent. Documenting the clarified behavior as acceptance criteria closes the loop so the ambiguity doesn't recur. The interview signal is initiative plus collaboration: you drive out ambiguity early instead of letting it become a defect.
A story says 'users can upload a profile photo' but never states size or format limits. Instead of guessing, QA asks the PO: 'What's the max file size, which formats, and what should happen for an oversized or wrong-type file?' The answers become new acceptance criteria, and the error-handling that would otherwise have been missed is built and tested.
CLARIFICATION LOG — Story: "Upload profile photo"
Gaps found by QA:
Q1 Max file size? (story silent)
Q2 Allowed formats? (jpg/png/gif/webp?)
Q3 Behavior on oversized file? error text?
Q4 Behavior on wrong format?
Q5 What replaces an existing photo — overwrite or version?
Proposed defaults (pending PO confirmation):
- Max 5 MB; JPG/PNG only; clear inline error otherwise;
new upload overwrites the previous photo.
Outcome: PO confirmed defaults + added "strip EXIF for privacy."
-> Added as acceptance criteria AC5-AC9.Scenario: You pick up a story to test, but the acceptance criteria only describe the happy path and say nothing about error cases, limits, or edge conditions. The developer has already built it 'the way they thought made sense'. The sprint is mid-way. What do you do?