Do “não recebi”
à etapa exata do problema
Problemas com códigos de verificação costumam aparecer apenas como “não recebi”, mas por trás há várias etapas: solicitação, geração, fila, entrega, recebimento e uso. Um diagnóstico eficaz não é reenviar sem parar, e sim registrar uma linha do tempo associável para cada etapa.
Conclusão: um timeout isolado não significa que o sistema de e-mail esteja indisponível, e clicar várias vezes em “enviar” não prova que o problema desapareceu. Em 2026, a abordagem mais confiável é tratar cada solicitação de código como uma transação curta, descrita por um identificador de correlação, horários de cada etapa e um resultado claro.
1. Crie primeiro um modelo de entrega em cinco etapas
A primeira etapa é a solicitação iniciada pelo usuário. Confirme se a página realmente enviou a solicitação, se a API retornou um status aceitável e se o front-end não exibiu uma falha como sucesso. A segunda é a geração do código pelo sistema e a criação da tarefa de e-mail; se a renderização do template falhar, a mensagem nem chega à fila de envio.
A terceira etapa é o serviço de e-mail aceitar a tarefa e tentar entregá-la; a quarta é o sistema de recebimento do destinatário receber e exibir a mensagem; a última é o usuário abrir o e-mail e enviar o código. Depois de separar o fluxo, “o e-mail não chegou” pode virar “a tarefa entrou na fila às 14:03:21, foi recebida às 14:03:58 e a lista do front-end só foi atualizada às 14:04:20”. Esse é o tipo de problema que pode ser corrigido.
O sucesso retornado pela API de envio só significa que a tarefa foi aceita; não significa que o e-mail já apareceu na caixa de entrada. O registro de teste deve manter separadamente o horário de “solicitação aceita” e o de “e-mail visível”.
2. Registre quatro horários usando o mesmo relógio
Use um endereço novo em cada rodada e registre quatro horários: acionamento, resposta da API, e-mail visível e envio do código. Em equipes que trabalham entre fusos, registre tudo em UTC e mantenha a indicação do fuso local nas capturas de tela. A precisão em segundos normalmente basta; não é necessário buscar capturas em milissegundos.
Se você usar o RelayTmp em um teste curto, primeiro copie o endereço atual nacaixa de entrada descartável e só então inicie este cadastro. Não troque de endereço no meio do teste: depois da troca, os e-mails de tarefas antigas não serão migrados para a nova caixa de entrada. Crie a próxima identidade somente após concluir o caso de teste, para facilitar a associação dos resultados.
| Etapa | O que registrar | Pergunta respondida |
|---|---|---|
| Acionamento | Ação, horário e ID do caso | O usuário realmente iniciou a solicitação? |
| Resposta | Status, identificador de correlação e duração | O sistema de negócio aceitou a tarefa? |
| Visível | Assunto, remetente e horário de chegada | Quando o e-mail entrou na visualização da caixa de entrada? |
| Uso | Horário do envio e sucesso ou falha | O código ainda é válido? |
3. Defina uma janela de espera explicável para reenvios
A janela de espera deve vir da meta do produto, não da paciência de quem testa. Se a equipe definir que 95% dos códigos devem ficar visíveis em até 60 segundos, registre o status de não recebimento aos 60 segundos e faça a decisão final aos 120. Durante a janela, é permitido atualizar manualmente a caixa de entrada, mas não solicitar outro envio.
Só inicie um caso de reenvio após o fim da janela anterior. No reenvio, deixe clara a regra do sistema: o código antigo expira imediatamente, os dois permanecem válidos por pouco tempo ou apenas o último é aceito. Depois, envie o código antigo e o novo separadamente, na ordem de chegada, e confirme se o texto de erro da interface corresponde à regra do back-end. Se vários e-mails chegarem fora de ordem, testar apenas “o mais recente” pode esconder o risco real.
- Fluxo normal: primeira solicitação, chegada dentro da janela esperada e uso bem-sucedido.
- Fluxo com atraso: o primeiro e-mail chega depois da janela esperada; o código ainda tem validade suficiente?
- Fluxo de reenvio: envie o primeiro código antes e depois da chegada do segundo para validar a regra de expiração.
- Fluxo de cliques repetidos: o front-end deve indicar um período de espera e não criar várias tarefas sem avisar.
4. Organize as evidências em um pacote fácil de encaminhar
Um bom relatório de bug não precisa de uma gravação de tela inteira. O pacote mínimo de evidências deve incluir ambiente, ID do caso, endereço de recebimento anonimizado, os quatro horários, assunto visível, resultado esperado e resultado real. Se houver um identificador de correlação do sistema, coloque-o junto do ID do teste para que a equipe técnica possa consultá-lo nos logs.
Não copie dados de contas reais associados ao código nem cole o corpo completo do e-mail em um chamado público. Oculte informações de identidade irrelevantes nas capturas. Um e-mail descartável é adequado para isolar testes de baixo risco, mas não é um atalho de conformidade para processar e-mails de usuários em produção.
Checklist antes de abrir um bug
- Indicar se foi o primeiro envio ou um reenvio;
- Usar o mesmo fuso horário em todos os horários;
- Incluir um limite claro no resultado esperado, em vez de “deveria ser rápido”;
- Associar cada endereço a um único caso, sem reutilizar uma caixa de entrada antiga;
- Anonimizar as evidências e não incluir códigos reais de usuários.
5. Quais métricas acompanhar em 2026
Observar apenas a duração média esconde a cauda longa. A equipe deve acompanhar pelo menos três latências: da criação da tarefa à aceitação pelo provedor, da aceitação pelo provedor ao recebimento pelo sistema de destino e do recebimento à visibilidade para o usuário. Analise cada uma em p50, p95 e p99. Agrupe também a taxa de falhas por template, idioma, domínio de destino e canal de envio; caso contrário, uma falha regional ou de um template será diluída pelo volume total.
Registre também a taxa de reenvio e a proporção de códigos que “já expiraram quando o primeiro chegou”. O aumento dos reenvios nem sempre indica entrega mais lenta: pode significar que a página não mostra uma contagem regressiva clara. Muitos primeiros códigos expirados indicam conflito entre validade, latência de entrega e estratégia de reenvio. As métricas servem para restringir a investigação, não para substituir casos reais.
6. Saiba o que uma caixa de entrada descartável pode comprovar
Uma caixa de entrada descartável pode comprovar se um endereço de teste recebe a mensagem, quando ela fica visível e se o corpo e os links podem ser lidos. Ela não comprova que todos os provedores de e-mail terão o mesmo comportamento nem contorna restrições do remetente a domínios temporários. Quando o remetente recusar ativamente o envio, registre isso como resultado de uma política, em vez de trocar de endereço repetidamente para tentar contornar a regra.
Contas de pagamento, saúde, trabalho e qualquer identidade que precise ser recuperada por longo prazo não devem usar endereços temporários. Se você precisar testar por várias semanas a mesma identidade pública, acesse opainel de encaminhamento de e-mails e crie um alias gerenciável. Deixe a caixa de entrada descartável para testes de baixo risco que terminem em poucas horas.
Crie um endereço exclusivo e registre a primeira linha do tempo
Abra a caixa de entrada descartável, copie o endereço e atualize a página para ler e-mails reais de teste no mesmo lugar.