Conceito e mecanismo
Um teste útil responde a uma pergunta sobre um risco concreto. Num portal de operações, confirmar que o botão de aprovação aparece não demonstra que a autorização é aplicada no servidor. Um teste de API pode verificar a regra mais diretamente; um percurso completo acrescenta evidência de que a interface, a identidade e o serviço funcionam em conjunto. A escolha depende da falha que se pretende detetar e do custo de obter uma resposta interpretável. Antes de aumentar a suite, lista os comportamentos alterados, as dependências e os efeitos que seriam difíceis de reverter. Escolhe algumas verificações rápidas e outras que atravessem fronteiras relevantes. Não existe uma proporção universal de testes que garanta cobertura adequada.
Aplicação guiada
Considera uma alteração ao arredondamento de comissões. Testar apenas o ecrã alterado deixa por observar o ficheiro exportado e a reconciliação que usa o mesmo cálculo. Inclui valores nas fronteiras, resultados conhecidos e um percurso representativo até ao consumidor. Se houver uma janela curta, justifica a seleção por impacto e identifica o que não foi exercitado. Mantém testes repetíveis para regras acordadas e reserva exploração para comportamentos inesperados. Uma falha no percurso completo pede diagnóstico por etapas; não prova, por si só, que o último componente alterado é responsável. O resumo para a decisão de release deve ligar cada risco à evidência obtida e indicar limitações de ambiente ou dados.
Uma regra partilhada pode afetar API, exportação e reconciliação.
Armadilhas comuns
Ecrã verde como prova global; cobertura contada sem risco; culpar a última mudança.
Tópicos relacionados: Equipa, feedback e especialistas · Plano, métricas e melhoria · Exemplos, critérios e pequenas entregas
Relaciona risco, nível de teste e limite da conclusão.
Referência: Using the Agile Testing Quadrants · CTAL-AT v2.0 (2026)