Especificação por meio de exemplos (BDD, testes de aceitação, ...)

Especificação por meio de exemplosUMA INTRODUÇÃO

Fábio Nogueira de Lucena

Referência

Specification By Example: How successful teams deliver the right softwareGojko Adzic, Manning, 2011

http://specificationbyexample.com/

Créditos para o autor e sua obra

Specification By Example: How successful teams deliver the right softwareGojko Adzic, Manning, 2011

Frases, citações e excertos obtidosdeste livro.

Aviso

As informações aqui contidas são uma interpretação do conteúdo do livro indicado no slide anterior.

Consulte o original para detalhes.

Esteja alerta!

Tecnologias são propostas e criadas continuamente para resolver problemas. Duas questões surgem:

A estratégia realmente contribui? O problema resolvido é parecido com o meu?

Orientações

Conhecimento de cerca de 50 projetos.

Alguns pequenos, outros envolvendo equipes espalhadas por diversos continentes.

Processos executados: XP, Scrum, Kanban e similares.

Outros nomes Testes de aceitação ágil

Behavior-Driven Development

Specification by Example, ...

Apresentado por meio de padrões

Tradicionalmente, ...

Desenvolver software exige extensas especificações funcionais e longas fases de testes.

O que não é compatível com liberações semanais.

O que precisamos?

Evitar especificação “exagerada” Documentação confiável que explica o que o sistema

faz Verificar de forma eficiente se o sistema faz o que a

especificação diz. Manter documentação relevante e confiável com o

mínimo de custo de manutenção.

Especificação por meio de exemplos é uma estratégia dirigida para atingir estes objetivos.

Especificação por meio deexemplos é um conjunto de

padrões de processo.

“Ao revelar os padrões de processos empregados por equipes de sucesso,eu espero ajudar outros a implementar estas ideias deliberadamente.”Gojko AdzicSpecification By ExampleManning, 2011.

Padrões de processos

Derivar escopo de objetivos

Especificar de forma colaborativa

Ilustrar usando exemplos

Refinar a especificação

Automatizar a validação sem alterar especificações

Validar frequentemente

Evoluir o sistema de documentação

Derivar escopo de objetivos

Derivar escopo de objetivos

Domínio da solução

Domínio do problema

Derivar escopo de objetivos(contexto)

Escopo é solução para problema do domínio.

Escopo é um meio de se atingir um objetivo de negócio.

Muitos esperam a definição do escopo pelo cliente, product owner ou usuário antes de iniciar a implementação.

Tudo que ocorre antes da implementação é geralmente ignorado pela equipe de desenvolvimento.

Após a especificação, desenvolvedores implementam a solução.

Derivar escopo de objetivos

Se clientes definem o escopo, então o projeto não se beneficia do conhecimento das pessoas na equipe de desenvolvimento.

O software fará o que o cliente pediu, mas não necessariamente o que precisava.

O Código de Trânsito Brasileiro foi alterado(Lei nº 11.910 de 18 de março de 2009)

“Art. 105. São equipamentos obrigatórios dos veículos, entre outros a serem estabelecidos pelo CONTRAN: (...)

VII - equipamento suplementar de retenção – air bag frontal para o condutor e o passageiro do banco dianteiro. (...)

CONTRAN, Resolução no. 312, instituiu a obrigatoriedade do sistema antitravamento das rodas (freio ABS).

ESCOPO

SegurançaOBJETIVO

“Eu quero um carro com vido elétrico, ... Sério?

ESCOPO

Ah, conforto.OBJETIVO

Posso indicar o carro com as características, mas comoespecialista em automóveis, se eu conhecesse o real objetivo, possivelmente seria mais útil, efetivo, ...

RESUMO

Derivar escopo de objetivos

‘Em vez de “cegamente” aceitar requisitos como a solução para um problema desconhecido, equipes de sucesso derivam escopo de objetivos.’Gojko Adzic

Derivar escopo de objetivos

Inicia-se com objetivo de negócio do cliente.

Todos colaboram para definir o escopo que atinge o objetivo.

A equipe trabalha com os usuários do negócio na determinação da solução.

Aqueles do negócio concentram-se no objetivo de uma característica desejável e no valor que esperam extrair dela.

A equipe então sugere uma solução que é mais barata, mais rápida, ...

Especificar de forma colaborativa

Em vez de contar com uma única pessoa para obter as especificações corretamente, equipes de sucesso colaboram com entendidos no negócio para especificar a solução.

Cria uma “propriedade compartilhada”das especificações, tornando a equipe mais engajada.

Ilustrar usando exemplos

Em vez de esperar pelo registro preciso deespecificações em uma linguagem de programaçãodurante a implementação, equipes de sucessoilustram especificações usando exemplos.

Equipe trabalha com especialistas do negóciopara identificar “exemplos chave” quedescrevem a funcionalidade esperada.

Desenvolvedores sugerem exemplos queilustram casos “problemáticos”.

Todos têm uma compreensão compartilhadado que precisa ser produzido.

Exemplos chave servem como alvo paradesenvolvedores e como critério de avaliaçãoobjetivo para checar se o desenvolvimentoestá concluído.

Se os exemplos são fáceis de entender,então podem ser empregados comorequisitos detalhados e não ambíguos.

Refinar a especificação

Especialistas no negócio tendem a pensarda perspectiva da interface com o usuário.

Detalhar como algo deve ser feito é emvez do que é exigido é um desperdício.

Muitos detalhes tornam exemplos difíceisde comunicar e compreender.

Equipes de sucesso, ao refinar a especificação,removem informações “não essenciais”e criam um contexto preciso e concretopara o desenvolvimento e testes.

Equipes de sucesso especificamo que é suposto que o softwarefaça, em vez de como ele faz.

Cucumber (exemplo)

Especificação com exemplos é uma especificação de trabalho, é um teste de aceitação, é um teste funcional.

Automatizar a validaçãosem alterar especificações

Verificação rápida é essencial para o desenvolvimentode software em iterações curtas.

Ou seja, é preciso tornar o processo de validação barato e eficiente.

Solução óbvia: automação.

Automação sim, mas como?

Rhino Mocks

Especificações automatizadastecnicamente são inacessíveis aos especialistas do negócio.

Várias versões

Versão desenvolvedor Versão mais legível

Sincronização???!!!

Equipes de sucesso não correm o risco de“tradução entre formatos”.

Exemplos chave que são compreensíveis eacessíveis a toda a equipe tornam-seespecificações executáveis.

Cucumber (exemplo)

Se é preciso alterar, então há um único lugar.

Única fonte

Consumida pordesenvolvedores,

responsáveis por testes,especialistas no domínio,

e outros.

Fitnesse

Wiki

Concordion

Concordion

Cucumber

specFlow

codeeffects http://rule.codeeffects.com/

OpenRules

Validar frequentemente

Um suporte eficiente de software exige sabermos o quê ele faz e o porquê.

Em muitos casos, a única formade fazer isto é recorrer ao código ou encontrar alguém que possa fazer para nós.

Código é, frequentemente, a única coisa em quepodemos confiar; muita documentação é desatualizada antes do término do projeto.

Desenvolvedores são oráculos de conhecimentoe gargalos de informação.

Evoluir o sistema dedocumentação

Ao longo do tempo, mudanças ocorrem eprovocam atualizações na“documentação viva”.

Créditos para o autor e sua obra(agradecimentos finais)

Specification By Example: How successful teams deliver the right softwareGojko Adzic, Manning, 2011

Frases, citações e excertos obtidosdeste livro.