Specification By Example: How successful teams deliver the right software

Este livro, escrito por Gojko Adzic é diferenciado, porque é um daqueles livros que quebram com paradigmas. O livro em si não possui nenhum código fonte e não explica sobre nenhuma ferramenta. É essencialmente sobre processo para a entrega de um produto certo, e não apenas de construir certo. Os livros do Gojko em geral são muito bons, todos eles não apenas valem a pena ser lidos como devem ser lidos por qualquer um interessado em entregar software de qualidade. Este livro foi listado como o segundo mais influente livro ágil de 2012, baseado nos reviews da Amazon e da Goodreads. Gojko é sérvio, sua carreira profissional começou em 1997 com artigos sobre programação publicados em revistas sérvias. Em 2005 ele se mudou para o Reino Unido e em 2009 fundou junto com outras pessoas a Yazino, uma startup de game social. Estarei neste post trazendo incrementalmente as principais ideias desse livro.

Muitos nomes, uma só ideia

Um esclarecimento muito importante são as inúmeras variações de nomes que as práticas que tratam com especificações e testes possuem. Todas elas compartilham dos mesmos conjuntos de princípios e ideias, dessa forma, tratam essencialmente da mesma coisa:

  • Agile acceptance testing
  • Acceptance Test-Driven Development
  • Example-Driven Development
  • Story testing
  • Behavior-Driven Development
  • Specification by Example

Gojko percebeu que as inúmeras variações de nomes não faziam com que as pessoas de negócio se tornassem mais envolvidas, os termos eram muito técnicos e mais confundiam do que ajudavam. Dessa forma decidiu nomear todo o conjunto de práticas descritas no livro como Specification by Example, pois não cria uma herança com nomes como agile, driven-development ou test, o que algumas vezes podem levar a uma compreensão viciada dos termos.

Você está construindo certo o produto certo?

Construir certo o produto versus construir o produto certo

Como pode ser visto na imagem, Specification by Example vai de encontro não apenas em construir certo o produto, mas também em construir o produto certo. Segundo o autor, o foco da comunidade nos últimos anos foi principalmente na eficiência e não na eficácia. Lembre-se de Peter Drucker, “a eficiência consiste em fazer certo as coisas, a eficácia em fazer as coisas certas”. Precisamos de ambos para o produto ter êxito. Dessa forma, para construir o produto certo é preciso:

  • Evitar o excesso de documentação.
  • Evitar a perda de tempo em detalhes que irão mudar antes mesmo de um trecho de código ser desenvolvido.
  • Ter documentação confiável que explique o que o sistema faz e que possa ser modificada facilmente.
  • Manter a documentação relevante e confiável com o mínimo de custo de manutenção.
  • Encaixar tudo isso em iterações curtas, para que as informações sobre o trabalho futuro possam ser produzidas just-in-time.

A figura a seguir mostra a documentação que times ágeis necessitam hoje. Elas precisam ser fáceis de manter, devem possibilitar serem escritas com pouca antecedência e devem ser testáveis. Isso faz todo o sentido quando passamos a pensar que toda a documentação gerada para o software passa a ser única. Isso é, não existe diferença da documentação que uma equipe de qualidade gera e da que o analista de negócios gera, pois todas elas tem o mesmo propósito. Todos estão escrevendo especificação para que o software funcione corretamente. Escrever comportamento de teste também é escrever especificação.

Intersecção para construir o produto certo

Quais são os benefícios em utilizar as práticas de Specification By Example?

O conjunto de práticas de Specification by Example pode ser usado tanto em times que usam processos baseados em iterações, como Scrum e Extreme Programming (XP), assim como processos baseados em fluxos, como Kanban. Os principais benefícios são os seguintes:

Implementação de mudanças mais eficiente

Isso ocorre por conta da existência de “documentação viva”, que é uma fonte confiável de informação das funcionalidades do sistema. É como dizer que agora a sua especificação é “compilável” (e como você verá mais adiante, de fato é).

Alta qualidade do produto

As expectativas estão claramente definidas o que torna a validação do processo eficiente. O desenvolvimento é baseado em comportamentos testáveis.

Menos retrabalho

Melhora da colaboração nas especificações, o que leva a um entendimento compartilhado das expectativas de todos os membros do time.

Melhor alinhamento de atividades dos diferentes papéis dentro do projeto

Melhora da colaboração entre os papéis, o que leva a um fluxo de entrega mais regular.

Quais são os passos para entregar um produto eficaz?

