Especificação por exemplo (SBE) - eTecnologia/projeto-genesis GitHub Wiki

Requisitos por Exemplo (SBE)

Segundo F. Brooks “A parte mais árdua na construção de um software consiste exatamente em identificar o que construir. Nenhuma outra parte do trabalho compromete tanto o resultado do trabalho se elaborado de forma incorreta. Nenhuma outra parte oferece tanta dificuldade para efetuar correções posteriores."
Um entendimento dos requisitos de software é essencial para o sucesso do desenvolvimento do software. Não importa quão bem projetado ou quão bem codificado seja, um software mal analisado e especificado frustrará o usuário.

Exisem muitas forma de fazer a especificação de requisitos de software, um delas é a Especificação Por Exemplo (SBE - Specificafiont by Example).
SBE é uma abordagem colaborativa para definir requisitos e testes funcionais orientados a negócios para produtos de software com base na captura de requisitos usando exemplos realistas em vez de instruções abstratas. É aplicado no contexto de métodos ágeis de desenvolvimento de software, em particular no desenvolvimento orientado a comportamento (BDD).
Essa abordagem é bem-sucedida para gerenciar requisitos e testes funcionais em projetos de grande escala de domínio significativo e complexidade organizacional. [1]
A especificação por exemplo também é conhecida como desenvolvimento orientado a exemplos, requisitos executáveis, desenvolvimento orientado a testes de aceitação (ATDD [2] ou A-TDD [3] ), teste de aceitação ágil, [4] requisitos orientados a testes (TDR).

Vantagens Novos conceitos altamente abstratos ou novos podem ser difíceis de entender sem exemplos concretos. [ citação necessária ] A especificação por exemplo destina-se a construir um entendimento preciso e reduz significativamente os ciclos de feedback no desenvolvimento de software, levando a menos retrabalho, maior qualidade do produto, tempo de resposta mais rápido para mudanças de software e melhor alinhamento das atividades de vários papéis envolvidos no software como testadores, analistas e desenvolvedores. [1]
Exemplos como uma única fonte de verdade Um aspecto chave da especificação por exemplo é criar uma única fonte de verdade sobre as mudanças necessárias de todas as perspectivas. Quando os analistas de negócios trabalham em seus próprios documentos, os desenvolvedores de software mantêm sua própria documentação e os testadores mantêm um conjunto separado de testes funcionais, entrega de softwarea eficácia é significativamente reduzida pela necessidade de coordenar e sincronizar constantemente essas diferentes versões da verdade. Com ciclos iterativos curtos, essa coordenação geralmente é necessária semanalmente ou quinzenalmente. Com a Especificação por exemplo, diferentes funções participam na criação de uma única fonte de verdade que captura a compreensão de todos. Exemplos são usados ​​para fornecer clareza e precisão, para que a mesma informação possa ser usada tanto como especificaçãoe um teste funcional orientado para o negócio. Qualquer informação adicional descoberta durante o desenvolvimento ou entrega, como esclarecimento de lacunas funcionais, requisitos ausentes ou incompletos ou testes adicionais, é adicionada a essa única fonte de verdade. Como há apenas uma fonte de verdade sobre a funcionalidade, não há necessidade de coordenação, tradução e interpretação do conhecimento dentro do ciclo de entrega.
Quando aplicado às mudanças necessárias, um conjunto refinado de exemplos é efetivamente uma especificação e um teste orientado ao negócio para aceitação da funcionalidade do software. Depois que a mudança é implementada, a especificação com exemplos se torna um documento explicando a funcionalidade existente. Como a validação desses documentos é automatizada, quando são validados com frequência, esses documentos são uma fonte confiável de informações sobre a funcionalidade de negócios do software subjacente. Para distinguir esses documentos da documentação impressa típica, que rapidamente fica desatualizada, [4] um conjunto completo de especificações com exemplos é chamado de Documentação Viva. [1]
Principais práticas
As equipes que aplicam a Especificação por exemplo com sucesso geralmente aplicam os seguintes padrões de processo: [1]
Derivando o escopo das metas Especificar de forma colaborativa - por meio de workshops de especificação de toda a equipe, reuniões menores ou revisões por teleconferência Ilustrando requisitos usando exemplos Especificações de refinamento Automatizando testes com base em exemplos Validar o software subjacente com frequência usando os testes Evoluindo um sistema de documentação a partir de especificações com exemplos para apoiar o desenvolvimento futuro As equipes de software que aplicam a especificação por exemplo dentro de uma estrutura Scrum normalmente gastam de 5% a 10% de seu tempo refinando o backlog do produto, incluindo a especificação colaborativa, ilustrando requisitos usando exemplos e refinando exemplos. [3]
Mapeamento de exemplo
O mapeamento de exemplo é uma técnica simples que pode orientar a conversa e derivar critérios de aceitação em pouco tempo. O processo divide as histórias em Regras e Exemplos documentados na forma de especificação por exemplo, e é uma técnica amplamente utilizada na esfera BDD. [5]

