Specificationby example

Terminologia e Definição
O termoSpecificationbyExample (Especificação por Exemplos) surgiu segundo seu criador
GojkoAdzik (2011) com o intuíto de unificar em um só termo as seguintes técnicas,
metodologias e práticas ágeis:
● Agileacceptancetesting
● Test-DrivenDevelopment
● Acceptance Test-DrivenDevelopment
● Example-DrivenDevelopment
● Storytesting
● Behavior-DrivenDevelopment
Segundo Gojko o fato de as mesmas práticas possuírem tantos nomes diferentes reflete o grande
número de inovações nesse campo no cenário atual da industria de software. Sobre essas
diferentes nomenclaturas Gojko afirma:
Se queremos os usuários finais (stakeholders) mais envolvidos, o que é o principal objetivo dessas práticas,
precisamos usar os nomes corretos para as coisas corretas e parar de confundir as pessoas. [Ver como
referenciar]
O autor decidiu por tanto simplificar essa terminologia na comunidade de software para que as
pessoas possam usufruir de seus benefícios sem entrarem em discuções improdutivas sobre
terminologias.
SpecificationbyExample é o resultado de um conjunto de estudos de caso realizados por Gojko
com mais de 50 projetos de desenvolvimento de software do mundo real. Projetos que variam em
tecnologia (de websites a softwares para desktop) e em metodologias (Extreme Programing,
Scrum, Kanban e outras metodologias normalmente agrupadas sobre os termos agilee lean).
SpecificationbyExample pode ser definido como um suplemento de práticas que podem ser
incorporadas a qualquer metodologia de desenvolvimento atual.
Necessidade
Construir o produto certo e construir certo o produto são dois objetivos distindos. Porém os dois
são necessários para se obter sucesso. Segundo Gojko tradicionalmente, construir o produto certo
requeria enormes especificações funcionais, documentação e longos ciclos de teste, atualmente
em um mundo de releases semanais isso não funciona. Ainda segundo Gjko é necessário uma
solução para:
● Evitar super-especificações inúteis; Evitar gastar tempo em detalhes que mudarão antes
do primeiro fragmento de trabalho ser desenvolvido.

● Ter documentos legíveis que explicam oque o sistema faz para que se posso modificá-lo
facilmente.
● Checar de maneira eficiente que o sistema faz o que as especificações dizem.
● Manter a documentação relevante e confiável com o menor custo de manutenção.
● Colocar tudo isso em processos baseados em iterações, de forma que a informação do
trabalho a ser feito é produzida sob demanda.
Figura 1.1 Fatores-chave para a documentação correta em times ágeis.
SpecificationbyExample unificou padrões e processos que times do mundo real utilizaram para
atingir esses objetivos.
Padrões de processo
Os padrões estabelecidos por SpecificationbyExample são assim denominados no sentido em que
eles são elementos recorrentes usados por diferentes times; São resultados de uma série de
experimentos empíricos com projetos e times reais e não de um modelo teórico de elaboração de
processos.

Figura 1.2 Principais padrões de processo de SpecificationbyExample.
1. Derivingscopefromgoals (Derivando o escopo dos objetivos): Nessa etapa a equipe que criará
o software deve derivar os escopos de desenvolvimento a partir dos objetivos estabelecidos pelos
stakeholders. Segundo Gojko é um erro esperar que os usuários envolvidos digam qual o escopo
de desenvolvimento pois os mesmos não são designers de software. O mais apropriado nessa
etapa é elencar os objetivos que os stakeholdersquerem atingir com o software em questão. Em
outras palavras, qual ou quais os problemas que a “solução” deve ser capaz de resolver. Começa-
se com um objetivo de negócios o time de desenvolvimento colabora definindo o escopo que vai
atingir este objetivo.
2. Specifyingcollaboratively (Especificando colaborativamente):O time nesse etapa deverá
juntamente com os stakeholders especificar colaborativamente o comportamento esperado para
cada funcionalidade do escopo. Desenvolvedores, testadores e analista de negócios devem
participar nessa etapa pois cada um tem um contexto único e habilidades que podem ajudar a
resolver questões que de outra forma poderiam passar desapercebidas gerando re-trabalho no
futuro.

