Um analista de teste está revisando onde focar esforço adicional de teste em um release. A equipe tem uma base de código madura com grande parte do código inalterada de releases anteriores, e um pequeno conjunto de novas mudanças. Conforme o syllabus, qual método analítico é mais apropriado para focar esforço adicional em áreas propensas a erro?

1. A. Apenas análise de cobertura estrutural, visando todas as áreas de baixa cobertura igualmente independentemente do histórico de mudança, o que é o oposto da análise de lacuna de teste — a análise de lacuna de teste foca em mudanças recentes de código que não foram testadas, em vez de em todas as áreas de baixa cobertura incluindo código estável testado em releases anteriores 💬 A
2. B. Teste aleatório de toda a base de código, selecionando entradas arbitrariamente sem considerar quais áreas mudaram ou quais áreas são propensas a erro — mas isso não é análise de lacuna de teste, que avalia especificamente até que ponto os testes exercitaram mudanças recentes de código para focar esforço adicional em mudanças novas e não testadas em vez de em todas as áreas de baixa cobertura incluindo código estável testado em releases anteriores 💬 B
3. C. Análise de padrão de chegada de defeitos usando o modelo de Rayleigh, que prevê e analisa a taxa na qual defeitos são detectados ao longo do tempo — mas isso é um método analítico diferente da análise de lacuna de teste, que avalia até que ponto mudanças recentes de código foram exercitadas por testes 💬 C
4. D. Análise de lacuna de teste, que avalia até que ponto os testes exercitaram mudanças recentes de código, permitindo ao TA focar esforço adicional em áreas especialmente propensas a erro (ou seja, novas mudanças que não foram testadas) em vez de visar todas as áreas que têm baixa cobertura (ex.: código que não mudou há muito tempo e foi testado em releases anteriores) ✓ D

Revelar gabarito

Resposta correta: Análise de lacuna de teste, que avalia até que ponto os testes exercitaram mudanças recentes de código, permitindo ao TA focar esforço adicional em áreas especialmente propensas a erro (ou seja, novas mudanças que não foram testadas) em vez de visar todas as áreas que têm baixa cobertura (ex.: código que não mudou há muito tempo e foi testado em releases anteriores)

Referência: https://istqb.org/wp-content/uploads/sdm-uploads/ISTQB-CTAL-TA-Syllabus-v4.0-EN-4.pdf