Pular para o conteúdo principal

Questão de Engenharia de Software — Teste de Software — FUNDATEC 2023

Engenharia de SoftwareTeste de Software
Código
qq897246
Banca
FUNDATEC
Órgão
PROCERGS
Ano
2023
Nível
Superior
Cargo
ANC - Analista em Computação - Ênfase em Teste de Software e Garantia da Qualidade
A análise de risco em projetos de teste de software, embora tenha suas características próprias, deve seguir as mesmas regras e metodologias aplicadas a projetos de software em geral. O risco é um dos elementos mais importantes a ser trabalhado no momento de se elaborar o projeto de teste de um software. Portanto, ao preparar o plano de teste e fazer a análise de riscos e definir a cobertura de testes, devemos levar em conta alguns elementos, que são:
  1. ASe existe risco evidente ou não e se há necessidade de mapear o mesmo no plano.
  2. BProbabilidade de ocorrência do risco e o impacto e a perda associada a esse risco.
  3. CRiscos são mapeados pelo analista na especificação e não são considerados no plano de teste.
  4. DMapear a probabilidade de ocorrência do risco e, se menor que 40%, não considerar.
  5. EAvaliar o impacto do risco levantado pelo gerente de projetos na execução de testes.
Revelar gabarito e comentário

GabaritoB — Probabilidade de ocorrência do risco e o impacto e a perda associada a esse risco.

Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.

Análise de riscos em projetos de teste de software

Gabarito: letra B. Em projetos de teste, a análise de riscos deve considerar os dois componentes fundamentais do risco: a probabilidade de ocorrência e o impacto (ou perda) associado. Essa definição é universal em gerenciamento de riscos, inclusive em teste de software. A alternativa B captura exatamente esses dois elementos.

A questão cobra o conhecimento básico de que risco é uma função de probabilidade e impacto (Risco = Probabilidade × Impacto). No contexto de teste, isso orienta onde concentrar esforços: áreas com alta probabilidade e alto impacto merecem mais atenção.

Alternativa A — ❌ Incorreta

Afirma que se deve levar em conta apenas “se existe risco evidente ou não e se há necessidade de mapear”. Reduz a análise a uma decisão binária, ignorando a graduação do risco (probabilidade e impacto). Mapear riscos é necessário, mas a intensidade é crucial.

Alternativa B — ✅ Correta ⟵ GABARITO

Explicitamente menciona “probabilidade de ocorrência do risco e o impacto e a perda associada a esse risco”. Essa combinação é o núcleo da gestão de riscos: sem medir essas duas dimensões, não é possível priorizar adequadamente as ações de teste.

Alternativa C — ❌ Incorreta

Diz que “riscos são mapeados pelo analista na especificação e não são considerados no plano de teste”. Isso é o oposto do correto: os riscos devem ser considerados no plano de teste para direcionar a estratégia e a alocação de recursos. Ignorá-los no plano compromete a eficácia dos testes.

Alternativa D — ❌ Incorreta

Sugere mapear a probabilidade e, se menor que 40%, não considerar. Não há fundamento para esse limiar arbitrário. A decisão de desconsiderar um risco deve levar em conta também o impacto; um risco de baixa probabilidade mas altíssimo impacto pode ser crítico (ex.: falha catastrófica). O corte de 40% é inventado e não reflete a prática.

Alternativa E — ❌ Incorreta

Limita a análise a “avaliar o impacto do risco levantado pelo gerente de projetos na execução de testes”. Ignora a probabilidade e restringe a fonte do risco ao gerente de projetos, quando na verdade riscos podem ser identificados por qualquer stakeholder (analistas, testadores, clientes). A análise completa deve incluir ambos os fatores e considerar múltiplas fontes.

NÃO CAIA NESSA!

A banca explora a tentação de aceitar regras simplistas ou parciais. Letras A, D e E apresentam versões incompletas ou com limiares arbitrários. A correta (B) é a única que menciona probabilidade + impacto/perda, que são os dois eixos fundamentais do risco.

Conclusão: Risco em teste de software é definido por probabilidade e impacto. A alternativa B é a única que abrange ambos os elementos corretamente.

Link permanente: /questoes/qq897246