Quando li o livro Specification by Example (SbE) fiquei completamente apaixonado (não achei palavra melhor) pela metodologia e virei fã de carteirinha. Atualmente, toda a área de QA Mobile da Concrete Solutions baseia-se nos conceitos da especificação por exemplo, e estamos obtendo muito sucesso com implementações em diferentes clientes e projetos.

Gostaria de apresentar para vocês nesse artigo os principais conceitos da Especificação por Exemplo e, com sorte, também deixá-los interessados nesse assunto. Esse texto será bem teórico, pois quero deixar a metodologia bem clara. Já ons futuros, falarei mais especificamente sobre como implementamos a Especificação por Exemplo na CS.

Uma frase muito interessante publicada pelo autor do Livro SbE em seu twitter (@gojkoadzic) é: “Like cheap wine, paper documentation ages rapidly and leaves you with a bad headache”, em tradução livre seria algo como: “Assim como vinho barato, a documentação em papel envelhece rápido e te deixa com uma incrível dor de cabeça”. O foco principal da SbE é resolver esse problema. Para isso existe o conceito de Documentação Viva (Living Documentation) que, como a Elessandra já explicou nesse aqui, é uma documentação que segue sempre junto do sistema, evoluindo continuamente, nunca envelhece e é sempre confiável.

O primeiro conceito sobre o qual temos que falar é: especificação não é teste. Isso pode parecer estranho, afinal sou um cara de QA falando sobre uma metodologia a ser utilizada em processos de QA. Mas realmente não é. A especificação é documentação e, portanto, deve ser clara e escrita em linguagem natural. Ponto importante a ser destacado aqui: a especificação deve ser entendida por todos os participantes do projeto, deve ser um porto seguro entre todos os envolvidos, desde clientes até desenvolvedores e testers.

Ok, mas como escrevemos essa especificação? Primeiro, temos que decidir qual a linguagem natural para se utilizar. Temos envolvidos de outros países no projeto? Se sim, então é interessante que ela seja em inglês ou em outra língua que todos compreendam. Aqui existe um ponto interessante: sabemos que a língua padrão da computação é o inglês, mas a sua documentação deve ser entendida por todos os integrantes, mesmo os não envolvidos em computação (como os clientes). Ou seja, se português é a língua que todos entenderam, seja feliz e utilize português, sem problema nenhum.

Outro ponto é que ela precisa focar no negócio, ou seja, toda e qualquer particularidade de implementação deve ser deixada de lado e não deve entrar na especificação. Assim, garantimos maior clareza e objetividade. Um exemplo: temos grandes diferenças de guidelines para Android e iOS. Em Android costuma-se usar menu, enquanto no iOS usamos navigation bar. Sendo assim, para acessar uma determinada tela do app, como o carrinho, no Android usaríamos o menu e no iOS usaríamos a navigation bar. Como deixar as características de implementação de lado? Simplesmente falamos “acesse o carrinho” ao invés de falar “por meio do Menu, acesse o carrinho”, ou “por meio da navigation bar, acesse o carrinho”. Como consequência disso, podemos ter uma mesma especificação para aplicativos Android e iOS que se comportam de maneiras similares.

A especificação foca no que DEVE SER FEITO, e NÃO em COMO DEVE SER FEITO.

Sendo assim, um cuidado que devemos ter é não confundir especificação com scripts de teste. Apesar desses scripts também serem claros e entendíveis por todos os envolvidos, eles tendem a misturar diversas funcionalidades. O objetivo principal de um script de teste é ser uma sequência bem definida de passos, normalmente atrelados às dificuldades de implementação.

Perfeito, então agora temos uma Documentação Viva do sistema? Ainda não. Até o momento, o que difere uma especificação de uma outra forma de documentação do sistema? Nada. Para que tenhamos uma Documentação Viva, nossa especificação precisa ser automatizada. Existem diversas ferramentas para automação de especificações, mas uma muito conhecida é o Cucumber. Uma vez automatizada, essa especificação pode ser confrontada regularmente com os sistema.

E o que ganhamos com a automação? A nossa especificação passa a evoluir juntamente com o seu sistema, ativamente nos informando se algo está diferente ou se tudo está conforme esperado.

A partir do momento em que temos nossa especificação focada nas nossas funcionalidades, escrita em linguagem natural e automatizada, conseguimos o principal benefício da SbE: CONFIANÇA.

• Confiança do cliente de que entendemos todas as funcionalidades que ele deseja;
• Confiança de que iremos entregar exatamente o que o cliente espera;
• Confiança de que os desenvolvedores irão desenvolver exatamente o esperado;
• Confiança de que uma vez desenvolvido, não teremos regressões;
• Confiança de que a especificação realmente representa o software, podendo ser utilizada em futuros processos de manutenção.

Além disso, temos outros benefícios, alguns decorrentes da confiança adquirida:

• Maior facilidade de comunicação entre todos os envolvidos no desenvolvimento do software;
• Documentação precisa e atualizada;
• Maior facilidade em processos futuros de manutenção;
• Testes de aceitação, integração e regressão automatizados.

Como falei no início, a ideia era fazer um artigo bastante teórico, por isso não vou abordar aqui o funcionamento das ferramentas de automação. Se você quiser saber mais, pode dar uma olhada nos aqui sobre Automação de testes funcionais: aqui está o post para Android, aqui para iOS e aqui para Android e iOS. Neles, você pode ter uma ideia de como utilizar Calabash e Cucumber para automatizar especificações.

Fique atento que em breve vamos publicar um texto sobre como implementamos a Especificação por Exemplo em nossas equipes ágeis.

Tem alguma dúvida ou observação? Aproveite os campos abaixo!