Specification By Example

Terminologia e Definição

O termo Specification by Example (Especificação por Exemplos) surgiu segundo seu criador Gojko Adzik (2011) com o intuíto de unificar em um só termo as seguintes técnicas, metodologias e práticas ágeis:

• Agile acceptance testing
• Test-Driven Development
• Acceptance Test-Driven Development
• Example-Driven Development
• Story testing
• Behavior-Driven Development

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.

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. Specification by Example é 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 agile e lean). Specification by Example 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.

Specification by Example unificou padrões e processos que times do mundo real utilizaram para atingir esses objetivos.

Padrões de processo

Os padrões estabelecidos por Specification by Example 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. Principais padrões de processo de Specification by Example.

1. Deriving scope from goals (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 stakeholders querem 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. Specifying collaboratively (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. Illustrating using examples (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 stakeholders para 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. Refining the specification (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. Automating validation without changing specifications (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. Validating Frequently (Validando frequentemente): Gjko afirma que a documentação tradicional de software fica desatualizada antes mesmo de o sitema 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.

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 Specification by Example 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 é alterado 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 é possível executá-los exercitando e auxiliando o processo de desenvolvimento do software, já que se trata de algo mais leve e intrinsecamente mais ligado ao código real, é uma documentação real. Aplicar Specification by Example somente pelo fato do ganho por meio dos testes de regressão acaba por não justificar o investimento feito em 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.

Figura 2 Tipo de documentação que deve ser escrita

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.