Especificação Por Exemplo como ela é – Parte 01

outubro 12, 2016 1:00 pm Publicado por Deixe um comentário

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

sbe-1

* adaptação: Specification by Example – Gojko Adzic, 2011

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

sbe-2

* Specification by Example – Gojko Adzic, 2011

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/

Mensagem do anunciante:

Experimente a Umbler, startup de Cloud Hosting por demanda feita para agências e desenvolvedores e ganhe até R$ 100 em créditos!

Source: IMasters

Categorizados em:

Este artigo foi escrito pormajor

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *