Percorre a tarefa completa com dados de teste
Começa pela tarefa que justifica a aplicação e acompanha-a desde a entrada até ao resultado utilizado por alguém. Usa dados preparados para teste e verifica o que fica guardado, o que aparece depois e o que acontece ao regressar. Abrir os ecrãs isoladamente não confirma que o percurso funciona como um todo.
Imagina uma associação que está a construir uma aplicação para inscrições em atividades. O percurso principal pode incluir escolher uma sessão, preencher os dados necessários e consultar o estado do pedido. Para o testar, precisas de confirmar que a sessão escolhida chega corretamente ao registo que a equipa vai tratar.
Depois fecha a página e volta a consultar o pedido. Se a informação só existia enquanto o formulário estava aberto, a demonstração inicial não validou a persistência. A comparação deve usar o resultado esperado que foi definido para a aplicação, incluindo os campos que precisam de ficar disponíveis após a submissão.
Experimenta ainda um percurso com uma diferença relevante, como uma sessão sem vagas ou uma inscrição já registada. Escolhe estes casos pela regra que exercitam. Não precisas de inventar dezenas de cenários sem propósito, mas precisas de verificar os que podem mudar a decisão da pessoa ou da equipa.
Os critérios devem vir do trabalho de planear a aplicação antes de programar. Se não existe uma resposta clara sobre o que deveria acontecer, regista uma decisão pendente. Um teste não resolve por si só a ambiguidade de um requisito que ainda admite comportamentos incompatíveis.
Para preparar o próximo passo, consulta Segurança de aplicações desenvolvidas com IA.
Verifica o que acontece com dados incompletos ou inválidos
Os testes devem incluir informação em falta, valores fora das regras e tentativas de repetir uma ação. Confirma que a aplicação explica a situação e não guarda um resultado incoerente. A validação visível no formulário ajuda a pessoa, mas as regras precisam de continuar a ser aplicadas quando o pedido chega ao sistema.
Na inscrição hipotética, verifica o que acontece quando falta um contacto necessário ou quando alguém seleciona uma sessão que entretanto deixou de aceitar pedidos. A mensagem deve orientar a correção sem apresentar como concluída uma inscrição que o sistema não conseguiu registar. Observa também se os restantes dados preenchidos são preservados.
Para uma ação de submissão, testa a repetição relevante para o teu caso. Uma pessoa pode carregar novamente porque não percebeu se o primeiro pedido terminou. O comportamento esperado deve impedir confusão entre uma nova inscrição legítima e a repetição do mesmo pedido, de acordo com a regra definida pelo projeto.
Pede ao agente que distinga os testes de apresentação dos testes das regras aplicadas pelo servidor. Um botão desativado pode melhorar o percurso e continuar a ser insuficiente como controlo. O relatório deve explicar que comportamento foi exercitado, com que entrada e que resultado foi observado em cada verificação.
Usa contas com responsabilidades diferentes
Testa os acessos com os tipos de utilizador previstos e inclui uma pessoa sem sessão iniciada. Verifica tanto as ações permitidas como aquelas que devem ser recusadas. Uma conta de administrador não serve para demonstrar os limites das restantes contas, porque pode ter acesso legítimo a informação que lhes deve ser escondida.
Na associação, uma pessoa inscrita pode precisar de consultar o próprio pedido, enquanto a equipa organiza todas as inscrições de uma atividade. Prepara registos fictícios para duas pessoas diferentes e confirma a separação. O teste deve observar os dados entregues pelo sistema, além das opções que aparecem no menu.
Esta verificação tem de ocorrer num ambiente que controlas e com identidades de teste. Não uses contas de clientes reais para tentar descobrir o alcance de uma falha. O objetivo é reproduzir as condições de acesso sem expor informação ou realizar ações sobre pessoas que não participam na validação.
Antes de começar, confirma para onde o ambiente local está a enviar pedidos. Uma aplicação aberta no teu computador pode estar ligada a serviços reais. A preparação de ambiente e acessos para trabalhar com Claude Code deve incluir essa identificação, para que o teste não produza efeitos fora do espaço previsto.
Observa a resposta quando uma dependência falha
Uma aplicação pode funcionar enquanto todos os serviços respondem e falhar de forma confusa quando uma ligação demora ou deixa de estar disponível. Simula essas condições no ambiente de teste. Confirma que o utilizador recebe informação útil e que a aplicação não apresenta uma conclusão que ainda não conseguiu confirmar.
Se o serviço que guarda a inscrição não responder, a página não deve mostrar sucesso apenas porque o formulário foi enviado. Precisas de saber se o pedido ficou pendente, falhou ou foi efetivamente registado. A resposta determina se a pessoa deve aguardar, corrigir alguma coisa ou repetir a operação.
Também interessa verificar o que acontece ao retomar. Uma tentativa repetida não deve criar efeitos duplicados por acidente, e uma falha parcial precisa de poder ser investigada. Guarda informação suficiente para identificar o passo que falhou, evitando incluir nos registos técnicos dados pessoais ou credenciais que não são necessários.
O princípio é o mesmo de testar uma automação antes da entrega: verificar o percurso normal e as exceções que alteram o resultado. Um teste deliberado de falha pode esclarecer mais sobre a preparação da aplicação do que repetir várias vezes o caminho que já sabes que funciona.
Fecha os testes locais e identifica o que falta online
Antes de publicar, confirma que a versão de entrega passa as verificações técnicas definidas para o projeto e pode ser preparada sem erros conhecidos impeditivos. Junta esse resultado aos testes de comportamento. Se uma condição depende do alojamento ou de uma integração externa, regista-a como pendente de validação no ambiente correspondente.
Pede uma lista curta que relacione cada verificação com a versão analisada. Distingue testes executados de recomendações ainda por cumprir e de pontos avaliados apenas por leitura do código. Essa diferença permite decidir com base na evidência disponível, em vez de interpretar uma frase geral de aprovação como uma revisão integral.
O endereço público, as configurações do alojamento e as ligações entre serviços podem introduzir condições diferentes das do computador local. Por isso, a publicação deve ter verificações próprias depois da passagem, com autorização e dados adequados. O sucesso local é uma etapa necessária do processo definido, sem substituir a observação do ambiente final.
Se existir uma falha que afeta o percurso principal, corrige-a e repete as verificações relacionadas antes de avançar. Quando a evidência estiver organizada, consegues explicar o que está pronto, quais os limites conhecidos e o que será confirmado a seguir. Essa clareza torna a decisão de colocar a aplicação online mais responsável.