Questão de Engenharia de Software — Geral — FCC 2025
Engenharia de Software›Geral
Código
fc150550
Banca
FCC
Órgão
CGE PI
Ano
2025
Cargo
Aud Gov ( )
Em um projeto de desenvolvimento de um novo sistema de orçamento eletrônico para uso das secretarias de estado, uma Secretaria da Fazenda aplica abordagens de teste de software, a utilização de documentos de teste e a avaliação da qualidade em diferentes ambientes. A mais adequada abordagem que representa a aplicação desses conceitos é
Aimplementar um processo de revisão de código rigoroso por pares para identificar e corrigir potenciais falhas de lógica antes da fase de testes, considerando que essa prática é a única que pode garantir a qualidade do software em todos os ambientes.
Brealizar testes pontuais ao final do desenvolvimento, focando na verificação das funcionalidades principais em um ambiente de produção simulado, utilizando um checklist de requisitos e o plano descritivo de software (SDP) produzido na etapa de conclusão.
Celaborar um Plano de Testes detalhado que define o escopo, os objetivos, os recursos e o cronograma dos testes. Em seguida, criar Casos de Teste específicos para cada funcionalidade, executar esses testes em ambientes de desenvolvimento, homologação e produção, e registrar todos os defeitos encontrados em Relatórios de Defeitos padronizados para acompanhamento e correção.
Ddesignar uma equipe de usuários finais para interagir com o sistema em um ambiente de prototipagem, coletando feedback de acordo com o documento de requisitos funcionais (FRD) sobre a usabilidade e reportando os problemas encontrados referentes a tempo de resposta, segurança nos logins e outros correlatos.
Eutilizar testes automatizados de unidade para garantir que cada componente individual do sistema funcione corretamente, em diferentes ambientes, e correspondentes interfaces com as demais unidades desenvolvidas.
Revelar gabarito e comentário▾
GabaritoC — elaborar um Plano de Testes detalhado que define o escopo, os objetivos, os recursos e o cronograma dos testes. Em seguida, criar Casos de Teste específicos para cada funcionalidade, executar esses testes em ambientes de desenvolvimento, homologação e produção, e registrar todos os defeitos encontrados em Relatórios de Defeitos padronizados para acompanhamento e correção.
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”.
Teste de Software: Plano de Testes, Casos de Teste e Relatórios de Defeitos
Gabarito: letra C. A alternativa C descreve o processo completo e estruturado de teste de software: elaboração de um Plano de Testes (escopo, objetivos, recursos, cronograma), criação de Casos de Teste específicos, execução em diferentes ambientes (desenvolvimento, homologação, produção) e registro de defeitos em Relatórios de Defeitos padronizados. Essa é a abordagem mais adequada porque integra planejamento, execução e gestão de defeitos, alinhada às boas práticas da engenharia de software.
O teste de software é um processo sistemático que visa encontrar defeitos e avaliar a qualidade do produto em relação ao contexto em que deve operar. Ele não é uma atividade isolada, mas permeia todo o ciclo de desenvolvimento, desde o levantamento de requisitos até a manutenção. A norma ISO 9126 define atributos de qualidade como funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade, que orientam o que deve ser testado.
A abordagem correta envolve três documentos essenciais: o Plano de Testes, que define o escopo, os objetivos, os recursos e o cronograma; os Casos de Teste, que especificam as condições de entrada, os passos de execução e os resultados esperados para cada funcionalidade; e os Relatórios de Defeitos, que registram os problemas encontrados para acompanhamento e correção. A execução em múltiplos ambientes (desenvolvimento, homologação e produção) é fundamental para validar o software em condições cada vez mais próximas do uso real.
A alternativa C é a única que abrange todo esse ciclo de forma integrada. As demais alternativas apresentam abordagens parciais ou equivocadas: a revisão de código é importante, mas não é a única garantia de qualidade; testes pontuais ao final não substituem um plano estruturado; o feedback de usuários é valioso, mas não cobre todos os aspectos técnicos; e testes de unidade automatizados são apenas um nível de teste, não a abordagem completa.
A pegadinha da banca está em apresentar alternativas que contêm elementos válidos de teste (revisão de código, testes pontuais, feedback de usuários, testes de unidade), mas que não representam a abordagem mais adequada e completa. O candidato deve identificar qual alternativa descreve o processo de teste como um todo, com planejamento, execução e gestão de defeitos.
1Plano de Testes
2Casos de Teste
3Execução em ambientes
4Relatórios de Defeitos
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
A revisão de código por pares é uma prática valiosa de garantia de qualidade, mas a alternativa afirma que ela é a única que pode garantir a qualidade do software, o que é uma generalização indevida. A qualidade é alcançada por um conjunto de práticas, incluindo testes, revisões, análise estática e dinâmica, entre outras. Além disso, a revisão de código não substitui a execução de testes em diferentes ambientes.
Alternativa B — ❌ Incorreta
Realizar testes pontuais ao final do desenvolvimento, focando apenas nas funcionalidades principais, é uma abordagem insuficiente. O teste deve ser planejado e executado ao longo de todo o ciclo de desenvolvimento, não apenas no final. Além disso, o Plano Descritivo de Software (SDP) é um documento de projeto, não um documento de teste, e a execução em ambiente de produção simulado não substitui a execução em ambientes controlados de desenvolvimento e homologação.
Alternativa C — ✅ Correta ⟵ GABARITO
Esta alternativa descreve o processo completo e estruturado de teste de software: elaboração de um Plano de Testes detalhado (escopo, objetivos, recursos, cronograma), criação de Casos de Teste específicos para cada funcionalidade, execução em ambientes de desenvolvimento, homologação e produção, e registro de defeitos em Relatórios de Defeitos padronizados. Essa é a abordagem mais adequada porque integra planejamento, execução e gestão de defeitos, seguindo as boas práticas da engenharia de software.
Alternativa D — ❌ Incorreta
Designar uma equipe de usuários finais para interagir com o sistema em um ambiente de prototipagem e coletar feedback é uma prática de validação de usabilidade, mas não representa a abordagem completa de teste de software. O feedback de usuários é importante, mas não cobre todos os aspectos técnicos, como testes de integração, desempenho, segurança e regressão. Além disso, o ambiente de prototipagem não é o mesmo que os ambientes de desenvolvimento, homologação e produção.
Alternativa E — ❌ Incorreta
Testes automatizados de unidade são um nível importante de teste, mas a alternativa afirma que eles garantem que cada componente individual funcione corretamente em diferentes ambientes, o que é uma visão limitada. Testes de unidade verificam componentes isoladamente, mas não cobrem a integração entre eles, nem os testes de sistema, aceitação e regressão. A abordagem completa requer múltiplos níveis e tipos de teste.