E-mail temporário para testes: como desenvolvedores e equipes de QA verificam fluxos de cadastro

Todo produto que envia e-mails precisa que alguém se cadastre, de novo e de novo, com um endereço novo. Desenvolvedores recorrem ao próprio Gmail com uma tag depois do sinal de mais, testadores de QA mantêm uma planilha de contas descartáveis e gerentes de produto pegam emprestada a caixa de entrada de um colega. Para uma tarefa específica, um endereço de e-mail temporário para testes é mais rápido do que qualquer uma dessas opções: ver exatamente o que um usuário novo recebe da sua configuração de e-mail de produção ou de staging.

Nós operamos os servidores de e-mail do PureTempMail, então os limites abaixo são as nossas configurações reais, não palpites. Este guia mostra onde uma caixa temporária pública se encaixa num plano de testes, um teste manual que você faz em cinco minutos, a lista de verificação que usaríamos nos nossos próprios e-mails de cadastro e os casos em que você deve usar outra ferramenta.

Onde uma caixa temporária se encaixa entre as suas opções de teste

Há cinco formas comuns de dar um endereço a uma conta de teste. A maioria das equipes acaba usando duas ou três delas em fases diferentes da mesma versão.

Uma caixa temporária ganha seu lugar numa lacuna que as outras deixam: uma mensagem real, enviada pelo seu provedor de e-mail real, chegando a um domínio que você não controla e vista no navegador em segundos. É o mais perto que você chega do que um cliente novo vê, sem criar mais uma conta em algum lugar.

Um teste manual com o PureTempMail

Este é o teste que sugerimos para verificar um fluxo de cadastro manualmente. Cada rodada leva uns cinco minutos.

1. 1

   Abra uma caixa de correio nova para cada usuário de teste

   Abra o PureTempMail numa janela separada do navegador. Um endereço novo é criado ao carregar a página. A caixa de correio fica salva por navegador, então clique em Novo para cada usuário de teste, ou use uma janela anônima quando dois testadores dividirem a mesma máquina.

2. 2

   Registre o endereço junto ao caso de teste

   Cole o endereço no caso de teste ou no ticket antes de usá-lo. Se mais tarde um testador perguntar por que o e-mail de redefinição nunca chegou, você precisa saber para qual caixa de correio ele foi.

3. 3

   Faça o cadastro e dispare todos os e-mails que puder

   Preencha o formulário e depois solicite os e-mails que um usuário novo pode gerar na primeira sessão: reenviar a verificação, esqueci minha senha, um login por link mágico, um pedido de troca de e-mail. Cada um é um modelo separado que pode quebrar por conta própria.

4. 4

   Acompanhe a caixa de entrada sem atualizar

   Os e-mails novos chegam à página por uma conexão ao vivo assim que o nosso servidor os aceita, então o momento em que uma mensagem aparece fica perto do horário real de entrega. Anote quanto tempo cada uma levou. Como funciona explica o caminho de entrega.

5. 5

   Abra cada mensagem nas duas visualizações

   Leia em HTML e depois mude para Texto puro. A visualização em texto puro é a que alguns clientes e leitores de tela usam como alternativa, e é onde aparecem primeiro a falta da parte em texto ou um código ilegível. Clique em cada link e confirme para onde ele leva.

6. 6

   Prorrogue se o fluxo for lento

   Sequências automáticas, aprovações demoradas e lembretes do segundo dia precisam de mais tempo. Clique em +1 h para voltar o cronômetro a uma hora cheia. Você pode repetir isso até 24 horas depois da criação da caixa de correio.

7. 7

   Deixe expirar e teste o bounce

   Depois que a caixa expira, o nosso servidor recusa e-mails para esse endereço na etapa SMTP com um erro permanente "No such mailbox". Envie mais um e-mail para ele e confira se o seu app ou o seu provedor de e-mail registra um hard bounce e para de enviar para esse usuário.

A lista de verificação dos e-mails de cadastro

Estas são as verificações que faríamos nos e-mails de cadastro de qualquer produto antes de uma versão. Cada uma é fácil de notar numa caixa de entrada real e fácil de deixar passar numa revisão de código.

