← ISTQB Foundation: testes e decisões de qualidade
08 / 8 · 60 MIN

Esforço, prioridades e evidência de release

Estima esforço com pressupostos, ordena testes com dependências e comunica resultados sem ocultar risco residual.

Usar risco como critério explícito

Uma matriz didática atribui pontuações a probabilidade e impacto, definindo nível como o produto das duas. Um risco com 3×5 recebe 15 e outro com 4×2 recebe 8. Isso suporta uma ordenação segundo a escala acordada; não representa automaticamente euros perdidos ou uma probabilidade percentual. Discute as consequências concretas, a qualidade da evidência e as limitações da escala. Num contexto de suporte, uma falha rara de fecho pode ter impacto elevado. A visibilidade de um problema estético não determina sozinha o tratamento. Regista separadamente severidade do defeito e prioridade de correção, explicando as razões da decisão.

Calcular esforço sem prometer duração

Para uma tarefa, as estimativas são quatro horas-pessoa no cenário otimista, sete no mais provável e dezasseis no pessimista. Aplicando E=(a+4m+b)/6, obténs oito horas-pessoa. A medida (b-a)/6 dá dois, mas não deve ser apresentada como garantia de que a tarefa termina entre seis e dez horas. O cálculo depende das estimativas e do modelo. Esforço também não equivale a duração: duas pessoas não garantem terminar em quatro horas se houver dependências, espera ou um ambiente partilhado. Decompõe o trabalho e explicita disponibilidade e precedências antes de converter uma estimativa de esforço numa previsão de calendário.

Verificar a comparação usada numa estimativa histórica

Uma organização observou razão de esforço desenvolvimento:testes de 5:2 em projetos comparáveis. Se desenvolvimento estima 150 dias-pessoa, a estimativa de testes é 150×2/5=60 dias-pessoa. O total combinado seria 210, mas não é isso que se deve apresentar como esforço de testes. A razão não é uma norma universal. Compara tecnologia, automação, criticidade, experiência, reutilização e definição das atividades incluídas. Se o projeto novo exige validação de recuperação antes inexistente, a analogia pode subestimar esforço. Regista pressupostos e revê a estimativa com observações reais, mantendo as unidades e o âmbito consistentes ao longo do reporte.

Priorizar cobertura nova respeitando dependências

Se R1,R2,R3 já foram cobertos, um teste que cobre R1,R2 acrescenta zero itens; outro que cobre R3,R4,R5 acrescenta dois. Com duração igual e sem dependências, o segundo vem primeiro quando o critério escolhido é cobertura adicional. Outro critério pode ser apropriado se riscos ou restrições forem diferentes. Um teste de risco elevado pode depender de preparação com prioridade nominal inferior; executa a preparação necessária antes dele. Não confundas prioridade com uma ordem impossível de executar. Na janela disponível, considera ambientes, dados, pessoas e sequência para que os resultados correspondam às condições que se pretende avaliar.

Reportar denominadores e preservar falhas iniciais

De cem testes planeados, 72 passaram, oito falharam e vinte não foram executados. A execução é 80%, o sucesso entre executados é 90% e os aprovados representam 72% do plano. Nenhuma dessas métricas explica sozinha risco residual. Mostra que requisitos e riscos estão ligados às falhas e omissões. Se a pipeline fica verde apenas depois de retries, conserva os resultados iniciais e investiga sincronização, dados e ambiente. Dez falhas em cem primeiras execuções não demonstram uma taxa de 10% de falhas em produção. População, condições e causas são diferentes e precisam de análise.

Preparar uma decisão de release com evidência limitada

Uma versão desconhecida da API compromete a interpretação de um teste de integração, mesmo que o calendário mande começar. Torna visíveis os critérios de entrada em falta e resolve-os ou acorda limitações explicitamente. No fim, compara critérios de saída e resultados. Se o teste de failover principal não foi executado, identifica o risco, as consequências, as opções e quem pode aceitar a exposição residual. Não transformes ausência de teste em aprovação, nem um documento de rollback em recuperação comprovada. O relatório ajuda os responsáveis a decidir; não lhes retira autoridade nem cria uma garantia que os testes não suportam.

NA PRÁTICA

Com 72 passados, oito falhados e vinte pendentes, apresenta execução 80%, sucesso nos executados 90% e cobertura do risco crítico separadamente. Explica por que o teste de failover em falta altera a recomendação.

Armadilhas comuns

Converter horas-pessoa diretamente em duração; inverter rácios; apresentar sucesso só dos executados sem omissões; esconder retries; confundir severidade com prioridade ou percentagem verde com probabilidade de release segura.

Tópicos relacionados: Risco e release · Ferramentas e sinal

Leva esta ideia contigo

Uma recomendação útil combina resultados, lacunas e consequências. Estimativas e percentagens devem ter pressupostos e denominadores claros para apoiar uma decisão responsável.

Criar conta

Referência: ISTQB CTFL syllabus v4.0.1 · CTFL v4.0; syllabus v4.0.1 (2024-09-15)

ISTQB® é uma marca registada de International Software Testing Qualifications Board. A dr.pt é uma plataforma de preparação independente e não está afiliada, associada, patrocinada, autorizada nem aprovada por ISTQB. Os conteúdos e as perguntas são originais, não são perguntas oficiais de exame, e concluir os nossos testes não atribui nem garante qualquer certificação. Os nomes são usados apenas para identificar o tema. Todas as outras marcas pertencem aos respetivos titulares.