Specification by Example é um conjunto de processos que facilita a mudança no software. Foca na entrega de um produto eficaz, e não apenas eficiente. A figura a seguir é a “big picture” do Specification By Example, e de certa forma, mostra o como o software sempre deveria estar: alinhado com o negócio. Na primeira parte, deriva-se o escopo a partir dos objetivos de negócio. Nada mais justo, sem objetivos de negócio o software provavelmente não teria motivos para existir. O escopo é então especificado colaborativamente, definindo-se os principais exemplos que são representativos para as user stories. Esses exemplos são refinados para então poderem ser automatizados, o que dá origem a uma especificação executável, literalmente uma especificação “compilável”. Essa especificação é validada frequentemente, uma vez que esses exemplos estão automatizados. Isso tudo dá origem a uma especificação viva e totalmente sincronizada com o software. Ao final, se algum comportamento do software é alterado a ponto de não corresponder mais a um exemplo da especificação, a validação irá quebrar. Da mesma forma, se algum exemplo da especificação é alterado sem que haja alteração no código, o software irá quebrar.

Processo da especificação por exemplos

A seguir serão mostradas as principais ideias de cada uma das etapas desse processo que foram extraídas do livro.

Derivar o escopo dos objetivos

Implementar um escopo significa oferecer a solução para um problema de negócio ou atingir um objetivo de negócio. Confiar no cliente para criar uma lista de user stories é deixar para ele a responsabilidade de desenhar a solução, porém os usuários de negócio não são designer de software. Se o cliente é quem define o escopo, o projeto não irá se beneficiar do conhecimento das pessoas da equipe de entrega. Isso resulta em um software que faz o que o cliente pediu, mas não o que ele realmente precisa. Ao invés de aceitar cegamente os requisitos de software como uma solução para um problema desconhecido, deriva-se o escopo dos objetivos. Os usuários de negócio, dessa forma, focam em comunicar o valor que eles esperam receber das funcionalidades desejadas. Isso ajuda todo mundo a entender porque ela é necessária. O time então pode sugerir uma solução que seja mais econômica, rápida e fácil de entregar do que aquela que muitas vezes os usuários de negócio imaginavam.

Especificar colaborativamente

Se desenvolvedores e testadores não estão engajados em elaborar as especificações, essas terão que ser comunicadas separadamente para o time, o que acaba abrindo oportunidades para muitos desentendimento. Na prática, você está brincando de telefone sem fio. No lugar de simplesmente confiar em uma única pessoa toda a responsabilidade de criar as especificações, por que não fazer com que os times de entrega colaborarem com os usuários de negócio para especificar a solução? Pessoas com diferentes experiências tem diferentes ideias e usam essa experiência a favor para resolver os problemas. Especificar colaborativamente cria um senso de posse compartilhada da especificação, fazendo com que todos sintam-se mais envolvidos no processo de entrega.

Ilustrar usando exemplos

Em vez de esperar que as especificações sejam precisas desde o início, trabalhe junto com os usuários de negócio para identificar os principais exemplos que descrevem a funcionalidade esperada. Durante esse processo, desenvolvedores e testadores frequentemente sugerem exemplos adicionais que ilustram casos extremos ou que enderecem áreas do sistema que são particularmente problemáticas. Isso elimina gaps funcionais e inconsistências e garante que todos os envolvidos tenham um entendimento compartilhado do que necessita ser entregue. Se o sistema funciona corretamente para todos os principais exemplos, então ele atende a especificação em que todos acordaram. Os principais exemplos definem o que o software precisa fazer. Esses exemplos serão usados como base para o desenvolvimento e também serão um critério de avaliação objetivo para saber quando o desenvolvimento estará pronto.

Refinar a especificação

Criar uma especificação colaborativamente através de exemplos cria um entendimento compartilhado do domínio do negócio, porém resulta em exemplos mais detalhados do que o necessário. Usuários de negócio pensam muitas vezes sobre a perspectiva de interface, logo oferecem exemplos de como algo deve funcionar quando clicam em links e preenchem campos. Esse tipo de descrição restringe o sistema. Detalhar como algo deve ser feito ao invés do que deve ser feito é um total desperdício. Exemplos detalhados fazem com que eles sejam difíceis de comunicar e entender. Os exemplos refinados podem ser usados como critérios de aceitação para a entrega. O desenvolvimento não estará pronto até que o sistema funcione corretamente para todos os exemplos. Depois de prover informação para que todos os principais exemplos sejam fáceis de entender, o time então passa a criar especificações com exemplos, ao qual representa a especificação de trabalho, o teste de aceitação e também futuramente o próprio teste de regressão funcional.

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

