Como testar o código de login por e-mail do Salesforce em 2026? Etapas de aceite de QA

Conclusão de aceite

Valide separadamente o endereço informado, o recebimento do código, a seleção da conta ou organização e o resultado final do login no Salesforce. Se um endereço estiver associado a várias contas, inclua a etapa de verificação e confirme qual conta foi escolhida. E-mail recebido não significa autenticação aprovada.

Este roteiro é para você que faz regressão de login em uma sandbox ou organização de teste Salesforce, mantém automação de interface ou administra várias organizações ligadas ao mesmo endereço.

Última atualização: 2 de novembro de 2026. As datas e o fluxo descritos foram conferidos nas orientações oficiais sobre mudanças no login, na documentação do login por e-mail e nos documentos de entrada e acesso a várias organizações citados neste guia.

Antes da execução: delimite rollout e entrada

O login por e-mail está sendo disponibilizado por etapas. Segundo as notas oficiais de mudança no login, a implantação em sandboxes começou em agosto de 2026 e a implantação em organizações de produção começou em outubro de 2026. A distribuição é gradual por organização. Essas datas não provam que a organização que você testa já recebeu a mudança.

Comece identificando o alvo. Anote se é sandbox ou produção, qual organização está sob teste e qual URL abre a sessão. O fluxo pode começar pela página de login geral, por um domínio personalizado da organização ou por uma entrada de SSO. Não trate essas opções como equivalentes. O comportamento observado em uma não confirma automaticamente o que acontece nas demais.

A documentação da Salesforce descreve o escopo da experiência padrão de login por e-mail. Antes de adaptar o teste, confira as instruções oficiais para entrar com endereço de e-mail e compare-as com a entrada efetivamente usada. My Domain, Experience Cloud, aplicativo móvel e SSO podem ter regras ou jornadas próprias. Se o seu caso usa um desses caminhos, valide a documentação correspondente em vez de presumir que a página geral se aplica.

A tabela serve para escolher o que comparar, não para declarar compatibilidade. A documentação oficial sobre URLs de login ajuda a identificar a entrada apropriada. Registre a URL usada no teste, mas não publique detalhes internos que exponham a organização ou dados de acesso.

Preparação da conta e do cenário

Antes de iniciar, use uma conta de teste autorizada e uma caixa de entrada que você possa consultar. Confira se o endereço pertence ao usuário de teste esperado e se você sabe quais organizações ou contas estão associadas a ele. Se o endereço estiver ligado a várias contas, inclua a seleção posterior no cenário. A Salesforce descreve um fluxo em que pode ser necessário confirmar o acesso com um código enviado por e-mail antes de escolher a conta. Consulte a orientação sobre acesso a várias organizações com um endereço.

Defina também o que significa “passou” antes de rodar o teste. Uma execução pode produzir resultados diferentes em cada etapa: a interface aceita o endereço, a mensagem chega, a página aceita o código, a conta correta é selecionada e a sessão abre na organização pretendida. Sem critérios separados, um teste pode dar falso positivo apenas porque uma mensagem apareceu na caixa de entrada.

Essa separação também melhora o diagnóstico. Se a mensagem não chegar, você investiga o trecho entre a solicitação e a caixa de entrada. Se chegar, mas a tela rejeitar o código, o problema está em outro ponto do fluxo. Se a sessão abrir na organização errada, o recebimento funcionou, mas o critério funcional não foi atendido.

Primeira execução: observe a interface real

Faça a primeira execução de forma assistida antes de automatizar. Abra a entrada definida no cenário e use as credenciais da conta autorizada. Informe o endereço de e-mail e registre o que a tela apresenta em seguida: opções de autenticação, pedido de código, mensagem de erro ou redirecionamento. Não presuma que todas as contas vão passar pela mesma sequência.

