APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Antes de escolher uma ferramenta, identifica a pergunta que precisa de resposta e a frequência com que essa resposta será necessária. Uma equipa pode querer detetar alterações incompatíveis numa API antes de integrar serviços; outra precisa de confirmar que um operador consegue concluir um percurso no browser. As duas necessidades podem justificar mecanismos diferentes. O sistema sob teste, ou SUT, é o objeto investigado. A solução de automação inclui código de testes, bibliotecas, dados, ambientes, configuração e relatórios que produzem evidência sobre esse objeto. Confundir os dois dificulta o diagnóstico: uma falha na preparação do ambiente de teste não demonstra automaticamente um defeito no produto.
Aplicação guiada
Num projeto fictício de reconciliação, a regra de cálculo é estável, mas os ecrãs mudam todas as semanas. Verificar todas as combinações através da interface pode tornar a manutenção dominante. Considera testar a regra num nível com acesso direto e reservar percursos de interface para riscos de interação e integração. Confirma que a equipa consegue manter o código e interpretar falhas durante a transição para APS. A automação pode repetir verificações rapidamente e apoiar preparação de dados, mas não elimina investigação humana nem decide sozinha que risco o negócio aceita. Regista limitações e custos recorrentes, incluindo atualização de dependências, diagnóstico de falsos alarmes e adaptação a novas versões do produto.
Uma falha do executor pode impedir o teste sem demonstrar falha do SUT.
Armadilhas comuns
Ferramenta antes do objetivo; toda a lógica pela interface; confundir infraestrutura e produto.
Tópicos relacionados: Testabilidade e avaliação de ferramentas · Arquitetura, camadas e dados · Piloto, fixtures e manutenção
Define a evidência necessária e o seu âmbito.
Referência: ISTQB CTAL-TAE syllabus · CTAL-TAE v2.0 (2024)