3. Illustratingusingexamples (Ilustrando utilizando exemplos): Ao invés de esperar que as
especificações sejam expressadas precisamente em uma linguagem de programação durante a
implementação, deve-se ilustrar o comportamento esperado do sistema utilizando exemplos
antes do desenvolvimento ser iniciado. O time de desenvolvimento trabalha com os
stakeholderspara identificar exemplos-chave que descrevem a funcionalidade esperada.
Desenvolvedores e testadores dão exemplos adicionais que revelam áreas antes ignoradas da
funcionalidade evitando assim gaps funcionais e faz com que todos tenham um conhecimento
distribuído sobre aquilo que precisam entregar.
4. Refiningthespecification (Refinando a especificação): Nessa etapa o time de desenvolvimento
deve remover informações irrelevantes dos exemplos tais como detalhes que tornam os exemplos
extensos e verbosos sem adicionar informações úteis. Segundo Gjko deve-se identificar o que o
software deve fazer e não detalhar o como fazer. Os resultados dessa etapa podem ser
considerados critérios de aceitação, que ao mesmo tempo são especificações para o
desenvolvimento e futuramente quando automatizados farão parte dos testes de regressão.
5. Automatingvalidationwithoutchangingspecifications (Automatizando as validações sem
modificar as especificações): Com os exemplos especificados e refinados o time pode usá-los
como meio de validar o produto. O sistema será validado diversas vezes durante o
desenvolvimento para assegurar que o mesmo atinge os objetivos. Rodar essas validações
manualmente introduziria um delay desnecessário e o feedback seria lento. A solução para isto é
automatizar as validações, porém essa automação deve também ser acessível aos stakeholders e
não deve modificar as especificações originais. O time de desenvolvimento literalmente deve
escrever a automação com as mesmas palavras utilizadas para criarem os exemplos, pois scripts
e código fonte não têm a capacidadade de contar expressar adequadamente o contexto de negócio
em que estão inseridos e documentação puramente textual fica desatualizada rapidamente.
Portanto nessa etapa a validação automática do sistema, suas especificações por exemplos e seus
critérios de aceitação tornam-se um só. O resultado dessa etapa gera especificações executáveis.
6. ValidatingFrequently (Validando frequentemente): Gjko afirma que a documentação
tradicional de software fica desatualizada antes mesmo de o sistema ser lançado. A validação
frequente é um produto das especificações executáveis ela sincroniza o que foi especificado com
o que o sistema realmente está fazendo.
7. Evolving a documentation system (Evolução de um sistema de documentação): Nessa etapa o
time de desenvolvimento mantém a documentação viva (especificações executáveis - testes)
atualizada com as modificações requisitadas pelos stakeholders para incrementar o software. As
especificações e testes estando em um mesmo lugar facilitam essa mudança pois concentram os
esforços em apenas uma fonte de informações. Desenvolvedores utilizam essa documentação

como especificações, testadores utilizam como testes e os analistas de negócio utilizam para
avaliar o impácto que uma mudança ou especificação futura pode ter no sistema.
[Continuar … páginas 20 a 24 do capítulo 2 de SpecificationbyExample]
Specificationbyexample propõe um processo com padrões definidos onde o
comportamento de uma funcionalidade desejada para um dado sistema é especificada usando-
se exemplos reais, esses exemplos após, refinados guiam o desenvolvimento e tornam-se
testes que asseguram que a especificação foi implementada conforme os exemplos a
descreviam e mais tarde os mesmos exemplos tornam-se a documentação da funcionalidade.
Os exemplos por tanto são ao mesmo tempo os requisitos, os testes e a documentação de cada
funcionalidade existente no sistema.
<citação> Ao invés de esperar que as especificações (requisitos) sejam escritas de
forma precisa em uma linguagem de programação durante a implementação, times de sucesso
ilustram as especificações utilizando exemplos. O time trabalha com os stakeholderspara
identificar exemplos chave que descrevem a funcionalidade esperada. Durante este processo,
desenvolvedores e testadores frequentemente sugerem exemplos adicionais que ilustram
casos extremos ou trabalham criando exemplos para partes do sistema que são
particularmente problemáticas. Isso remove os gaps funcionais e as inconsistências e assegura
que todos os envolvidos possuem um conhecimento compartilhado do que precisa ser
entregue, evitando re-trabalho que resulta de erros de interpretação e tradução. </citação>
[Gojko 2011 Specification by example, chapter 2]
http://www.slideshare.net/marcusoftnet/specification-by-example-with-specflow-110217
Processo
1 Os objetivos de negócio são definidos
2 O escopo é derivado dos objetivos gerando estórias
3 Cada estória é ilustrada com exemplos e os exemplos são especificados
colaborativamente
4 Os exemplos mais significativos são selecionados (exemplos-chave)
5 As especificações dos exemplos-chave são refinadas para remover detalhes
desnecessários
6 As especificações refinadas são automatizadas sem modifica-las, tornando-se
especificações executáveis