Uma vez que o time concorda com as especificações com exemplos e as refina, elas podem ser utilizadas como base para o desenvolvimento e para validar o produto. O sistema será validado muitas vezes com esses testes durante o desenvolvimento para garantir que eles atendam aos objetivos. Como se automatiza a validação sem alterar a especificação, os principais exemplos serão próximos dos mesmos que foram feitos no quadro branco: compreensíveis e acessíveis para todos. Para que tudo isso ocorra, não seria possível automatizar as especificações com uma linguagem muito técnica, pois as tornariam inacessíveis para os usuários de negócio. Existem hoje muitos frameworks que quase não requerem tradução dos principais exemplos. Alguns deles são o Concordion, FitNesse, Cucumber e SpecFlow. Dessa forma, o mesmo documento pode ser usado para buscar esclarecimentos com os usuários de negócio. Se há necessidade de alterar a especificação, isso será feito em um único lugar.

Validar frequentemente

Na maioria das vezes, o código fonte é a única coisa em que se pode confiar. A maioria das documentações ficam desatualizadas antes mesmo do projeto ser entregue. Dessa forma, os programadores passam a ser o gargalo da informação. Especificações executáveis, por outro lado, são fáceis de serem validadas. Se a validação é frequente, então é possível haver tanta confiança na documentação quanto no código fonte de que eles estão fazendo a mesma coisa.

Evoluir a um sistema de documentação

Uma documentação viva, é uma fonte confiável e oficial de informação sobre as funcionalidades do sistema que qualquer pessoa pode acessar. É tão confiável quanto o código, só que muito mais fácil de ler e entender. A equipe de suporte pode usá-la para saber o que o sistema faz e por quê. Os desenvolvedores podem usá-la para desenvolvimento. Testadores podem usá-la para testes. Analistas de negócio podem utilizá-la como ponto de partida para se analisar o impacto de uma mudança em uma funcionalidade. Além de tudo isso, possibilita também o seu uso para teste de regressão.

Testes e especificações são a mesma coisa?

Quando uma especificação é utilizada com muitos exemplos concretos, ela pode ser usada também para testar o sistema. Depois que a especificação é automatizada, ela torna-se um teste de aceitação executável. Dessa forma, especificações e testes são a mesma coisa. Evidentemente que isso não significa que não há outros tipos de teste, como por exemplo, testes exploratórios e testes de usabilidades, porém esses tipos de testes não são especificações.

Quais os efeitos sobre os diferentes papéis na equipe?

Efeitos sobre os analistas de negócio:

  • O papel do analista de negócio está mudando de um transportador de informação para um facilitador que permite as pessoas compartilhar conhecimentos diretamente.
  • O analista de negócio é uma ótima opção para ser o facilitador do workshop de especificação.
  • Trabalhar com teste de aceitação torna o resto do trabalho do analista de negócio mais fácil e mais eficaz.
  • Você ainda pode manter seus documentos tradicionais, mas use os testes de aceitação como especificação oficial.
  • Você pode modificar a especificação (testes de aceitação) quando o desenvolvimento iniciar sem causar grandes problemas para ninguém.
  • Testes não tem que ser perfeitos desde o início.
  • Fazer tudo certo não é só sua responsabilidade. Desenvolvedores e testadores compartilham a responsabilidade pelas especificações.

Efeitos sobre os testadores:

  • O papel principal do teste é ajudar as pessoas a evitar problemas, não descobri-los.
  • O processo de QA não termina com o teste de aceitação ágil. Você pode usar ainda qualquer outra ferramenta ou técnica além dos testes de aceitação.
  • A automação dos testes de aceitação dá a você mais tempo para testar coisas que não podem ser facilmente automatizadas.
  • Testadores tem mais influência em projetos que usam teste de aceitação ágil.
  • Desenvolva sua carreira aprendendo tudo que você possa sobre o domínio durante os workshops de especificação, ou torne-se um especialista em automação.

Efeitos sobre os desenvolvedores:

  • Você não pode escrever testes de aceitação por conta própria.
  • Você precisa participar em discussões sobre o domínio.
  • Workshops de especificação dá a você uma boa chance para discutir casos extremos e inconsistências com especialistas no domínio antes do desenvolvimento.
  • Testes de aceitação não fornecem feedback instantâneo como os testes unitários. Isso é porque eles lidam com o panorama geral e com regras de negócio e não com unidades de código.
  • Você necessita ambos, testes de unidade e testes de aceitação.
  • Testes de aceitação existem para facilitar a comunicação entre as pessoas.
Anúncios