Aplicabilidade
A especificação por exemplo se aplica a projetos com complexidade organizacional e de domínio suficiente para causar problemas na compreensão ou comunicação de requisitos de uma perspectiva de domínio de negócios. Não se aplica a problemas puramente técnicos ou onde a complexidade chave não está na compreensão ou comunicação do conhecimento. Existem usos documentados dessa abordagem em domínios, incluindo banco de investimento, negociação financeira, seguros, reserva de passagens aéreas, jogos on-line e comparação de preços. [1] Uma abordagem semelhante também está documentada em um projeto de simulação de usina nuclear. [3]

Testes baseados em exemplos compartilhados se encaixam melhor na categoria de testes projetados para dar suporte a uma equipe enquanto entregam software de uma perspectiva de negócios (consulte Agile Testing Quadrants [6] ) - garantindo que o produto certo seja construído. Eles não substituem os testes que analisam um sistema de software de uma perspectiva puramente técnica (aqueles que avaliam se um produto é construído da maneira correta, como testes de unidade, componentes ou testes de integração técnica) ou testes que avaliam um produto depois de desenvolvido (como testes de penetração de segurança).

História
O uso documentado mais antigo de exemplos realistas como uma única fonte de verdade, requisitos e testes automatizados em projetos de software é o projeto WyCash+, descrito por Ward Cunningham no artigo A Pattern Language of Competitive Development [7] [8] em 1996. name Specification by Example foi cunhado por Martin Fowler em 2004. [9]

A especificação por exemplo é uma evolução da prática Customer Test [10] de Extreme Programming proposta por volta de 1997 e a ideia da Ubiquitous Language [11] do design orientado a domínio de 2004, usando a ideia de testes de caixa preta como requisitos descritos por Weinberg e Gause [12] em 1989.

Automação
A aplicação bem-sucedida da especificação por exemplo em projetos de grande escala requer validação frequente da funcionalidade do software em relação a um grande conjunto de exemplos (testes). Na prática, isso requer que testes baseados em exemplos sejam automatizados. Uma abordagem comum é automatizar os testes, mas manter os exemplos em um formato legível e acessível para membros não técnicos e técnicos da equipe, mantendo os exemplos como uma única fonte de verdade. Este processo é suportado por uma classe de ferramentas de automação de testes que trabalham com testes divididos em dois aspectos - a especificação e a camada de automação. A especificação de um teste que geralmente está em um formato de texto simples ou HTML e contém os exemplos e descrições auxiliares. A camada de automação conecta o exemplo a um sistema de software em teste.

Exemplos de tais ferramentas são:
Concordion
Cucumber
FitNesse
Robot Framework
SpecFlow for .NET
Gauge (software)


Livros de Referência

Fonte:
https://en.wikipedia.org/wiki/Specification_by_example

⚠️ **GitHub.com Fallback** ⚠️