PT | EN
Publicado dia 29 de novembro de 2019

Especificação por Exemplo no SoftDrops

| Tempo de leitura 3 minutos Tempo de leitura 3 minutos
Especificação por Exemplo no SoftDrops

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.

Confira a série de conteúdos sobre Estratégias de Testes de APIs escrita por Raphael Rodrigues no nosso blog.

Foto do autor

Quer saber mais sobre
Design, Estratégia e Tecnologia?