Registre os três horários; não se prenda à ordem dos e-mails

Em 2026, é comum que os fluxos de cadastro coloquem o envio de códigos em uma fila: a página informa que a solicitação foi aceita, o sistema gera o código e o serviço de e-mail tenta entregá-lo. A mensagem “enviado” pode indicar apenas que a tarefa foi criada — não que o e-mail já chegou ao servidor de recebimento. Uma segunda solicitação pode passar por uma fila mais rápida: o código novo chega primeiro e o antigo, depois.

Durante os testes, registre pelo menos três horários: quando você clicou em enviar, quando o e-mail apareceu pela primeira vez na caixa de entrada e quando enviou o código para validação. Se tiver acesso aos registros do servidor, anote também o horário de geração do código e o identificador da tarefa de e-mail. Não use a data no corpo da mensagem nem o cabeçalho Date como horário de recebimento: em geral, eles são definidos pelo remetente.

Exemplo: solicitação A às 10:00:00; solicitação B às 10:01:00. B aparece às 10:01:04 e A, às 10:01:12. Nesse caso, A pode aparecer no topo da lista mesmo sendo o código antigo, já invalidado.

A verificação periódica do navegador informa apenas quando a página detectou o e-mail pela primeira vez. A precisão depende do intervalo entre verificações, da rede e de a página estar em primeiro plano. É útil para identificar atrasos de minutos, não para monitorar a entrega em milissegundos. Para calcular indicadores de nível de serviço com precisão, use os registros de envio e recebimento, não estimativas feitas a partir de capturas de tela.

Envie uma vez para estabelecer uma linha de base reproduzível

Primeiro, abra o e-mail de teste para recebimento, copie o endereço atual e confirme que ele continuará válido durante todo o teste. Use esse endereço apenas em ambientes de teste que você tem autorização para acessar. Não vincule um e-mail temporário a ativos, contas de produção ou identidades que precisem ser recuperadas a longo prazo. O vencimento do endereço e o do código são independentes: estender a validade do primeiro não prolonga a do segundo.

  1. Prepare uma conta de teste ainda não utilizada e anote o ambiente, a versão da página e o fuso horário local.
  2. Clique em enviar uma única vez. Registre se a solicitação foi aceita e não clique repetidamente para tentar acelerar a chegada do e-mail.
  3. Deixe a página de recebimento aberta. Aguarde o e-mail e confira o endereço de destino, o assunto e a finalidade informada no corpo da mensagem.
  4. Envie o código dentro do prazo de validade e registre o resultado. Depois, tente usar o mesmo código mais uma vez para verificar se ele já foi consumido.

A segunda tentativa com o mesmo código deve falhar? Isso depende das especificações do produto. Códigos de uso único para login geralmente deixam de valer após o primeiro uso bem-sucedido, mas essa expectativa não se aplica necessariamente a todos os produtos. Confirme com a equipe responsável pela autenticação: o prazo começa na geração ou no envio? O código é invalidado assim que validado? Cada endereço pode ter apenas um código ativo?

Se não estiver recebendo os e-mails nesta etapa, volte às verificações de acionamento e entrega da bancada de testes de cadastro. Não comece logo um teste de reenvio. Sem uma linha de base bem-sucedida, é fácil confundir “o código antigo foi invalidado” com “o e-mail nunca foi enviado”.

Teste o reenvio em duas rodadas para evitar conclusões inconclusivas

Depois que o período de espera terminar, solicite B e identifique A e B como primeira e segunda rodada. Se os dois e-mails tiverem o mesmo código, não conclua que houve duplicidade apenas pelo valor: alguns sistemas reenviam o mesmo código enquanto ele está válido; outros geram um novo a cada solicitação. Compare os identificadores das tarefas, os registros de envio e o comportamento previsto pelo produto.