• Código ou link de verificação. Ele chega, o código é legível em texto puro, o link funciona uma vez e um segundo clique mostra uma mensagem clara em vez de uma página de erro.
• Links mágicos e códigos de uso único. Um link novo invalida o antigo, um link expirado explica o que fazer em seguida e abrir o link em outro navegador se comporta do jeito que você pretende.
• Redefinição de senha. O e-mail diz a qual conta se refere, o link expira e pedir uma redefinição para um endereço não cadastrado não revela se esse endereço tem conta.
• E-mails de boas-vindas e sequências. O primeiro chega depois da verificação, não antes, e as etapas seguintes não disparam para usuários que nunca confirmaram.
• Partes HTML e texto puro. As duas existem, as duas dizem a mesma coisa e nada importante fica só numa imagem. Imagens remotas carregam na nossa visualização HTML, então você pode conferi-las ali e usar Texto puro para ver a mensagem sem elas.
• Anexos. Faturas e PDFs chegam com nomes de arquivo e tipos de conteúdo coerentes. Mantenha os arquivos de teste abaixo de 1 MB por mensagem, ou envie um link de download, o que de qualquer forma é mais gentil com os usuários reais.
• Destino dos links. Nenhum link de um e-mail de produção aponta para localhost, um nome de host interno ou um domínio de staging, e os redirecionamentos de rastreamento levam à página certa.
• Cabeçalhos de descadastro. E-mails de marketing e de sequências trazem um link de descadastro que funciona e, no caso de remetentes em massa, o cabeçalho de um clique List-Unsubscribe descrito na RFC 8058, que as diretrizes para remetentes do Google exigem de remetentes em massa. E-mails transacionais, como os de redefinição, não devem ser bloqueados por um descadastro.
• Tempo de entrega. E-mails de verificação que levam mais de um ou dois minutos fazem você perder usuários. Se um estiver lento, veja se o seu app coloca os e-mails numa fila atrás de outras tarefas ou se o provedor limita remetentes novos.
• Seus próprios limites de taxa. Martele o botão de reenviar. O app deve limitar isso e pedir que o usuário espere, em vez de mandar dez códigos ou falhar em silêncio.
• Reutilizar um endereço. Cadastre-se duas vezes com o mesmo endereço na mesma sessão e confira a segunda tentativa: um caminho claro de "já cadastrado" e nenhuma segunda conta.
• Sua regra contra domínios descartáveis. Se o seu produto bloqueia endereços temporários, confirme que a mensagem de erro é clara e que ela não bloqueia provedores reais por engano. Mais sobre isso abaixo.

Nossos limites e o que eles significam para um teste

Estas são as configurações reais dos nossos servidores. Planeje os testes em torno delas.

Duração

Uma hora a partir da criação. +1 h volta o prazo a uma hora cheia, até 24 horas depois da criação. Suficiente para uma sessão, não para uma conta de teste que você vai reutilizar na próxima sprint.

Mensagens

Até 50 mensagens e 5 MB por caixa de correio. Novos e-mails são recusados assim que qualquer um dos limites é atingido, então um teste de carga direcionado a um único endereço para de contar rapidinho. Abra uma caixa de correio nova por usuário de teste.

Tamanho da mensagem

Até 1 MB por e-mail, anexos incluídos. Só os 10 primeiros anexos são mantidos.

Só recebe

O endereço não pode enviar nem responder. Fluxos em que o usuário precisa responder por e-mail, como as conversas de tickets de suporte, não podem ser testados de ponta a ponta aqui.

Domínio

Um único domínio para todos os endereços. Se o seu produto bloqueia domínios temporários conhecidos, vai bloquear o nosso, o que é útil quando esse é justamente o comportamento que você quer testar.

Novas caixas de correio

Cinco caixas de correio novas por minuto a partir de um mesmo endereço IP. Uma equipe de QA atrás da mesma conexão do escritório divide essa cota.

Exclusão

