Concrete Logo
Hamburger button

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

  • Blog
  • 23 de Setembro de 2016

*Este post foi originalmente publicado no Blog Teste de Software. Confira aqui.

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 post 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 post, 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, que falamos no post 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 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 e 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:

Captura de Tela 2016-08-26 às 12.01.12

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 ao invés 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 o 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.

Pra encerrar a parte 2 da nossa série, outra dica essencial: para tudo o que falamos hoje, lembre de utilizar uma linguagem que represente o domínio do negócio e evite o tecniquês. Amanhã eu volto com o último post da série, no qual 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

Trabalha com QA e quer fazer parte do nosso time? Clique aqui!