You are asked to test a feature that has no written requirements. How do you proceed?

Build the specification as you test rather than waiting for one. Gather intent from whoever requested it, look at similar existing features for conventions, explore the feature to map its actual behavior, and write what you find as testable statements. Then get those confirmed by the product owner, so ambiguities surface as questions before release rather than as disputed bugs afterward.

I do not wait for a document and I also do not just guess, because guessing means every finding turns into an argument about whether it is a bug. I start by finding intent wherever it exists: the ticket, the design mock, a chat thread, the pull request description, and a ten minute conversation with whoever asked for the feature, where I lead with what problem this solves for the user. Then I look at comparable features in the same product, because consistency is itself a requirement and a new screen that validates differently from every other screen is a defect regardless of what any document says. Then I explore the feature and write down what it actually does as testable statements. That becomes a short specification, usually about a page, and I send it back with the ambiguities marked: when the quantity exceeds stock, does it block or warn? Nine times out of ten the product owner answers within the hour, and now we have a shared definition of correct before release rather than a dispute after it. It also leaves the next tester something to work from.