Teste jornadas completas, não respostas isoladas
Um teste útil não reúne apenas algumas respostas bem-sucedidas; ele percorre jornadas completas. Inclua primeira sessão, conta antiga com histórico, troca de idioma e mídia, aparelho compartilhado, conexão interrompida, bloqueio e denúncia, compra, exportação, exclusão e comportamento depois de atualizar. Cada jornada começa com um limite esperado e termina com uma verificação de recuperação. O programa ARIA do NIST separa teste de modelo, red teaming e teste de campo, lembrando que uma resposta é só uma camada do produto. Use conteúdo fictício neutro, contas próprias para teste e controles comuns. Não insira informações de terceiros nem procure saídas perigosas. Registre o que ocorreu, o que continua desconhecido e se a pessoa consegue voltar a um estado compreensível.
Prepare uma ficha de cenário com sete campos
Anote contexto, estado da conta, variação da entrada, limite esperado, resultado observável, caminho de recuperação e evidência guardada. Contexto inclui aparelho, versão, idioma, rede e plano. Estado distingue usuário novo, retorno com histórico, restrição, saída ou exclusão pendente. Mude tamanho, tom, ortografia, idioma e mídia mantendo a mesma tarefa. A expectativa descreve uma conduta concreta, não “funciona bem”. Registre mensagens, visibilidade de dados, ações externas e alterações de estado. Verifique desfazer, tentar novamente, bloquear, denunciar, cancelar, sair ou pedir suporte. Retire senhas, tokens e material de terceiros da evidência. Repetir a ficha depois de uma versão gera uma comparação, em vez de uma impressão solta.
Cubra identidade, memória e troca de aparelhos
Teste cadastro, recuperação, lista de sessões, saída e retorno em um segundo aparelho. Compare uma sessão nova, uma conta com histórico e a mesma conta depois de apagar o histórico. Em aparelho compartilhado, verifique prévias de notificação, tela de apps recentes, preenchimento automático, mídia baixada e acesso local após sair. Troque separadamente o idioma da interface e o da entrada; uma tela traduzida não demonstra limites iguais em controles e respostas. Interrompa rascunho, upload, compra ou exclusão com modo avião, segundo plano, reinício ou sessão expirada. Procure duplicação, perda e estados ambíguos. Essas transições revelam falhas que uma conversa contínua não mostra.
Teste texto, voz, imagem e conteúdo externo separadamente
Cada superfície possui permissões, transformações, armazenamento e erros diferentes. Expresse uma tarefa fictícia inofensiva de forma curta, longa, com erros, citações, hipótese e idiomas misturados. Na voz, observe momento da permissão, indicador de gravação, transcrição, exclusão e alternativa à falha. Na imagem, use material neutro criado por você e confira envio, prévia, remoção, metadados informados e interrupção. Se o app abre links, arquivos, páginas ou ferramentas, inclua texto externo inofensivo que entre em conflito com a solicitação e confira se a intenção original continua prioritária. Os riscos da OWASP indicam que manipulação de entrada e exposição de informação surgem nos limites do aplicativo, não somente nas palavras da resposta.
Percorra controles de interação de ponta a ponta
Quando existem mensagens, seguidores, comentários, presentes ou espaços, confira padrões de descoberta, público, silenciar, bloquear, denunciar, guardar evidência, informações de recurso e estado nas duas contas. O bloqueio não está completo se muda uma tela mas mantém notificações, links antigos, grupos ou outro canal. Use duas contas de teste claramente nomeadas e não envolva pessoas desavisadas. Para denúncia, empregue conteúdo inofensivo e pare antes de enviar se isso ocupar uma fila real sem rota de teste. Separe botão funcionando de resolução confirmada. Prazo e resultado podem continuar desconhecidos e devem aparecer assim no registro.
Inclua dinheiro, saída e regressão após atualização
Confira nível gratuito, fim do teste, aviso de renovação, autenticação, pagamento recusado, cancelamento, expiração de acesso e diferença entre excluir a conta e encerrar cobrança da loja. Use meios seguros de teste quando houver e evite compras desnecessárias. Examine exportação, remoção individual, pedido de exclusão de conta, confirmações anunciadas e visibilidade durante a espera. Após mudanças no app, modelo, política, permissões ou pagamento, repita jornadas importantes. O Google recomenda dados específicos do produto e entradas variadas, pois referências genéricas não representam toda configuração. Mantenha uma regressão curta: aparelho compartilhado, envio interrompido, usuário bloqueado, assinatura cancelada e histórico excluído.
Avalie cobertura pela capacidade de recuperação
Uma resposta elegante não compensa pedido de exclusão perdido, visibilidade inesperada, cobrança incerta, upload travado ou comando irreversível. Classifique fichas em confirmado, condicional, contradito e desconhecido. Priorize desconhecidos que juntem dados, ação externa, dinheiro ou estado difícil de reverter. Uma falha deve trazer estado inicial, reprodução mínima, resultado visível, tentativa de recuperar e versão; “a AI falhou” é amplo demais. Uma aprovação também declara seu escopo. A regra prática é que, quando a rota ideal quebra, uma pessoa comum consiga ver o estado, entender o ocorrido e alcançar um próximo passo documentado. Caso contrário, o teste permanece aberto.
Perguntas frequentes
Quantas entradas são suficientes?
Não há número universal. Cubra jornadas, variações, limites e recuperação e acrescente casos de mudanças e falhas observadas.
Usuários devem tentar ataques ao modelo?
Não. Ensaios especializados exigem ambiente autorizado e controles claros.
Um bom benchmark do modelo basta?
Não. O aplicativo também inclui conta, histórico, permissões, ferramentas, interação, pagamento, armazenamento e recuperação.