Describe a time you had to test a feature with vague requirements. How did you proceed?

Vagueness is normal in real product work. The interviewer is checking whether you go heads-down and guess, or surface ambiguity early.

STAR walkthrough — sample answer:

Situation: A previous team had to ship a "promo code" feature on a checkout flow. The PM had written a one-paragraph description: "users can enter a code and get a discount." The engineering ticket was three sentences. Sprint started, the engineer started building, and I was asked to "write tests for promo codes."

Task: As the QA owner I needed test coverage for the feature, but I didn't actually know what valid behaviour looked like. Could codes be reused? Stack? Expire? What about invalid codes — did we show an error or just ignore them? Could amounts go negative if the discount exceeded the cart?

Action: Instead of starting from the engineer's branch and reverse-engineering, I wrote a one-page document titled "Promo Code Behaviour — Open Questions." It listed about 20 specific edge cases as questions: stacking, case sensitivity, what happens at exactly 100% discount, partial application, currency conversion if applicable, codes during refunds. I shared it with the PM and engineer at the start of the sprint.

We had a 30-minute conversation, the PM clarified the actual product intent (single-use codes, no stacking, error on invalid), and we found three cases the PM hadn't thought through (negative amounts, expired codes mid-checkout). The engineer confirmed which were in scope for this sprint vs deferred. I converted the answers into a decision log shared with the team and used it as the basis for the test plan.

Result: We shipped the feature without late-stage rework or production surprises. The decision log became the canonical reference for the area when we expanded promo codes the following quarter — saved another round of "wait, what should this do?" conversations.

What I learned: vague requirements aren't a QA problem to solve alone — they're a product problem to surface. The faster you make ambiguity visible, the cheaper it is to resolve.

Why this answer works: shows initiative, structured thinking (a written list of questions), early surfacing rather than late surprise, and follow-on value (the decision log). Avoids the trap of "I figured it out by reading the code."