How would you approach testing a feature with vague or incomplete requirements?

Vague requirements are the rule, not the exception. The test engineer who responds with "I can't test until the spec is finalised" is unhelpful; the one who responds with "let me help finalise it" is invaluable.

Step 1: Map the ambiguity. Read the spec actively, looking for words like "should", "fast", "user-friendly", "etc.", "and so on". Each is a tell. Build a list of open questions: what does "fast" mean — sub-200ms? What does "etc." mean — what's the exhaustive list?

Step 2: Surface the questions early. A three-amigos session (PM + dev + QA) before development starts is the ideal forum. Walk through every ambiguity, force a decision or a deferred-with-reason. Document the answers so they don't re-emerge later.

Step 3: Write down assumptions. When you can't get a decision and have to start anyway, write the assumption explicitly: "I'm assuming negative numbers are rejected with error code 400. If that's wrong, the test cases will need to change." Stakeholders can react to written assumptions; they can't react to ones in your head.

Step 4: Use exploratory testing while the spec moves. Scripted test design against a moving target wastes effort. Exploratory sessions cover ground without the rewriting cost — and they often surface ambiguities the spec didn't address.

Step 5: Push back on impossible expectations. If the team wants test coverage signed off but the spec is genuinely undefined, that's a process problem, not a tester problem. The right escalation is "we cannot meaningfully test this until [these decisions] are made."

The signal of seniority: you treat vague requirements as a leadership opportunity to clarify the product, not as a tester problem to suffer through.