Questão de Engenharia de Software — Metodologia de desenvolvimento de software — FUNDATEC 2025
Engenharia de Software›Metodologia de desenvolvimento de software
Código
qg484483
Banca
FUNDATEC
Órgão
UFRGS
Ano
2025
Nível
Médio
Cargo
Técnico em Tecnologia da Informação/Área: Sistemas de Informação
No Behavior-Driven Development (BDD), a linguagem Gherkin é utilizada para descrever cenários de teste de forma compreensível tanto para desenvolvedores quanto para usuários de negócio. Considere o exemplo abaixo:Cenário: Login bem-sucedido Dado que o usuário informou um login e senha válidos Quando o usuário confirma o acesso Então o sistema exibe a página inicialO principal objetivo desse tipo de especificação em Gherkin é:
AEspecificar apenas testes unitários automatizados.
BDocumentar regras de negócio em linguagem acessível a todos os envolvidos.
CSubstituir completamente a codificação da aplicação.
DDescrever exclusivamente cenários técnicos para desenvolvedores.
ERestringir a execução dos testes ao ambiente de homologação.
Revelar gabarito e comentário▾
GabaritoB — Documentar regras de negócio em linguagem acessível a todos os envolvidos.
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”.
Behavior-Driven Development (BDD) - Gherkin
Gabarito: letra B. O principal objetivo do Gherkin é descrever cenários de teste em linguagem natural, compreensível por todos os envolvidos (desenvolvedores, testadores, analistas de negócio), servindo como documentação viva das regras de negócio. Isso é a essência do BDD: alinhar a comunicação entre áreas técnicas e de negócio.
A linguagem Gherkin utiliza palavras-chave como Dado, Quando, Então para estruturar exemplos concretos de comportamento esperado. Diferente de scripts de teste técnicos, o Gherkin é pensado para ser lido e escrito por qualquer stakeholder, promovendo a chamada "linguagem onipresente" (ubiquitous language) do Domain-Driven Design.
Alternativa
Descrição
Correta?
Justificativa
A
Especificar apenas testes unitários automatizados
❌
Gherkin descreve testes de aceitação/funcionais, não unitários; o BDD abrange vários níveis de teste.
B
Documentar regras de negócio em linguagem acessível a todos os envolvidos
✅
Essência do BDD: alinhar comunicação entre áreas técnicas e de negócio com linguagem natural e exemplos concretos.
C
Substituir completamente a codificação da aplicação
❌
Gherkin é apenas para descrever cenários; a implementação real continua sendo codificada em linguagens de programação.
D
Descrever exclusivamente cenários técnicos para desenvolvedores
❌
Gherkin foi criado para ser compreensível também por não desenvolvedores (analistas, clientes), usando termos do domínio do negócio.
E
Restringir a execução dos testes ao ambiente de homologação
❌
Gherkin não define ambiente de execução; os cenários podem ser executados em qualquer ambiente (desenvolvimento, teste, produção).
1Descrever cenário (Gherkin)
2Automatizar steps
3Executar (falha)
4Implementar código
5Executar (passa)
6Refatorar
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Afirma que o Gherkin especifica "apenas testes unitários automatizados". Na verdade, os cenários em Gherkin são testes de aceitação (ou funcionais), não unitários. Eles descrevem o comportamento do sistema do ponto de vista do usuário, e não a lógica interna de uma unidade de código. Além disso, o BDD pode ser aplicado em vários níveis de teste, não só unitário.
Alternativa B — ✅ Correta ⟵ GABARITO
Exatamente: documentar regras de negócio em linguagem acessível a todos os envolvidos. O Gherkin serve como uma especificação executável que todos conseguem entender, eliminando barreiras de comunicação entre times técnicos e de negócio. Cada cenário é um exemplo concreto de uma regra de negócio.
Alternativa C — ❌ Incorreta
Afirma que o Gherkin "substitui completamente a codificação da aplicação". Isso é absurdo: o Gherkin é apenas uma linguagem para descrever cenários; a implementação real (código da aplicação) continua sendo escrita em linguagens de programação tradicionais. O Gherkin alimenta os testes, mas não substitui o desenvolvimento.
Alternativa D — ❌ Incorreta
Afirma que o Gherkin descreve "exclusivamente cenários técnicos para desenvolvedores". Pelo contrário, o Gherkin foi criado para ser compreensível para não desenvolvedores também. A linguagem usa termos do domínio do negócio, não jargões técnicos. Um analista de negócio ou cliente deve ser capaz de ler e validar os cenários.
Alternativa E — ❌ Incorreta
Afirma que o Gherkin "restringe a execução dos testes ao ambiente de homologação". Isso não faz parte do propósito do Gherkin. Os cenários escritos em Gherkin podem ser executados em qualquer ambiente (desenvolvimento, testes, homologação, produção), desde que haja a infraestrutura adequada. A restrição a um único ambiente não é uma característica da linguagem.