Compare o resultado com a documentação oficial vigente, mas preserve a diferença entre regra documentada e evidência local. A tela que você viu comprova o comportamento daquela organização, daquela entrada e daquela conta naquela execução. Não prova que todas as organizações já mudaram nem que todas as entradas exibem a mesma experiência.

Guarde evidências úteis para repetir o teste: URL de entrada, tipo de organização, identificador interno da conta de teste, horário da tentativa conforme o padrão de registro da equipe, texto relevante da interface e destino do redirecionamento. Remova ou masque dados pessoais e segredos antes de anexar capturas a tickets ou relatórios. Para definir limites entre dados de teste e dados pessoais, consulte o guia de separação de dados em ambientes de teste.

Recebimento do código: valide a mensagem da tentativa atual

Quando a interface solicitar um código, abra a caixa de entrada correspondente ao endereço usado. Confirme se a mensagem está relacionada à tentativa atual e se foi entregue ao destino esperado. Evite copiar um código de uma mensagem antiga ou de outra execução paralela: isso pode deixar o resultado ambíguo e comprometer a reprodutibilidade.

Registre separadamente dois estados: “mensagem recebida” e “código aceito pela página”. O primeiro é uma evidência de entrega. O segundo indica que a interface avançou nessa etapa. Nenhum deles, isoladamente, demonstra que você entrou na organização certa. Não atribua validade fixa ao código nem prometa um tempo de entrega universal; confirme o comportamento que a organização apresentou e documente o que aconteceu na execução.

Se várias execuções compartilham a mesma caixa, associe cada mensagem à tentativa correspondente antes de inseri-la. Sem essa conferência, um teste pode parecer intermitentemente aprovado ou reprovado por consumir a mensagem errada.

Para testar a própria operação de recebimento, escolha uma caixa controlada por você e confirme se ela atende ao cenário antes de iniciar a regressão. Uma caixa temporária pode ajudar a evitar que mensagens de teste se misturem ao e-mail de trabalho, mas não substitui a verificação do código na interface. A bancada de entrega de e-mail pode complementar a preparação quando você estiver avaliando como isolar mensagens de teste.

Depois da verificação: confirme conta e organização

Se o fluxo oferecer opções de conta, organização ou nome de usuário, confronte cada opção com o alvo definido no cenário. Não selecione a primeira opção automaticamente. Em ambientes que compartilham um endereço de e-mail, essa escolha é parte do comportamento que você precisa validar, não uma etapa incidental.

A documentação sobre acesso a várias organizações explica o caso em que pode haver verificação por e-mail antes da escolha da conta. Use essa orientação para montar o cenário, mas registre o que a sua organização efetivamente exibiu. O resultado deve permitir responder: a página apresentou a opção esperada? A opção escolhida corresponde ao teste? A sessão terminou na organização correta?

Confirme o destino final pelo estado autenticado e pela identidade da organização apresentada, não apenas por um redirecionamento ou por uma mensagem de sucesso. Se a página voltar ao pedido de verificação, a sessão ainda não está concluída. Se abrir outra organização, a autenticação pode ter avançado, mas o teste funcional falhou na seleção. Registre esses casos com estados distintos para que a equipe não misture “credencial aceita” com “destino correto”.

Automação: mantenha os caminhos separados

Mantenha casos distintos para o login por e-mail e para o login tradicional com nome de usuário quando ambos fizerem parte da cobertura. O objetivo não é obrigar toda a automação a seguir a interface que apareceu numa execução manual; é testar o caminho de autenticação que o requisito pede.

Se o teste precisa usar nome de usuário, consulte a documentação oficial de URLs de login para verificar a entrada ou o parâmetro aplicável no momento da implementação. Não fixe um parâmetro com base em memória nem suponha que um link usado em uma organização vale para todas. Registre a URL configurada e valide a rota em uma organização autorizada.

