A Passkey falha e a equipe não sabe se o problema está no login ou na recuperação por e-mail.
Solução rápida: teste os caminhos separadamente: valide a autenticação com Passkey e, em outro caso controlado, acompanhe a recuperação desde a geração da mensagem até o estado final da conta.
Desenvolvimento: para quem implementa Passkey e precisa verificar a alternativa de e-mail no próprio produto.
QA: para quem precisa registrar recebimento, processamento do link e resultado da conta como evidências distintas.
Segurança: para quem avalia se a recuperação atende às regras e aos objetivos de proteção definidos pelo produto.
A conclusão de aceite precisa separar os caminhos
Passkey login e recuperação por e-mail não são duas etapas de uma mesma prova. O teste de Passkey verifica se a credencial autentica a conta conforme a implementação. O teste de recuperação verifica se o produto oferece uma alternativa definida, envia a mensagem esperada e conclui a ação de recuperação corretamente.
Não trate uma etapa como substituta da outra. Uma autenticação por Passkey bem-sucedida não demonstra que a mensagem de recuperação foi criada ou chegou à caixa de entrada. Da mesma forma, receber uma mensagem não prova que o link foi processado, que a conta mudou de estado ou que o acesso foi restaurado.
A documentação oficial de jornadas de Passkey descreve alternativas por e-mail ou telefone como possibilidades de recuperação em certos contextos. Isso não determina que todo produto precise oferecer essas opções, nem padroniza o comportamento de links ou o estado final da conta. A equipe deve usar a documentação como referência de experiência, mas definir o aceite a partir da implementação própria e dos materiais técnicos aplicáveis. A orientação oficial sobre jornadas de usuário com Passkey ajuda a compreender esse limite.
Antes de executar o teste, registre o que o produto realmente oferece quando a credencial não está disponível, foi removida ou não pode ser usada. A alternativa pode ser um código por e-mail, um link de login ou um fluxo específico de recuperação da conta. Esses mecanismos não são intercambiáveis: cada um pode exigir ações e produzir resultados distintos.
Desenvolvimento: transforme a implementação em critérios observáveis
O trabalho de desenvolvimento começa com um mapa do comportamento esperado. Não deduza o fluxo a partir de como outro serviço funciona. Especifique as telas e ações do próprio produto, as condições para iniciar a recuperação e os efeitos esperados depois da confirmação.
| Caminho implementado | O que observar na mensagem | Resultado a confirmar |
|---|---|---|
| Código enviado por e-mail | Código, instruções e conta de destino correspondem à solicitação | O produto aceita ou rejeita o código conforme as regras implementadas |
| Link para entrar | A mensagem deixa claro que o link concede acesso | O produto cria a sessão ou aplica o efeito definido para esse link |
| Link de recuperação de conta | A mensagem explica a ação de recuperação solicitada | A conta e as credenciais mudam conforme a política do produto |
| Sem alternativa por e-mail | Não deve surgir uma mensagem de recuperação inesperada | O fluxo comunica a alternativa realmente disponível |
A tabela é um roteiro de inspeção, não uma especificação universal. Por exemplo, um link pode iniciar uma troca de credencial, permitir uma etapa de verificação ou apenas levar a uma tela autenticada. O comportamento aceito precisa estar definido pelo produto. A documentação de servidor sobre autenticação com Passkey pode orientar a implementação da autenticação, mas não substitui a definição do fluxo de recuperação da equipe. Consulte as orientações técnicas de autenticação no servidor.
Como saber se o e-mail de recuperação pertence a esta execução? Correlacione a solicitação com uma conta de teste e com o evento gerado pela aplicação. Use um identificador de execução ou outro dado de correlação não sensível em registros internos. Na caixa de teste, confira o destinatário e o conteúdo esperado. Se várias execuções estiverem ativas, mantenha endereços ou identificadores separados para que uma mensagem antiga não seja atribuída ao caso atual.
A correlação deve evitar dados pessoais reais. Prefira contas sintéticas nos ambientes autorizados e endereços controlados pela equipe. Para aprofundar a separação entre endereços de teste e caixas de trabalho, consulte as recomendações sobre segurança de e-mails usados em cadastros.
QA: acompanhe cada marco da mensagem
Para a equipe de QA, o teste começa quando a pessoa aciona a recuperação no produto, não quando alguém encontra uma mensagem na caixa de entrada. Registre o caso de teste, a conta sintética, o ambiente e a ação executada. Depois, acompanhe os marcos sem misturar estados diferentes:
- Solicitação iniciada: a interface aceita a ação e mostra a resposta prevista, sem revelar dados de outras contas.
- Mensagem gerada: a aplicação produz o e-mail correto para a conta associada ao teste.
- Solicitação encaminhada: o serviço de envio aceita a solicitação da aplicação, conforme o registro disponível.
- Mensagem recebida e legível: a caixa de teste permite abrir e inspecionar o e-mail.
- Link ou código processado: o produto aceita, rejeita ou consome o elemento conforme o comportamento implementado.
- Conta verificada: o estado da conta e a possibilidade de acesso correspondem ao resultado definido.
Esses marcos respondem a perguntas diferentes. Um registro de que a aplicação gerou uma mensagem não confirma que o serviço de envio a aceitou. A aceitação pelo serviço não comprova a entrega. E a entrega não demonstra que a conta foi recuperada. Documente o ponto exato em que o teste parou; não registre todos os resultados como “e-mail enviado”.
Que etapas verificar quando o login com Passkey falha? Confirme primeiro qual alternativa o produto promete para aquela condição. Em seguida, verifique se a solicitação de recuperação corresponde à conta de teste, se o e-mail contém a ação esperada, se o código ou link é processado como previsto e se o estado da conta muda corretamente. Por fim, teste o acesso posterior usando o método que a implementação define. Assim, uma falha de entrega não fica confundida com um problema de autenticação.
Use uma caixa controlada que permita ler a mensagem recebida e inspecionar seu conteúdo. Se a equipe comparar alternativas de recebimento para o ambiente de testes, avalie retenção, acesso e adequação ao fluxo; os fatores que afetam a validade de uma caixa temporária podem ajudar nessa decisão. Não presuma que um serviço de recebimento temporário seja adequado para todo fluxo: confirme as capacidades publicadas antes de depender dele.
Primeiro marco: geração e endereço de destino
Acione o fluxo no produto próprio, usando uma conta criada para teste. Compare o endereço que iniciou a solicitação com o endereço que recebeu a mensagem e confira se a aplicação apresenta informações compatíveis com a política de privacidade do produto. Não exponha detalhes da conta na resposta da tela nem use o conteúdo do e-mail para inferir se um endereço real está cadastrado, salvo se essa divulgação for parte consciente e aprovada da experiência.
Inspecione assunto, texto, instruções e destino do link. O conteúdo deve corresponder à ação real: um código não deve ser descrito como link de login, e um link de recuperação não deve sugerir que a simples abertura já concluiu a recuperação se ainda houver etapas. Mantenha a mensagem em um ambiente autorizado e não compartilhe capturas de tela contendo links ativos ou dados de acesso.
Segundo marco: processamento do link e estado final
Abra o link a partir da mensagem de teste e execute as ações que o produto solicita. O teste deve observar mais do que a navegação para uma página: verifique se a operação termina, se a conta fica no estado previsto e se o acesso posterior corresponde às regras definidas.
Inclua caminhos de sucesso e de falha. Se a implementação define validade, uso único ou outra condição para o link, teste essa regra conforme a especificação do produto. Não generalize essas propriedades para outros serviços nem as trate como comportamento universal. Para um link que deveria ser consumido uma única vez, por exemplo, a equipe precisa verificar a resposta do próprio produto a uma nova tentativa; para outro desenho, o resultado esperado pode ser diferente.
Depois de receber o link, como confirmar o resultado da recuperação? Registre o destino alcançado, a resposta do produto e o estado da conta após a ação. Em seguida, faça uma tentativa de acesso com o método previsto pela implementação e confirme se ela funciona ou falha conforme o critério de aceite. Uma mudança de página, isoladamente, não é prova de recuperação concluída.
| Evidência registrada | O que ela comprova | O que não comprova sozinha |
|---|---|---|
| Evento de geração na aplicação | A aplicação iniciou a criação da mensagem | Entrega ou leitura pelo destinatário |
| Aceitação pelo serviço de envio | A solicitação foi aceita pelo componente de envio | Chegada à caixa de teste |
| Mensagem visível na caixa controlada | O conteúdo pode ser inspecionado no destino de teste | Processamento bem-sucedido do link |
| Resposta após abrir o link | O produto respondeu à ação de recuperação | Acesso final correto sem verificar a conta |
| Estado final e tentativa de login | O resultado funcional previsto foi observado | Cobertura de cenários não testados |
Segurança: limite a evidência e proteja os dados de teste
A recuperação por e-mail é uma opção que o produto decide oferecer; não é uma extensão automática da autenticação por Passkey. Não afirme que ambas têm as mesmas propriedades de segurança apenas porque levam ao acesso da mesma conta. Analise o caminho de recuperação de acordo com a política do produto, os riscos que ele precisa reduzir e as orientações técnicas aplicáveis. As diretrizes de identidade digital sobre recuperação de contas tratam a recuperação como parte que merece controles próprios, e não como prova de que qualquer mecanismo de e-mail tem um nível de segurança predeterminado.
Revise também a exposição das evidências. Mensagens, links ativos, códigos, endereços e registros de execução podem revelar informações que não deveriam circular em logs, capturas de tela ou relatórios compartilhados. Restrinja o acesso aos resultados, remova segredos de artefatos de CI/CD e evite usar contas de colegas ou dados pessoais reais em demonstrações. Se um relatório precisar mostrar que o teste passou, prefira evidenciar o estado funcional sem reproduzir o segredo que permitiu a operação.
Equipe: decida o que liberar com condições explícitas
A decisão de aceite fica mais clara quando a equipe separa os caminhos e declara o que ainda não foi verificado. Use a lista condicional abaixo para escolher a cobertura adequada:
- Se a Passkey autentica a conta conforme o critério definido, registre o resultado do login. Não marque o fluxo de recuperação como aprovado sem executá-lo.
- Se o produto oferece recuperação por e-mail, faça um teste controlado que acompanhe geração, envio, recebimento, processamento e estado final.
- Se a mensagem chega, mas o link não conclui a ação prevista, mantenha a recuperação como reprovada ou inconclusiva; não use a chegada da mensagem como substituto do resultado.
- Se a equipe só validou a geração ou a aceitação pelo serviço de envio, registre a limitação e programe uma verificação externa de recebimento antes de afirmar que a entrega foi coberta.
- Se a recuperação não faz parte do produto, documente qual alternativa existe. Não crie uma expectativa de recuperação por e-mail com base no comportamento de outra plataforma.
- Se a implementação mudou desde o último aceite, repita os casos que possam afetar o conteúdo, o processamento do link e o estado da conta.
Passar no teste de Passkey significa que a recuperação por e-mail também passou? Não. O resultado de Passkey confirma apenas o caminho de autenticação exercitado. A equipe deve manter evidências separadas para login por credencial, recebimento de e-mail, processamento do link e resultado da conta. O material de experiência da FIDO também aborda a criação e o login com Passkey como etapas de uma experiência mais ampla; ele não transforma a recuperação por e-mail em consequência automática de um login bem-sucedido. Consulte as recomendações de experiência para criação e login com Passkey.
Ao fechar a validação, escreva o alcance do teste em termos verificáveis: qual ambiente e conta sintética foram usados, qual alternativa foi exercitada, até que marco a equipe acompanhou a mensagem e qual estado final observou. Registre também o que ficou fora da cobertura, como recebimento em caixas externas ou regras que não foram executadas. Essa precisão evita que um resultado parcial seja interpretado como aprovação completa do fluxo.
Para testes pontuais do produto próprio, uma caixa temporária pode ser uma opção para receber mensagens sem expor o endereço corporativo. O DewinBox pode entrar nessa avaliação quando a capacidade publicada atender ao cenário; confira no próprio serviço se o acesso exige cadastro e quais são as condições de disponibilidade e retenção antes de incorporá-lo à rotina. Para recuperação duradoura ou contas importantes, mantenha um endereço que a equipe ou a pessoa responsável possa acessar no longo prazo.
Restabeleça um fluxo de recebimento claro
Crie uma caixa de entrada temporária para receber o código. Se as notificações continuarem por mais tempo, use um alias de encaminhamento permanente que possa ser pausado.