Já tive algumas discussões com amigos da comunidade sobre a utilização de Especificação Por Exemplo, e todas elas acabaram por me motivar a escrever este artigo e tentar esclarecer o assunto.

Situação: quando a galera de QA ouve falar de especificação, BDD, ATDD ou outros termos correlacionados, pensa logo na automação de testes e no fato de que será acrescentada mais uma camada de abstração (as features), gerando mais trabalho.

Problema: pensar na especificação apenas como mais uma camada da automação de testes. Ela definitivamente não é isso.

O que ela é, então?

A Especificação Por Exemplo (ou Sbe, do inglês Specification By Example) é um conjunto de práticas que ajudam a construir o produto certo, focando na comunicação entre as pessoas envolvidas no projeto de forma que todos possam ter o mesmo entendimento e que contribuam para o produto. Ela tem foco no negócio (nada de termos em tecniquês), preconizando uma linguagem comum e uma documentação que seja viva.

Construir Certo X Produto Certo

Essa, pra mim, é uma das maiores sacadas da Especificação: entender qual o produto certo baseado no problema que o cliente quer resolver ou nos objetivos de negócio.

Construir certo, utilizando as melhores práticas de desenvolvimento, melhores ferramentas, testes automatizados, continuous delivery e tantas outras coisas de nada adianta se o produto não atinge os objetivos de negócio e não gera lucro pra empresa.

Mas como? Vou detalhar nos próximos artigos, mas em resumo a especificação foca na colaboração dos indivíduos envolvidos (QAs, Devs, POs, Uxs, Stakeholders, toda a galera) para, a partir dos objetivos de negócio, descobrir quais features são relevantes e vão atender a esse objetivo.

Geralmente, os stakeholders já pensam no final do processo (quero um carro, por exemplo), mas na maioria das vezes existe uma distância entre o que eles querem (o carro) e o que eles precisam (você pode descobrir que eles só têm que percorrer 900m, e uma bicicleta é o máximo que eles precisam).

Então, a especificação te dá processos que vão ajudar a melhorar o entendimento e a colaboração dos envolvidos no projeto, focando no real problema (ou objetivo de negócio) do stakeholder. Além disso, te oferece exemplos que podem utilizados para automatizar os testes.

Documentação Viva

Em desenvolvimento de software, existem vários tipos de documentação que podem ser aplicados ao gosto do cliente. O problema é que fatalmente ela acaba ficando desatualizada em relação ao código da aplicação.

Além disso, existem dois cenários extremos que acabam acontecendo:

Cenário 1 (geralmente observado em desenvolvimento Cascata) –  muitos e diferentes documentos (Termo de Iniciação, Termo de Abertura do Projeto, Casos de Uso, Especificação Técnica, Plano de Testes, Casos de Teste etc.).

Cenário 2 (geralmente observado em desenvolvimento ágil) – já que é documentação mínima, não vamos fazer documentação. Nosso código é o documento.

Ambos os cenários são extremos. No primeiro, você tem toneladas de documentos completamente apartados do código da aplicação e que com o decorrer do projeto vão ficar desatualizados. No segundo, você tem apenas o código como documentação, impedindo que pessoas não técnicas (POs e até mesmo os stakeholders) tenham uma ferramenta pra colaborar no entendimento dos requisitos com o time.

Por isso a especificação fala da Documentação Viva. Ela é:

• simples de manter: um único documento, em um único lugar (geralmente no controle de versão junto com o código);
• sempre atualizada: qualquer mudança que seja necessária será feita apenas nela;
• executável: você utiliza essa documentação (isso mesmo, o texto em pt-br que você escreveu pra definir o comportamento da aplicação) para automatizar testes (agora sim a gente fala de testes automatizados);
• confiável: como ela está sempre atualizada, ela é confiável. Além disso, como essa documentação foi automatizada por meio de testes, sempre que algum comportamento mudar o teste vai falhar e te obrigar a atualizar a documentação;
• colaborativa: é construída com a ajuda de todos os envolvidos no projeto;
• esclarecedora: clara o suficiente para que todos entendam e serve de fonte de consultas caso exista alguma dúvida na hora de desenvolver.

Vamos para os padrões então

Como pode ser visto na figura acima, a especificação trata de 7 processos:

• Derivar o escopo a partir do objetivo;
• Especificar colaborativamente;
• Ilustrar usando exemplos;
• Refinar a especificação;
• Automatizar as especificações;
• Validar frequentemente;
• Evoluir a documentação viva;

Nos próximos artigos, vou falar detalhadamente de cada um desses processos.

IMPORTANTE: Da próxima vez que ouvir falar de Especificação Por Exemplo, não pense primeiramente em testes automatizados (eles são consequência), e sim em um conjunto de padrões pra construir o produto certo.

Ficou alguma dúvida ou tem algum comentário sobre o texto? Deixe sua contribuição abaixo. Até a próxima!

***

Artigo publicado em http://www.concretesolutions.com.br/2016/09/22/especificacao-por-exemplo-1/