APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Uma revisão técnica ganha valor quando os participantes chegam com perguntas concretas e conhecem os contratos envolvidos. Num serviço que abre uma ligação à base de dados, executa uma operação e devolve resposta, investiga também o caminho de erro: a ligação é devolvida ao pool quando ocorre uma exceção? A revisão de código pode seguir recursos, valores e saídas sem esperar que uma fuga cause incidente. Uma checklist orienta atenção, mas não substitui compreender o programa. Adapta-a à linguagem e ao histórico do produto, registando observações com localização, mecanismo e consequência. Evita recomendações universais como nunca comparar valores decimais: o tipo numérico e a regra determinam a comparação apropriada.
Aplicação guiada
Na arquitetura, segue dependências partilhadas e limites de concorrência. Duas instâncias com caches separados podem devolver versões diferentes se a invalidação não acompanha uma atualização. Aumentar o pool de cada instância pode exceder o limite total de ligações da base de dados. Uma fila sem capacidade ou política de expiração definida pode transformar um pico curto num atraso prolongado. Discute estas hipóteses com os autores e converte-as em decisões ou testes específicos, sem assumir que uma observação prova automaticamente um defeito. Para APS, inclui diagnóstico e recuperação: que identificador liga pedido, registo e efeito, e como se distingue um pedido falhado de um pedido concluído cuja resposta se perdeu? Conserva as respostas na documentação utilizada pela equipa.
Quatro instâncias com pools de 40 podem pedir 160 ligações a uma base limitada a 120.
Armadilhas comuns
Checklist sem contexto; pool isolado como capacidade global; observação como culpa.
Tópicos relacionados: Risco técnico e evidência operacional · Cobertura lógica white-box · Análise estática e dinâmica
Segue recursos e dependências nos caminhos de sucesso e erro.
Referência: ISTQB CTAL-TTA syllabus · CTAL-TTA v4.0 (2021)