Troca o pedido genérico por uma regra observável
Um teste negativo começa com uma regra que pode ser confirmada, como impedir que um colaborador leia pedidos de outro cliente. Especifica quem tenta agir, sobre que registo e em que condições. O resultado deve descrever a recusa e o estado que precisa de permanecer intacto depois da tentativa.
“Testa a segurança” deixa demasiado espaço para interpretações. A IA pode verificar o login, abrir algumas páginas e concluir que não encontrou erros. Isso não responde à pergunta de negócio: uma pessoa com acesso a um projeto consegue consultar outro para o qual nunca recebeu autorização?
Imagina um portal hipotético com dois projetos e duas contas de colaboradores. Cada conta deve ver apenas o respetivo projeto. Pede um teste em que a primeira conta tenta abrir um registo do segundo projeto. O resultado esperado inclui não receber o conteúdo desse registo, mesmo que conheça o seu endereço.
Acrescenta a ação de modificar. Uma pessoa pode ter permissão para ler uma proposta, mas não para aprovar a sua execução. O teste deve verificar se a tentativa de aprovação é recusada e se a proposta mantém o estado anterior. A existência de leitura autorizada não resolve a questão da escrita.
Estas regras devem surgir ao planear a aplicação antes de programar. Fazer perguntas nesta fase permite esclarecer decisões que a IA não consegue tomar pelo negócio. Se ninguém definiu quem pode aprovar, um teste que passa apenas confirma uma suposição introduzida durante o desenvolvimento.
Para preparar o próximo passo, consulta Segurança de aplicações desenvolvidas com IA.
Escolhe contas e dados que revelem a diferença
Prepara identidades de teste com permissões distintas e registos que pertençam a cada uma. Inclui uma pessoa sem sessão iniciada e outra com acesso limitado. Usa informação fictícia que permita reconhecer uma exposição indevida, evitando dados reais de clientes e qualquer envio ou alteração fora do ambiente previsto para o ensaio.
No portal hipotético, chamaria aos registos “Projeto de teste A” e “Projeto de teste B”. A diferença precisa de ser visível para quem lê o relatório. Se todas as contas forem administradoras ou partilharem os mesmos dados, o ensaio não consegue demonstrar que existe isolamento entre utilizadores.
Também prepararia uma conta cujo acesso foi retirado. O comportamento esperado deve ficar definido: essa pessoa já não pode consultar nem alterar o projeto protegido. Testar apenas contas criadas de raiz deixa por observar o que acontece quando as responsabilidades mudam e um acesso anteriormente válido termina.
Diz à IA o que pode executar. Por exemplo, criar registos fictícios, iniciar sessões de teste e consultar resultados nesse ambiente. Exclui envios reais, cobranças e alterações em contas de clientes. Um pedido de teste precisa de limites operacionais tão claros como os da funcionalidade que está a ser testada.
Regista o ponto de partida antes da tentativa. No caso da aprovação, guarda o estado e a versão do pedido; no caso de um valor, guarda o montante atual. Sem esta referência, um relatório pode mostrar uma mensagem de erro e deixar passar uma alteração que aconteceu apesar da recusa apresentada.
Testa caminhos diferentes para a mesma ação
A recusa deve manter-se nos caminhos que permitem chegar à ação, incluindo pedidos diretos ao servidor. Não limites a verificação à ausência de um botão no ecrã. Pede à IA que relacione os testes com os pontos de entrada existentes na tua aplicação e apresente as verificações que conseguiu executar.
Uma interface pode esconder a opção de apagar e o servidor continuar a aceitar a operação. Num ensaio autorizado da própria aplicação, a verificação deve confirmar que a regra é aplicada onde o pedido é processado. A aparência do ecrã dá informação sobre a interface; não prova, sozinha, a autorização efetiva.
O mesmo cuidado aplica-se a anexos e exportações. Se a página de um projeto está protegida, mas o respetivo documento fica acessível a qualquer conta, o teste precisa de identificar essa diferença. Inclui os recursos que fazem parte da tarefa, em vez de testar apenas o primeiro ecrã que a pessoa vê.
Se houver vários tipos de utilizador, combina casos permitidos e recusados. O colaborador autorizado deve conseguir consultar o seu projeto; a mesma conta deve ser impedida de abrir o outro. Um sistema que bloqueia tudo também passa numa verificação mal desenhada que procure apenas recusas.
Pede um relatório com o caso executado, o resultado esperado e o observado. Se a IA não conseguiu iniciar determinada sessão ou alcançar um ponto de entrada, isso fica como teste não executado. Não aceites que ausência de resultado apareça resumida como sucesso, nem que uma descrição de código substitua uma execução que foi pedida.
Inclui dados inválidos e estados que impedem avançar
Além das permissões, testa entradas que violam as regras do processo: campos obrigatórios vazios, valores fora dos limites e alterações numa versão antiga. Define a resposta esperada em cada caso. A aplicação deve explicar a recusa de forma útil e evitar guardar uma operação parcial que deixe o trabalho inconsistente.
Num exemplo hipotético de pedido de compra, a quantidade pode ter de ser positiva e a justificação obrigatória acima de um limite definido pela empresa. A IA precisa dessas condições antes de construir os casos. Não lhe peças para inventar valores aceitáveis só para conseguir preencher uma tabela de testes.
Testa os limites exatos, incluindo o valor permitido e o primeiro valor que deixa de ser aceite. Essa comparação mostra se a regra foi implementada com o significado pretendido. O mesmo raciocínio vale para os limites de uma automação que altera o orçamento dos anúncios, onde uma interpretação errada pode ter consequências concretas.
Considera também um pedido já concluído. Se a regra diz que uma aprovação só pode ocorrer uma vez, repetir a ação não deve criar outra execução ou notificação indevida. A equipa deve decidir como tratar a repetição e pedir uma prova desse comportamento, incluindo o que ficou registado depois das duas tentativas.
Numa edição concorrente, alguém pode tentar guardar uma versão desatualizada. O resultado esperado pode ser pedir que recarregue a informação, em vez de substituir silenciosamente o trabalho mais recente. Este caso testa uma regra de colaboração e integridade dos dados, mesmo quando todas as pessoas envolvidas têm permissões legítimas.
Usa as falhas para corrigir a regra e repetir a prova
Quando um teste falha, conserva o caso que revelou o problema e confirma a correção com a mesma tentativa. Volta a executar o percurso permitido relacionado. A revisão termina com uma lista clara de resultados e lacunas, para que a equipa saiba o que foi demonstrado e o que ainda exige verificação.
Se uma conta abriu um registo que não devia, o trabalho seguinte é corrigir a autorização e testar novamente esse acesso. Não basta esconder o endereço ou retirar o botão que tornou a falha visível. A regra tem de resistir à mesma tentativa no ponto em que a aplicação decide servir os dados.
Se o teste estava errado, corrige o teste com uma decisão explícita sobre o comportamento pretendido. Pode acontecer que um supervisor deva aceder a ambos os projetos e que a conta escolhida tivesse esse papel. Nesse caso, o resultado revela um problema no ensaio, não necessariamente uma falha da aplicação.
Guarda estes casos para as alterações seguintes. Uma nova exportação, um novo perfil ou uma mudança na forma de guardar documentos pode abrir um caminho que ainda não foi verificado. O conjunto de testes precisa de acompanhar essas mudanças, com casos ligados às regras que continuam relevantes para o negócio.
Este trabalho complementa o processo de testar uma automação antes de a entregar à equipa. A IA ajuda a preparar e executar verificações, mas os resultados precisam de evidência e limites claros. Um relatório útil distingue o que funciona, o que foi recusado corretamente e o que ficou por testar.