Evite seletores que dependem apenas da posição de um botão, da ordem visual dos campos ou de uma frase que possa mudar. Prefira atributos estáveis disponíveis na interface e mantenha uma verificação do estado esperado após cada transição. Se uma alteração de página quebrar o script, identifique se mudou a entrada, a etapa de autenticação, a escolha da conta ou a confirmação final. Essa separação reduz o risco de “consertar” o teste removendo justamente a verificação que deveria detectar uma mudança.

Para a caixa de entrada, defina como a automação identifica a mensagem da tentativa: endereço destinatário, contexto de execução e conteúdo que corresponda ao fluxo atual. Evite compartilhar uma caixa entre processos paralelos sem uma regra clara de correlação. O teste deve falhar com um diagnóstico útil quando não encontra uma mensagem, quando a página não aceita o código ou quando a organização final não corresponde ao alvo.

Decisão para escolher o caminho de teste

Use estas condições para selecionar a abordagem antes de escrever ou alterar a automação:

• Se o requisito cobre o login por e-mail padrão, use uma conta autorizada e uma entrada compatível com esse fluxo. Registre o comportamento observado na organização; não presuma que o rollout já chegou a todas.
• Se o endereço está ligado a várias contas, inclua a verificação por e-mail e a escolha explícita da conta ou organização. Sem essa etapa, você não cobriu o risco de selecionar o destino errado.
• Se o requisito exige nome de usuário, mantenha um caso separado e siga a entrada ou o parâmetro documentado pela Salesforce. Não force o caso de e-mail a representar essa cobertura.
• Se o cenário usa SSO, My Domain, Experience Cloud ou aplicativo móvel, valide a documentação e a entrada específicas. Se não puder confirmar que o caminho está coberto, marque o resultado como pendente, não como aprovado.
• Se a caixa de teste não permite identificar a mensagem desta tentativa, escolha outro método de recebimento controlado ou serializa as execuções. Não aprove o cenário com base em uma mensagem possivelmente antiga.
• Se você só verificou a chegada do e-mail, o teste ainda está incompleto. Continue até confirmar a aceitação do código, a seleção correta e o estado final da sessão.

Essa regra evita que uma regressão de interface seja confundida com um teste completo de autenticação. Ela também torna explícito quando o caminho certo é voltar à documentação, ajustar o cenário ou obter uma caixa controlada mais adequada.

Dúvidas frequentes de QA

Registro de aceite

Ao encerrar, informe o ambiente, a entrada usada, o tipo de conta, se houve código, o resultado do recebimento, a conta ou organização selecionada e o estado final. Anexe evidências sem expor credenciais ou dados pessoais. Se algum dado não puder ser coletado, indique a lacuna em vez de preencher por inferência.

Classifique o resultado conforme a etapa atingida. “Recebido” não equivale a “aceito”; “aceito” não equivale a “organização correta”. Essa linguagem ajuda desenvolvimento e QA a localizar a falha sem atribuí-la automaticamente ao serviço de e-mail ou à interface.

Limite a conclusão ao que foi executado. Se você testou uma organização, uma entrada e uma conta, o relatório deve dizer isso. Não declare que “o login Salesforce está aprovado” em geral quando o teste não cobriu outros caminhos. Se a Salesforce alterar o calendário de rollout, os escopos de entrada ou as instruções de automação, revise o cenário com base nos documentos oficiais atuais, não em capturas antigas.

Para a etapa de recebimento, use um endereço controlado e avalie antes se ele permite acompanhar a mensagem necessária ao seu teste. Quando o objetivo é apenas registrar uma conta temporária de teste ou verificar uma mensagem, o MsgMask pode ser uma opção para manter esse recebimento separado do seu endereço principal. O serviço não substitui a validação do login nem garante compatibilidade com todo fluxo Salesforce: confira a capacidade de recebimento necessária ao seu caso antes de usar. Se fizer sentido para o cenário, você pode abrir o MsgMask e iniciar sem criar uma conta.

Perguntas frequentes