Dados de teste
Dados de teste para e-mails transacionais: realistas para revelar problemas e limpos para serem excluídos
Bons exemplos não são cópias dos dados de produção, mas fatos de teste bem delimitados, reproduzíveis e vinculados a um único evento.
Comece definindo quatro princípios
Os dados de teste devem ser identificáveis, isolados, reproduzíveis e fáceis de limpar. Ao ver um e-mail, a equipe deve saber imediatamente de qual ambiente e acionamento ele veio e qual versão do modelo foi usada.
Além disso, os casos não devem conter dados reais de clientes, tokens de produção ou credenciais de pagamento válidas. Mesmo com um sistema de testes protegido, siga sempre o princípio da minimização.
Use uma identidade de recebimento independente para cada lote de testes
Atribua endereços temporários independentes a diferentes versões, modelos ou casos de automação para evitar que e-mails antigos satisfaçam novas asserções. O ciclo de vida do endereço deve coincidir com a janela de testes; ao terminar, troque-o ou exclua-o.
Quando for necessário observar os resultados por vários dias, crie uma entrada de encaminhamento para cada fornecedor ou cenário. Não transforme uma caixa de e-mail pessoal compartilhada em depósito permanente de todos os dados de pré-produção.
Conecte logs e e-mails com um ID de evento exclusivo
Inclua nos campos permitidos do modelo um ID de evento não sensível, como uma abreviação do ambiente, a data e um trecho aleatório. Os logs da aplicação, as tarefas da fila e o corpo do e-mail devem usar o mesmo ID, formando um caminho completo para a investigação.
O ID não deve conter e-mail, nome ou chave de negócio. Sua função é relacionar evidências, não transportar a identidade do usuário.
A matriz deve cobrir os limites das variáveis, não apenas acumular casos
Os testes de código devem cobrir código correto, incorreto, expirado, reutilizado e reenvio com intervalo de espera. As notificações transacionais devem abranger textos mínimo e máximo, valores zero e altos, campos opcionais ausentes e diferentes fusos horários.
Os modelos multilíngues também devem verificar se assunto e corpo usam o mesmo locale, se palavras longas transbordam, se datas e números seguem os hábitos regionais e qual é a estratégia de fallback para traduções ausentes.
| Tipo de e-mail | Caso normal mínimo | Limites importantes |
|---|---|---|
| Código de verificação | Código de seis dígitos + validade | Expirado, reenviado, reutilizado |
| Notificação de pedido | Um produto + valor padrão | Nome longo, valor zero, vários fusos horários |
| Alerta de segurança | Dispositivo + horário + número do evento | Dispositivo desconhecido, local ausente |
| Modelo multilíngue | Um e-mail para cada idioma compatível | Fallback, texto longo, direção do texto |
Os casos negativos devem verificar se o usuário consegue se recuperar
A mensagem de erro não é o fim do teste. Depois de um código inválido, o usuário consegue reenviá-lo ou alterar o e-mail? Se faltar uma variável do modelo, a tarefa falha de forma clara? Quando um anexo excede o limite, a resposta permite identificar o problema? Tudo isso precisa ser verificado.
Cada caso negativo deve definir o estado esperado, a mensagem visível e a ação de recuperação. Afirmar apenas que houve “falha” faz muitos fluxos inutilizáveis parecerem aprovados.
Limpe os dados, mas preserve evidências sem informações sensíveis
Ao terminar os testes, exclua os endereços temporários, remova os aliases desnecessários e limpe capturas de tela e logs conforme as regras da equipe. O pacote de evidências precisa conter apenas a versão do modelo, o ID do evento, o horário, o resultado e capturas desidentificadas.
Se um caso precisar ser mantido entre versões, guarde-o em um repositório controlado de dados de teste, em vez de depender de registros de entrega de 30 dias ou de caixas de entrada pessoais.
Uma especificação de caso executável
Para cada caso, documente as pré-condições, a ação de acionamento, os valores das variáveis, o assunto esperado, o corpo esperado, o atraso permitido, as evidências de falha e as ações de limpeza. Se outra pessoa conseguir reproduzi-lo sem consultar o autor, o projeto dos dados está concluído.
Use o planejador de fluxos de pré-produção para estimar o tempo desta rodada conforme o volume da versão e o tipo de modelo e gerar uma ordem de execução mais fácil de repassar.