Na primeira parte desta série, falamos sobre o que é a Especificação Por Exemplo (e também sobre o que ela não é). Descobrimos que ela é um conjunto de boas práticas para ajudar a construir o produto certo. Neste artigo e no próximo, vamos falar um pouco sobre cada uma dessas práticas.

Derivar o escopo a partir do objetivo

Como falamos no primeiro artigo, nem sempre o que o cliente pede é realmente o que ele precisa (lembram do exemplo do carro x bicicleta?). Derivar o escopo a partir dos objetivos ajuda a descobrir o que o cliente realmente precisa e dá liberdade para que o time de desenvolvimento possa sugerir a melhor forma de fazer isso (mais simples de implementar, mais rápida e até mais barata).

Nosso foco, então, deve ser entender qual o problema que o cliente quer resolver, ou a meta que ele quer atingir, e a partir daí o time todo colabora para chegar ao design da solução.

objetivos de negócio > derivar o escopo > criar as histórias

Nesse ponto, é de extrema importância entender alguns pontos:

• quem precisa?
• de quê?
• para qual finalidade?

Assim, fica mais fácil de descobrir qual o produto que realmente vai resolver o problema do cliente.

Especificar colaborativamente

Colaboração sem dúvidas é uma das palavras mais importantes nesse contexto. Para alcançar o sucesso, é importante que todas as pessoas envolvidas colaborem. Assim, o entendimento é uniforme e um conhecimento compartilhado é construído.

A Documentação Viva, da qual falamos no artigo anterior, é um exemplo do que deve ser especificado colaborativamente. QAs, Devs, POs, UXs e todos os envolvidos devem elaborá-la em conjunto criando especificações que são fáceis de entender (para os mais diversos papéis) e testes simples de manter.

Alguns exemplos de como especificar colaborativamente:

• Grandes Workshops: time, stalkeholders e todas as pessoas com conhecimento de negócio elaboram juntas exemplos para ilustrar a funcionalidade. Pode-se usar a cerimônia de refinamento para isso.
• Pequenos Workshops (3 amigos): geralmente QA, PO e UX, ou QA, BA (Business Analyst), DEV (ou a configuração que fizer sentido para seu time) colaboram para criar os exemplos. O QA contribui muito na hora de pensar nos cenários (tanto positivos quanto negativos) para as funcionalidades.
• Escrita em par: QA e UX, QA e PO, QA e DEV, BA e DEV (ou a configuração que fizer sentido para seu time) escrevem em par as especificações.
• Desenvolvedores revisam as especificações: quando o time não tem um QA, por exemplo, e o PO ou o BA escrevem as especificações, o time de desenvolvimento pode revisar para garantir que não existem dúvidas sobre o que deve ser implementado.

O importante é que exista algum nível de colaboração.

Ilustrar com exemplos

Seres humanos compreendem melhor com exemplos práticos. Isso ajuda a evitar a ambiguidade e comunica com precisão.

É importante utilizar exemplos concretos do negócio e pensar nos outputs esperados.

Além disso, os exemplos ajudam a gerar discussão e eliminar as dúvidas.

Exemplificando:

Funcionalidade: Entrega Grátis

1 – Oferecida para clientes VIP, uma vez que eles comprem um certo número de livros;

2 – Não é oferecida para clientes comuns nem para clientes VIPs que comprem qualquer coisa diferente de livros;

3 – O número mínimo de livros para a entrega grátis é 5;

Exemplos:

Algumas características de bons exemplos:

• devem ser precisos: ajuda a evitar ambiguidade, deve informar claramente o contexto e como o sistema deveria se comportar em cada caso;
• devem ser completos: é importante combinar diferentes inputs e pensar nos resultados esperados, além de experimentar com dados;
• devem ser realísticos: pensar sempre em situações reais do usuário (cuidado com informações sigilosas);
• fáceis de entender: todos os envolvidos devem ler os exemplos e entender sem muita dificuldade. Pode-se usar de abstrações – por exemplo, usar “carro” como exemplo em vez de ficar descrevendo exaustivamente as características do mesmo: carro com 4 rodas, 2 portas etc., a menos que essas características influenciem no resultado final.

Também pode-se usar exemplos para requisitos não funcionais.

Performance: “o sistema precisa importar X registros em Y minutos consumindo Z de cpus”.

UI: protótipos de telas são bons exemplos também.

Refinando as especificações

Nesse ponto, já temos muitos insumos sobre o que deve ser construído e qual o comportamento. Agora é hora de olhar pra todo esse conteúdo e refiná-lo.

Uma boa especificação vira um teste de aceitação; para isso, ela precisa ser:

• precisa e testável (já falamos disso no ponto anterior)
• não ser um script: os scripts dizem como algo deve ser testado (logar como Maria, navegar para home, pesquisar por “Teste de Software”, adicionar o primeiro resultado ao carrinho etc.). A especificação fala o que software deve fazer (primeiro resultado de “Teste de Software” pode ser adicionado ao carrinho).
• estar descrevendo o negócio e não o design de tela: descreve qual a funcionalidade sem dizer como fazer isso. É importante evitar escrever especificações atreladas ao código (clico no botão “Fechar”). Pense primeiramente na jornada do usuário e não nos detalhes da tela.

Outro detalhe importante do refinamento é decidir o que vai ser coberto pelos testes de aceitação gerados a partir das especificações. Dê foco em ilustrar os aspectos mais importantes do negócio.

• Pausa para referência: vale ler sobre a Pirâmide de Automação de Testes e pensar em quais tipos de teste você pode usar no seu projeto;
• Pausa pra referência 2: eu tenho uma apresentação sobre os tipos de testes e exemplos.

Pra encerrar a parte 2 da nossa série, outra dica essencial: para tudo o que falamos hoje, lembre-se de utilizar uma linguagem que represente o domínio do negócio e evite o tecniquês. No último artigo da série, vamos falar dos processos que faltam: automatizar as especificações, validar frequentemente e evoluir a documentação viva. Até lá!

Referências:

• Specification by Example: How Successful Teams Deliver the Right Software
• Cucumber Best Practices
• 15 experts tips for using cucumber
  
• Never Say “Click” – Good Cucumber System Testing Practices

***

Artigo publicado originalmente em http://www.concretesolutions.com.br/2016/09/23/especificacao-por-exemplo-2/.