Checklist de desenvolvimento e QA
Receber um e-mail não basta. Use este checklist para verificar gatilhos, identidade do destinatário, conteúdo, ações, timing, falhas e privacidade, tornando a decisão de publicação reproduzível.
Escopo
Os cartões não são apenas decoração. Execute-os da esquerda para a direita, na ordem dos testes; uma falha bloqueadora nunca deve ser liberada apenas com um “envie novamente”.
Antes do teste, deixe claro “quem fez o quê e em qual estado” e liste as condições que devem e não devem gerar um envio. Testar apenas o caminho de sucesso deixa de fora ramificações importantes, como preferências de notificação desativadas, conta já verificada e deduplicação de eventos.
Copie o endereço de recebimento da barra de ferramentas do recurso de testes atual, evitando digitá-lo manualmente. Ao trocar o endereço, atualize também o usuário de teste; mensagens antigas não são migradas, e misturar endereços antigos e novos compromete a confiabilidade do resultado.
Verifique o tamanho do código, o conjunto de caracteres, a validade, a invalidação após o uso e as regras de reenvio. Se a página informa 10 minutos, mas o backend expira em 5, isso é uma falha do produto, não um detalhe de texto.
Valide também o retorno para códigos incorretos ou expirados, entradas consecutivas e reenvios frequentes. Em validações por link, confira protocolo, hostname, ambiente, token de uso único e a página final após o redirecionamento; não basta confirmar que o botão pode ser clicado.
No corpo do e-mail, confira a largura do contêiner, a quebra dos títulos, a altura dos botões, o espaçamento dos parágrafos e o redimensionamento das imagens. Nomes longos, nomes extensos de projetos e botões em francês ou português podem estourar o layout com mais facilidade que o chinês; faça a regressão usando a amostra mais longa razoável.
Mesmo com as imagens desativadas, a marca e a tarefa principal devem continuar identificáveis; a versão em texto simples deve manter o código, o prazo, os links e as informações de suporte. Não coloque todo o conteúdo em imagens nem deixe o texto de prévia oculto aparecer na primeira linha do corpo.
Abra individualmente o botão principal, os links secundários, a área de ajuda e o cancelamento de inscrição; confirme domínio, caminho, parâmetros e estado de login. Links de teste não devem apontar por engano para operações de escrita em produção, e templates de produção não devem conter domínios de teste.
Confira nome, tipo, tamanho e permissões dos anexos; tipos perigosos devem ser bloqueados ou isolados. Ao responder, confirme se Reply-To chega ao canal de suporte esperado, evitando respostas para um endereço de envio sem monitoramento.
Assunto, prévia, corpo, botões e mensagens de erro devem estar no mesmo idioma; datas, valores e fusos horários devem seguir o formato da região do usuário. Quando faltar uma tradução, use um fallback controlado, em vez de misturar idiomas aleatoriamente no mesmo e-mail.
A hierarquia dos títulos deve ser contínua, e o texto dos links deve descrever seu objetivo; as imagens devem ter texto alternativo adequado. A cor não pode ser o único meio de indicar um estado, e o contraste deve ser suficiente tanto para texto claro sobre fundo branco quanto para texto escuro sobre fundo colorido.
Simule atrasos na fila, recusas temporárias do provedor e rejeições permanentes; observe se o sistema tenta novamente conforme a política e evita notificações duplicadas. A interface deve apresentar um status acionável, em vez de classificar toda falha como “erro de rede”.
Se o e-mail de teste não chegar, investigue camada por camada, usando evidências da aplicação, da fila, da plataforma de envio, do DNS e do destinatário. Preserve a evidência da primeira falha e valide o reparo depois; não apague as pistas originais só porque um reenvio posterior funcionou.
| Nível | Exemplo | Critério de publicação | Tratamento da falha |
|---|---|---|---|
| Bloqueador | E-mail não gerado, destinatário incorreto, código indisponível ou link principal errado | Todos devem passar | Interromper a publicação e corrigir a causa raiz |
| Alto | Envio duplicado, prazo inconsistente ou conteúdo cortado no celular | Corrigir ou obter aceite por escrito do responsável | Definir prazo claro e caso de regressão |
| Médio | Prévia repetida, rótulo de link secundário pouco claro ou quebra ruim de texto longo | Avaliar público e frequência | Incluir na próxima iteração e manter evidências |
| Baixo | Pequena diferença visual sem impacto na tarefa | Não bloqueia o fluxo principal | Registrar o template e o escopo de clientes |
Registre o número do caso, ambiente, versão do template, idioma, prefixo do endereço de recebimento, horários do gatilho e da chegada, ID da mensagem, resultado e link do defeito. As capturas devem mostrar o assunto e o conteúdo principal, mas ocultar tokens e dados pessoais reais.
Após o reparo, faça a regressão nas mesmas condições e teste também o caminho de falha mais próximo. Se precisar de ajuda para localizar problemas de entrega, consulte o guia de diagnóstico de entrega de e-mails ou entre em contato com support@msgtmp.com.
