1) Preparação do ambiente de teste

• Ambientes separados: valide em staging e, quando possível, em um ambiente espelho de produção.
• Configurações de e-mail: confirme domínio/SMTP/serviço transacional e políticas de envio (rate limit e templates).
• Relógio e timezones: verifique consistência de tempo (expiração do OTP) entre backend e frontend.
• Logs e rastreabilidade: garanta correlação por request_id/trace_id para diagnosticar “não chegou”.
• Dispositivos e navegadores: inclua iOS/Android, Safari/Chrome e variações com bloqueadores.

Dica de QA: trate fluxo de cadastro como um produto dentro do produto. Se você não consegue reproduzir um problema com facilidade, a chance de ele virar “intermitente” em produção é alta.

2) Entrada do e-mail e validações básicas

Validação de formato e UX

• Validação de formato do e-mail (incluindo subdomínios e TLDs diferentes).
• Normalização: espaços, letras maiúsculas/minúsculas, caracteres invisíveis (copiar/colar).
• Mensagens de erro claras e específicas (sem “algo deu errado” genérico).
• Botão de continuar desabilitado até o input ser válido (com feedback acessível).
• Suporte a teclado mobile: tipo correto, ação “next/done”, foco e rolagem consistentes.

Regras de bloqueio e e-mails descartáveis

• Se houver bloqueio por domínio temporário, valide a mensagem (explica o motivo e sugere alternativa).
• Se não houver bloqueio, valide que o fluxo funciona com domínios descartáveis comuns e com domínios menos conhecidos.
• Testes com endereço de e-mail “plus alias” (ex.: usuario+teste@dominio.com), se permitido pela regra do produto.
• Comportamento para e-mails já cadastrados: login, recuperação, ou mensagem orientando o próximo passo.

3) Envio do OTP: entrega, latência e consistência

Entrega (happy path)

• OTP chega na caixa descartável em tempo razoável; valide com diferentes provedores/rotas.
• O e-mail contém assunto coerente, remetente reconhecível e conteúdo compatível com o contexto (cadastro, login, troca de e-mail).
• O OTP exibido no e-mail coincide com o registrado no backend para aquela sessão.
• Se houver link mágico, ele abre corretamente e autentica a sessão esperada.

Latência e atrasos

• Simule atraso: OTP chegando perto do limite; valide o comportamento do contador e a mensagem ao usuário.
• OTP chegando após expirar: deve ser recusado com erro específico e opção de reenviar.
• Resiliência do frontend: a tela de OTP não deve “travar” se o e-mail demorar.

Conteúdo do e-mail (qualidade e segurança)

• O e-mail não deve expor dados sensíveis desnecessários (ex.: senha, informações internas).
• Se houver deep link, valide fallback para web e comportamento quando o app não está instalado.
• Links devem ser curtos e claros, com tracking mínimo e compatível com privacidade.

4) Tela de OTP: UX, erros e casos extremos

Inserção do código

• Input com máscara apropriada (somente dígitos, tamanho fixo, avanço automático entre campos, se houver).
• Colar o OTP inteiro funciona (paste) e preenche os campos corretamente.
• Teclado numérico no mobile, com foco consistente após retorno de background.
• Indicador de carregamento durante verificação do código (sem “double submit”).

Erros e mensagens

• Código incorreto: mensagem clara, sem revelar detalhes que ajudem abuso (ex.: não dizer “faltam 2 tentativas” se isso for sensível).
• Código expirado: mensagem orientando a ação (reenviar) e explicando o que aconteceu.
• Código já usado: deve falhar com feedback correto e sem autenticar novamente.
• Problema de rede: estado offline/online, retry e preservação do que o usuário digitou.

Contador e expiração

• Contador regressivo (se houver) sincroniza com backend e não “volta” ao alternar telas.
• Ao expirar, UI muda de estado: desabilita verificar, destaca reenvio, limpa mensagens antigas.
• Se o usuário sair e voltar, a tela recupera o estado corretamente (expirado vs válido).

5) Reenvio (Resend): rate limit e ordenação

Regras de reenvio

• Reenvio bloqueado até um tempo mínimo; botão e texto explicam quando será liberado.
• Rate limit no backend: respostas coerentes (HTTP/erros) e mensagens amigáveis.
• Em caso de bloqueio temporário, o usuário entende que deve aguardar e o fluxo não fica “morto”.

Ordenação e múltiplos códigos

• Ao reenviar, o OTP anterior deve invalidar (ou manter, dependendo da regra), mas isso precisa ser consistente.
• Se o usuário tenta um OTP antigo, deve falhar com mensagem adequada.
• Se chegam vários e-mails, o mais recente deve ser o esperado; valide que o template deixa isso claro.

Comportamento com e-mail descartável

• Se a caixa expira rápido, reenvios tardios podem cair fora do tempo. Valide o fluxo orientando o usuário.
• Se houver opção de trocar e-mail no meio do fluxo, confirme invalidar a sessão anterior e reiniciar corretamente.

