Especificação por Exemplo no SoftDrops

Tempo de leitura: 5 minutos

No SoftDrops do dia 20 de novembro, o agilista Raphael Rodrigues falou aos colegas sobre “Especificação por Exemplo” (Specification by Example – SbE). Criada por Gojko Adzic, o conjunto de práticas possibilita minimizar riscos durante a construção de um produto digital, ao focar na comunicação entre todas as partes envolvidas durante o desenvolvimento do projeto. Segundo Raphael, “essa prática pode contribuir muito com o alinhamento da equipe, além de reduzir o retrabalho na busca por entregar o que é certo”. No entanto, antes de analisá-la, é preciso compreender o que é especificação dentro no contexto de desenvolvimento de um software.

Entendendo a especificação

A especificação é uma declaração (escrita) dos requisitos que um software terá. Segundo a norma IEEE-90, a especificação pode ser:

• Uma capacidade que um usuário necessita para resolver um problema ou atingir um objetivo;

• Uma capacidade que deve ser atendida por um sistema ou componente de um sistema para satisfazer um contrato, padrão, especificação ou outro documento formalmente imposto;

• Um conjunto de todos os requisitos que formam a base para o desenvolvimento de um software.

Em resumo, os requisitos se referem à solicitação do cliente, suas necessidades, exigências e desejos. Logo, a especificação é a documentação desses requisitos.

Práticas que minimizam riscos e ajudam na construção de um produto digital

Executada no ciclo de descoberta (discovery) em times ágeis, a Especificação por Exemplo pode ser utilizada em conjunto com outras práticas. “Apesar de ser empregada nessa fase do projeto, ela não se concentra em explorar problemas e ‘compreender’ o que precisa ser feito, mas sim em ‘detalhar’ o que precisa ser feito”, comentou Raphael.

As outras práticas que podem ser utilizadas junto com a Especificação por Exemplo são:

Impact Mapping (que se concentra em definir os objetivos, personas, impacto no consumidor);

Story Mapping (que se concentra na definição de épicos, ou seja, histórias de usuário grandes demais para serem “quebradas” em pequenas partes);

Funil de Práticas.

Como a especificação por exemplo ocorre?

Nessa etapa do funil, ocorrem três técnicas, que são: quebrar o escopo, workshop 3 amigos e exemplos-chave.

• Quebrar o escopo: nada mais é do que escrever as user stories, ou seja, declarar o que um usuário faz ou necessita fazer dentro de uma aplicação. Exemplo: “Como um vendedor, gostaria de consultar o estoque de um determinado produto para oferecer a um cliente?”

• Workshop três amigos: é a busca por alinhamento do time, constituído por Product Owner (PO), desenvolvedor e analista de testes (QA). A proposta dessa técnica é promover o entendimento entre a equipe, com uma comunicação mais transparente e uniforme entre os integrantes do projeto.

• Exemplos-chave: corresponde aos cenários de teste. É a descrição de comportamentos do usuário, que muitas vezes é realizado pelo QA. Exemplo: “Dado que o livro ‘Paz e Guerra’ está disponível por R$20,00, quando Susane seleciona o livro ‘Paz e Guerra’, então a tela de comprar livro por R$ 20,00 é exibida.”

“Após utilizar essas técnicas, é importante montar uma tabela declarando as restrições do que está sendo validado, juntamente com os exemplos de comportamento que precisam ser testados”, concluiu Raphael.

Se você quiser conferir a série de conteúdos sobre Estratégias de Testes de APIs escrita por Raphael Rodrigues aqui no nosso blog, clique aqui.

Sugestões ou críticas para nosso blog? Entre em contato pelo endereço mkt@softdesign.com.br.