7 Ao final do processo as especificações executáveis formam uma documentação “viva”
do sistema pois ao mesmo tempo em que descrevem os comportamentos esperados
elas são o próprio teste do sistema.
Os exemplos são tratados como fonte única de verdade, sendo este um aspecto chave desta
metodologia. Desta forma, evita que diferentes colaboradores de uma equipe de desenvolvimento
gerem e trabalhem somente em seus próprios documentos. Neste contexto, pode-se afirmar que a
eficácia da entrega do software é significativamente afetada pela constante necessidade de
coordenação e sincronização destas diferentes “versões da verdade”. Fazendo uso de SbE todos
os membro da equipe participam da criação da única fonte de verdade, sendo assim nela
encontra-se a compreensão de todos. Estes exemplos são utilizados para proporcionar precisão e
clareza, para fazer uso desta informação tanto como uma especificação como um teste funcional.
Qualquer informação considerada relevante durante o ciclo de desenvolvimento é adicionada a
esta fonte de exemplos única, sem requerer qualquer necessidade de tradução ou interpretação.
Documentação Viva
Segundo Gojko a questão da documentação gerada pelo SpecificationbyExample advém
parte do ATTD e parte do BDD, ambas com focos diferentes que quando unidas proporcionam
uma totalidade na cobertura e profundidades acerca das especificações do sistema. O ATTD
detém seu foco na automação dos testes funcionais, de regressão e são alvos mais claros para o
desenvolvimento. O ATDD é mais útil para a adoção inicial quando se tem muitos problemas
relacionados a qualidade funcional do sistema. Já o BDD centra-se no processo de especificação
de cenários por meio do comportamento do sistema, podendo servir como base para fundamentar
as atividades de entrega de software a médio e curto prazo. O BDD centra-se na construção do
entendimento comum entre as partes interessadas através da colaboração e esclarecimento de
especificações.
É necessário saber o que um sistema faz para ser capaz de analisar os impactos das
mudanças sugeridas, apoiá-lo, e solucionar problemas. Muitas vezes, a única maneira de
descobrir o que o sistema faz é olhar para o código-fonte da linguagem de programação e aplicar
engenharia reversa na funcionalidade do negócio. Logo uma boa documentação é útil para além
do desenvolvimento de software. A solução ideal seria um sistema de documentação que é fácil e
barato de manter, de forma que ele possa ser mantido de acordo com a funcionalidade do
sistema, mesmo se o código da linguagem de programação subjacente é alterada com frequência.
O problema com qualquer tipo de documentação completa é, de fato, o custo de manutenção.
Quando um sistema de software é continuamente validado contra um conjunto de
especificações executáveis, uma equipe pode estar certa de que o sistema irá fazer o que as
especificações dizem, ou, em outras palavras, que as especificações vão continuar a descrever o
que o sistema faz. Essas especificações vivem com o sistema, e elas são sempre consistentes, e
pelo fato da noção das diferenças entre as especificações e a funcionalidade de fato
implementada de forma imediata, esta documentação pode ser mantida consistente a um baixo

