Te pedem para testar uma funcionalidade que não tem requisitos escritos. Como você procede?

Construa a especificação enquanto testa em vez de esperar por uma. Colete a intenção com quem pediu, olhe funcionalidades parecidas que já existem para entender as convenções, explore a funcionalidade para mapear o comportamento real, e escreva o que você achou como afirmações testáveis. Depois consiga a confirmação do product owner, para que ambiguidades apareçam como perguntas antes do release em vez de bugs contestados depois.

Eu não espero por um documento e também não fico chutando, porque chutar significa que toda descoberta vira uma discussão sobre se é ou não um bug. Eu começo achando a intenção onde ela existir: o ticket, o mock de design, uma thread de chat, a descrição do pull request e uma conversa de dez minutos com quem pediu a funcionalidade, na qual eu abro com que problema isso resolve para o usuário. Depois eu olho funcionalidades comparáveis no mesmo produto, porque consistência é em si um requisito e uma tela nova que valida diferente de todas as outras é um defeito, esteja escrito em algum documento ou não. Depois eu exploro a funcionalidade e anoto o que ela de fato faz como afirmações testáveis. Isso vira uma especificação curta, normalmente de mais ou menos uma página, e eu devolvo com as ambiguidades marcadas: quando a quantidade passa do estoque, bloqueia ou avisa? Nove em cada dez vezes o product owner responde dentro de uma hora, e agora temos uma definição compartilhada de correto antes do release em vez de uma disputa depois. Também deixa algo para o próximo testador trabalhar em cima.