Te piden testear una funcionalidad que no tiene requisitos escritos. ¿Cómo procedes?

Construye la especificación mientras testeas en vez de esperar a que llegue. Recoge la intención de quien la pidió, mira funcionalidades parecidas ya existentes para captar las convenciones, explora la funcionalidad para mapear su comportamiento real, y escribe lo que encuentres como afirmaciones comprobables. Después haz que las confirme la persona responsable de producto, para que las ambigüedades salgan como preguntas antes de la release y no como bugs discutidos después.

Ni espero a que haya un documento ni me lo invento, porque adivinar significa que cada hallazgo se convierte en una discusión sobre si es un bug o no. Empiezo buscando la intención donde exista: el ticket, el diseño, un hilo de chat, la descripción del pull request, y una conversación de diez minutos con quien pidió la funcionalidad, donde arranco preguntando qué problema le resuelve esto al usuario. Después miro funcionalidades comparables del mismo producto, porque la coherencia es en sí misma un requisito y una pantalla nueva que valida distinto de todas las demás es un defecto diga lo que diga cualquier documento. Luego exploro la funcionalidad y escribo lo que hace en realidad como afirmaciones comprobables. Eso se convierte en una especificación corta, normalmente de una página, y la devuelvo con las ambigüedades marcadas: cuando la cantidad supera el stock, ¿bloquea o avisa? Nueve de cada diez veces la persona de producto responde en menos de una hora, y ya tenemos una definición compartida de lo correcto antes de la release en vez de una disputa después. Además le deja algo con lo que trabajar a la siguiente persona de test.