Se as especificações disserem claramente que reenviar invalida o código anterior na hora, faça dois testes independentes. Na primeira rodada, solicite A e depois B; tente A primeiro e registre a rejeição. Na segunda, inicie uma sessão limpa, solicite A e B novamente e envie apenas B para confirmar que o código novo conclui a validação. Não use B primeiro e conclua, pela rejeição de A, que o mecanismo de reenvio funciona: A também pode ter sido rejeitado porque o desafio já foi encerrado.

  • Se o código antigo ainda for aceito depois da geração do novo, verifique o armazenamento e a lógica de invalidação do desafio; não investigue apenas a fila de e-mails.
  • Se o código novo também falhar, confira o ID do desafio, a sessão, o endereço de teste e o relógio; depois, verifique o prazo de validade.
  • Se o e-mail chegar depois que o código expirar, analise o intervalo entre a geração e a entrega junto às equipes de e-mail e autenticação.
  • Se o reenvio for limitado, respeite o período de espera e teste no ritmo permitido. Não burle o limite.

Teste o vencimento com amostras independentes. Envie os códigos dentro do prazo, perto do limite e depois de expirarem. Evite várias tentativas com o mesmo código, pois isso pode bloquear o acesso. A contagem regressiva no cliente é apenas informativa: a decisão final é do servidor. O relógio do dispositivo do usuário não deve determinar se o código será aceito.

Separe conflitos entre abas de casos de e-mails duplicados

Se uma aba enviar A e outra enviar B, cada página pode estar usando um desafio ou uma sessão diferente. O fato de B falhar na primeira aba não significa, por si só, que os e-mails chegaram fora de ordem. Reproduza primeiro o problema com uma única aba e, depois, teste com duas, registrando as ações e os resultados esperados em cada página.

Ao receber “dois e-mails iguais”, diferencie pelo menos três situações: a página enviou a solicitação duas vezes, uma nova tentativa do sistema causou uma entrega duplicada ou a interface da caixa de entrada exibiu o mesmo e-mail mais de uma vez. Se tiver acesso aos cabeçalhos originais, compare os Message-ID e relacione-os aos registros das tarefas de e-mail. Eles servem como indício, não como prova única: o encaminhamento ou o processamento pelo provedor também podem alterar campos relacionados.

Receber apenas um e-mail também não prova que o sistema impede duplicidades. A segunda tarefa pode ainda não ter sido executada, ou o provedor pode ter agrupado as mensagens. Para validar a proteção contra duplicidades, examine os identificadores das solicitações e os registros das tarefas no sistema testado. A caixa de entrada temporária comprova o que foi observado no destino, mas não substitui a auditoria do comportamento do sistema.

Registre as observações para que outras pessoas possam reproduzir o teste

Um relatório útil inclui a versão do ambiente, um identificador de conta anonimizado, o prazo de validade do endereço, os horários das solicitações e do recebimento, o horário de envio do código e o resultado exibido na página. Use A e B no lugar dos códigos completos. Ao relacionar os registros, informe o ID da tarefa e não inclua em chamados públicos códigos ainda válidos. Se a captura de tela mostrar um link de verificação, oculte também o token antes de compartilhá-la.

Seja específico ao apresentar as conclusões. “Após a segunda solicitação, o primeiro código ainda foi aceito na mesma sessão” é mais útil para orientar uma correção do que “os códigos não são seguros”. Da mesma forma, “a página de recebimento detectou o e-mail após 12 segundos” é mais preciso do que “o serviço de e-mail atrasou 12 segundos”, pois você não mediu todas as etapas intermediárias.

Depois de validar a ordem dos horários, examine também o conteúdo do e-mail. O assunto deixa clara a finalidade? O corpo informa o prazo de validade? É possível distinguir números parecidos no celular? Continue com Validação do conteúdo e do texto simples de e-mails de notificação para verificar separadamente se o e-mail chegou e se o usuário consegue usar o código corretamente. Se tiver dúvidas sobre algum termo, consulte o glossário de recebimento de e-mails.

No próximo teste, altere apenas uma variável

Use um endereço temporário novo, envie primeiro um e-mail de referência e só então teste o reenvio. O HideRelay apenas recebe e-mails; não gera nem valida os códigos do produto testado.