custo. Estas especificações executáveis criam um corpo robusto de documentação, uma fonte
autorizada e não ambígua de informações sobre a funcionalidade de um sistema, fazendo uma
analogia, cada uma das especificações seriam como páginas do livro que é o próprio sistema de
documentação viva.
Gojko ainda afirma que a documentação viva substitui todos os artefatos que as equipes
precisam para entregar o produto certo, ela pode até mesmo apoiar a produção de manuais de
usuários (embora provavelmente não substituí-los). As especificações são definidas conforme e
concomitante a evolução do sistema, a documentação resultante é incremental e assim torna-se
barata de escrever. Ao mesmo tempo em que os processos de negócio são derivados é possivel
executá-los exercitando e auxiliando o processo de desenvolvimento do software, já que trata-se
de algo mais leve e intrinsecamente mais ligado ao código real, é uma documentação real.
Aplicar SpecificationbyExample somente pelo fato do ganho por meio dos testes de regressão
acaba por não justificar o investimento feito a longo prazo para implementá-lo já que conforme
as estimativas dos custos de software, aponta que a eficiência na remoção dos defeitos por meio
de testes de regressão é de 23% em média. Esta prática permite a criação de documentação viva
sem necessidade de anos de prática pela sua forma mais natural de escrita, criando documentação
por meio de especificações executáveis.
A documentação viva é tão importante quanto o sistema que se está entregando, a ideia
de que a documentação é um produto chave é o cerne deste método. Algumas vantagens em ter
uma documentação viva são apontadas por Gojko:
○ Ajuda as equipes a longo prazo evitando os problemas mais comuns com
manutenção;
○ Ajuda as equipes a criarem documentação útil que irá facilitar a evolução do
software ao longo do tempo;
○ Ajuda a evitar problemas de manutenção causados pela falta de conhecimento
compartilhado.
Como iniciar a mudança no processo
Sobre como iniciar a mudança no processo e introduzir SpecificationbyExampleGjko afirma que
os pontos de partida cujos resultados podem ser obtidos mais rapidamente são os seguintes:
● Se já existe uma mudança no processo ocorrendo, utilizar essa oportunidade para introduzir as
ideias chaves por trás do SpecificationbyExample. Como exemplo o autor cita que durante a
mudança para uma metodologia de desenvolvimento ágil é mais fácil introduzir as idéias do
SpecificationbyExample embutidas nas práticas diárias.
● Implementar testes funcionais automatizados para times que não possuem nenhum teste funcional
automatizado. Focar na qualidade do produto é a mais eficiente forma, segundo Gjko de
implementarSpecificationbyExample pois iniciando com testes funcionais automatizados e a

documentação viva do sistema o time pode gradualmente ir utilizando novas especificações para
guiar o desenvolvimento ao mesmo tempo em que sente os benefícios de possuir especificações
executáveis garantindo a regressão do sismtema.
● Introduzir especificações executáveis automatizadas para times que possuem automação de testes
separada do desenvolvimento. Gjko afirma que introduzir a camada de especificação por
exemplos pode aproximar testadores de desenvolvedores assim como engajar os stakeholders no
processo de especificação utilizando exemplos.
Como iniciar a mudança na cultura do time
Na maior parte as mudanças necessárias para implementar os processos chave do SpecificationbyExample
são culturais - todos os envolvidos no processo de entrega do software colaboram juntamente com os
stakeholders para especificar os requerimentos. A seguir Gjko cita pontos que podem auxiliar nessa
mudança cultural:
● Evitar utilizar a terminologia “ágil” quando estiver em um ambiente resistente a mudanças. O
autor afirma que o uso de jargões tais como: Scrums, stand-ups, userstories, backlog, masters,
pairprogramming, e outros termos como estes são facilmente mal-entendidos e acabam causando
confusão e por consequência resistência a mudanças. É factível
implementarSpecificationbyExample sem utilizar termos técnicos, tendo como objetivo inicial a
melhoria da qualidade do produto, as outras mudanças acontecem por consequência.
● Explicar SpecificationbyExample como o processo de coletar exemplos para clarificar os
requisitos, derivando testes e então automatizando esses exemplos.
● Assegurar de que há suporte gerencial. Durante a implementação dos testes funcionais
automatizados utilizando as especificações a produtividade do time vai cair brevemente para
depois subir constantemente. Sem o suporte gerencial as chances de sucesso do
SpecificationbyExample são mínimas.
● Vender SpecificationbyExample como uma nova forma de realizar testes de aceitação de usuário.
Utilizar o conhecimento de domínio dos stakeholders e futuros usuários do sistema para colaborar
nas especificações iniciais ao invés de apresentar a funcionalidade ao final de um ciclo de
desenvolvimento para testes manuais de aceitação. Demonstrar que as especificações iniciais
foram automatizadas e são validadas constantemente.
● Não fazer com que a automação funcional de testes seja o objetivo final. Oprincipal objetivo da
automação de testes funcionais no contexto do SpecificationbyExample é ser legível para pessoas
sem nenhum conhecimento técnico, promover a comunicação a cerca do comportamento
esperado do sistema e tornar-se documentação viva. De outra forma os stakeholders e usuáriosnão
irão se importar com as especificações executáveis.

Specificationby example

Mais conteúdo relacionado

Mais procurados (20)

Destaque (19)

Semelhante a Specificationby example (20)

Mais de Laís Berlatto (20)

Specificationby example