Depois que a caixa expira, uma limpeza que roda a cada cinco minutos exclui a caixa de correio, as mensagens e os anexos. Tire capturas de tela antes de o tempo acabar se precisar de evidências para um relatório de bug.

Automação

Não há API pública para acessar caixas de correio por scripts. O PureTempMail foi feito para uma pessoa olhando para um navegador, e é por isso que suítes automatizadas devem usar as ferramentas mais abaixo.

Verificando SPF, DKIM e DMARC nos seus e-mails de teste

Uma mensagem que aparece bem ainda pode falhar na autenticação e cair no spam para os usuários reais. Para verificar, envie o mesmo e-mail para uma caixa que mostre o código-fonte bruto, como o Mostrar original do Gmail, e cole os cabeçalhos no nosso analisador de cabeçalhos de e-mail. Ele mostra se SPF, DKIM e DMARC passaram, aponta um Reply-To em outro domínio e mostra onde a entrega atrasou. A análise roda no seu navegador, então os cabeçalhos não são enviados para nós.

Testando o seu próprio bloqueio de domínios descartáveis

Muitas equipes colocam uma verificação contra e-mail descartável no formulário de cadastro e nunca a testam com um endereço temporário de verdade. Uma caixa temporária é a entrada de teste óbvia.

• Confira o texto. A rejeição deve dizer o que usar no lugar, como "Use um endereço pessoal ou de trabalho". Um simples "E-mail inválido" faz usuários honestos procurarem um erro de digitação que não existe.
• Procure falsos positivos. Teste endereços de pequenos provedores regionais e de domínios próprios de empresas. Listas de bloqueio baseadas em padrões às vezes os pegam.
• Confira todas as portas de entrada. A mesma regra deve valer para o formulário de cadastro, a configuração de troca de e-mail, os convites e a API, senão as pessoas simplesmente vão usar o caminho que você esqueceu.
• Decida se você precisa mesmo do bloqueio. Nosso artigo sobre por que os sites bloqueiam e-mail descartável aborda os custos que o justificam e os casos em que ele só faz você perder usuários honestos.

Quando uma caixa temporária pública é a ferramenta errada

Nestes casos, use outra coisa.

• Qualquer coisa com segredos reais ou dados de clientes. Tokens de produção, faturas reais, convites de administrador. Use um sandbox que só a sua equipe consiga ler.
• Testes automatizados e CI. Aponte o app para um capturador local como o Mailpit no desenvolvimento e no CI, e para um sandbox hospedado como o Mailtrap ou o Mailosaur quando os testes precisarem rodar contra um ambiente implantado. O MailHog, o capturador local mais antigo, não é mais mantido, e o Mailpit é o substituto mais comum.
• Ambientes de staging com cópias de dados reais de usuários. O problema ali são os dados copiados. Anonimize-os e direcione os e-mails de staging para um capturador, para que um teste nunca envie e-mail a um cliente real.
• Contas de teste que você precisa manter. Uma conta de demonstração para vendas ou uma conta de revisão para uma loja de apps precisa de um endereço que funcione no mês que vem. Use endereçamento com sinal de mais numa caixa de correio da equipe ou um catch-all num domínio de teste seu.
• Dados de teste que nunca devem ser entregues. Para dados iniciais e testes unitários, use os domínios reservados, como example.com e o domínio de topo .test, reservados pela RFC 2606. E-mails enviados a eles não vão a lugar nenhum, por definição.

Fontes

• Mailpit no GitHub, a ferramenta e API de testes de e-mail para desenvolvedores, e suas notas sobre a substituição do MailHog.
• Documentação do Mailtrap Email Sandbox.
• Bibliotecas cliente do Mailosaur no GitHub.
• RFC 8058, Signaling One-Click Functionality for List Email Headers.
• Google, diretrizes para remetentes de e-mail.
• RFC 2606, Reserved Top Level DNS Names.
• A duração das caixas de correio, os limites de tamanho e quantidade, os limites de taxa, a recusa SMTP após a expiração e o intervalo de limpeza vêm da configuração dos próprios servidores do PureTempMail, também resumida nas perguntas frequentes.