6) Links no e-mail: web, app e deep links

Se o fluxo usa link de verificação (além do OTP), trate como um “produto paralelo”, porque é um ponto de quebra comum. Valide os cenários abaixo em iOS/Android e desktop.

• Link abre no destino correto (app ou web) e autentica/valida o estado correto.
• Link aberto em navegador diferente daquele do signup: comportamento esperado (continuar, pedir login, ou recusar por segurança).
• Link clicado duas vezes: primeira funciona, segunda deve ser recusada com mensagem clara.
• Link após expiração: recusa correta e CTA para reenviar.
• Se houver redirect, valide que não há loop e que o parâmetro de retorno não quebra.
• Em mobile, validar “abrir em app” vs “continuar no navegador”, conforme a política do produto.

7) Segurança: abuso, enumeração e proteção do funil

Enumeração de e-mail

• Respostas do sistema não devem permitir descobrir facilmente se um e-mail existe (“conta encontrada” vs “conta não existe”).
• Mensagens e tempos de resposta devem ser similares entre e-mails existentes e inexistentes.
• Logs e métricas de tentativa devem existir, mas sem vazar detalhes ao usuário final.

Proteção contra abuso

• Rate limit por IP, por dispositivo e por e-mail (conforme estratégia), com respostas controladas.
• Detecção de comportamento automatizado: tentativas em alta frequência, múltiplos e-mails descartáveis em sequência.
• Bloqueio progressivo: backoff, captcha (se aplicável), ou cooldown com UX clara.

Integridade da sessão

• OTP vinculado a uma sessão/fluxo específico (signup vs login) e não reutilizável em outro contexto.
• Proteção contra replay: código usado uma vez não autentica novamente.
• Em caso de troca de e-mail durante o fluxo, invalidar tokens anteriores com clareza.

8) Acessibilidade e internacionalização

• Campos e botões com labels acessíveis; foco visível e navegação por teclado.
• Erros anunciados para leitores de tela e não apenas por cor.
• Contraste suficiente e textos compreensíveis para estados (enviando, validando, expirado, reenviar).
• Formato do e-mail e idioma do template coerente com o idioma escolhido no app/site.
• Em PT-BR, cuidado com termos: “código”, “verificação”, “reenviar”, “expirou”, evitando traduções literais ruins.

9) Observabilidade: o que medir para evitar regressões

Mesmo com testes manuais fortes, os fluxos de OTP mudam com frequência (templates, gateways, políticas anti-abuso). Se você não mede, você descobre tarde. Para QA, o ideal é alinhar com engenharia e produto um conjunto mínimo de sinais.

• Taxa de entrega: proporção de OTP enviados vs confirmados.
• Tempo até chegada: latência média e percentis (p95/p99).
• Taxa de reenvio: alto reenvio costuma indicar entrega lenta ou UX confusa.
• Falhas por expiração: se sobe, pode ser latência ou TTL curto demais.
• Erros por domínio bloqueado: útil quando e-mails descartáveis são parte do público.
• Abandono no funil: onde o usuário desiste (tela de OTP, erro de rede, expiração).

10) Casos de teste recomendados (lista de execução)

Fluxo básico

• Cadastrar com e-mail descartável válido e receber OTP; confirmar e concluir cadastro.
• Repetir com variação de navegador e dispositivo.
• Repetir com latência simulada e rede instável.

Expiração e reenvio

• Deixar o OTP expirar e validar mensagem + reenvio.
• Reenviar e validar que o novo OTP é aceito e o antigo é rejeitado (conforme regra).
• Testar limite de reenvios e comportamento após cooldown.

Erros comuns

• Inserir OTP incorreto até o limite; validar resposta, cooldown e persistência do estado.
• Trocar de app para outro e voltar; validar que a tela não perde estado nem trava.
• Fechar e reabrir o app; validar recuperação de sessão ou reinício do fluxo conforme política.

Links no e-mail

• Link abre no navegador: valida estado correto e evita loops.
• Link abre no app: valida deep link e fallback se app não instalado.
• Link duplicado: primeira vez ok, segunda recusa e orienta.

Segurança e bloqueios

• Testar respostas para e-mail existente vs inexistente (evitar enumeração).
• Testar sequência rápida de cadastros com e-mails descartáveis (rate limit/abuso).
• Testar domínios bloqueados e UX de orientação ao usuário.

Fechamento: por que esse checklist vale o tempo

O fluxo de cadastro é o “primeiro aperto de mão” do seu produto. Se o OTP falha, não importa o quão bom o resto é: o usuário não chega lá. Testar com e-mail descartável amplia a cobertura porque revela o que o mundo real faz: cadastros rápidos, múltiplas tentativas, latência imprevisível e pouca paciência para telas confusas.

Use este checklist como roteiro de execução e também como base para automatizar partes do funil. O objetivo não é só passar no teste hoje, e sim manter a experiência estável quando templates, provedores e políticas mudarem amanhã.