Identifique a origem do envio
Registre se é produção, homologação ou ambiente local, além da versão do template e do idioma usados.
Central de QA de e-mails
Execute um ciclo completo de teste de recebimento no navegador
Transforme “o e-mail chegou” em verificações objetivas: disparo, fila, recebimento, resumo na lista, renderização do conteúdo, links e anexos. Endereços temporários ajudam a isolar os dados de cada teste.
Defina as credenciais do teste
Em cada execução, guarde o mínimo necessário para reproduzir o resultado e evite registrar apenas “às vezes não chega”.
Use um endereço novo em cada rodada
Copie o endereço de e-mail temporário atual para evitar que mensagens antigas e tarefas repetidas afetem não lidos, ordenação e contagens.
Registre o disparo e o recebimento
Anote também o horário do envio e o momento em que a mensagem apareceu na lista para obter dados de latência comparáveis.
Inclua um identificador de teste não sensível
Inclua o número do build ou do caso no assunto, sem inserir dados reais de usuários nem chaves de produção.
Ordem de execução
Oito pontos de verificação para não confundir “parece normal” com sucesso
Valide a lista e os detalhes separadamente; depois que o e-mail real chegar, a mensagem de demonstração deve sair da lista.
Dispare o e-mail uma única vez
Confirme o retorno de sucesso da API ou da página do produto e salve o identificador associado à solicitação. Não clique em enviar várias vezes seguidas.
Observe quando a mensagem aparece na lista
Aguarde a atualização automática; se necessário, atualize manualmente uma vez e confirme que houve feedback visível. Registre quantos segundos se passaram entre o disparo e a exibição.
Confira o remetente e o endereço de resposta
O nome exibido, o domínio do endereço e o Reply-To devem corresponder às configurações do ambiente, sem expor endereços de desenvolvimento ou marcas incorretas.
Confira o assunto e a prévia
As variáveis não devem aparecer sem substituição, assuntos longos devem ser truncados sem estourar o layout da lista e o horário deve seguir o formato local.
Abra a linha inteira para ver os detalhes
O conteúdo HTML deve aparecer em um quadro isolado, com o texto simples como alternativa; no celular, a área de leitura deve ocupar toda a tela.
Verifique o código e os botões principais
O código deve ser legível, mas não deve ser gravado em logs; os textos dos botões precisam ser claros, e o domínio de destino deve corresponder ao ambiente.
Verifique anexos e caminhos alternativos
Valide nome, tipo, tamanho e download autenticado dos arquivos; sem HTML, o texto simples ainda deve estar disponível.
Salve o resultado e repita com outro endereço
Registre aprovações, falhas e capturas de tela; use um endereço novo para confirmar que o teste é reproduzível e não deixar o cache ocultar problemas.
Matriz de testes mínima recomendada
| Caso | Variação de entrada | Principais verificações |
|---|---|---|
| Código de seis dígitos | Templates em chinês e inglês | Valor do código, validade, cor da marca e remetente |
| Link de confirmação | Nome de usuário e URL longos | Quebra de linha, destino do botão e alternativa em texto simples |
| E-mail de notificação | Sem assunto ou sem prévia | Placeholders localizados e layout da lista |
| E-mail de marketing em HTML | Imagens desativadas e tela estreita | Renderização isolada, largura limitada das imagens e informações de cancelamento |
| E-mail com anexo | Nome de arquivo em chinês e vários arquivos | Codificação do nome, autenticação do download e feedback de falha |
| Envio duplicado | Dois disparos para o mesmo endereço | Ordenação, status de não lido e estratégia de deduplicação |
Como registrar um bug acionável
Deixe claros no título o ambiente, o template e o problema, por exemplo: “E-mail de código em chinês na homologação estoura horizontalmente na área de leitura móvel”. No corpo, inclua horário do disparo, horário do recebimento, domínio do endereço, navegador e resultados esperado e observado.
Não publique códigos reais, o endereço completo de recebimento nem o conteúdo de e-mails de usuários em sistemas públicos de bugs. Ao compartilhar uma amostra, use dados de teste gerados especificamente para isso e oculte os tokens.
Quando mudar para um teste de encaminhamento contínuo
A validação de um build é adequada para um e-mail temporário; regressões entre dias, status de entrega e novas tentativas de anexos funcionam melhor com uma identidade de encaminhamento separada. Ela pode manter a entrada por mais tempo sem misturar o QA com o endereço pessoal público dos participantes.
Independentemente da identidade usada, não trate um serviço de e-mail temporário como alvo de teste de carga. Solicitações automáticas em alta frequência acionam limites de taxa e tornam as medições irrelevantes para usuários reais.