Histórias de usuário e critérios de aceite: Os sustentadores da qualidade de software
Hoje, quando pensamos em qualidade de software, já imaginamos automação de testes funcionais/performance/integração/unitário, porém devemos antes notar que não adianta pensar em automação se não temos bem definidos o que será testado. Neste ponto que entra a importância de criar histórias e critérios de aceite de forma a possibilitar a implementação correta da automação dos testes.
Devemos lembrar que o incremento da qualidade de software não esta apenas no final do fluxo de desenvolvimento, mas sim, permeia todas as fases do processo. Conforme podemos observar na figura abaixo, quanto antes o defeito é encontrado, maior a velocidade e menor o custo em sua correção.
Deste modo, quando pensamos em qualidade de software, devemos iniciar os trabalhos pela especificação correta das histórias e critérios de aceite, sendo que estes, serão base para os futuros processos de qualidade no fluxo de desenvolvimento.
Mas, como fazer isso ?
Primeiro vamos falar das histórias de usuário (User stories)
As histórias de usuário são representações das funcionalidades que o sistema deve possuir, são o fundamento da construção do software e devem ser escritas pelo PO (product owner) com apoio dos stakeholders da aplicação. O conceito de história de usuário vem do XP (eXtreme Programming), sua ideia é padronizar e implementar uma linguagem simples e organizada para a escrita das funcionalidades.
O que uma boa história deve ter ?
Em 2001, a Connextra lançou o formato de escrita de história:
Como (papel), eu quero (ação) e para (por quê).
Seguindo este formato na escrita de histórias, devemos responder as três perguntas:
Quem se beneficia ? Parte interessada que se beneficia da história do usuário (Papel). Esta informação serve para detalhar as permissões a esta funcionalidade.
O quê se quer ? Visão de alto nível da funcionalidade para o usuário (ação). Aqui falaremos da funcionalidade propriamente dita.
Qual é o benefício? O valor de negócio que a história proporciona ( Por quê). Esta informação tem grande utilidade na priorização da estória.
Um modo muito legal e rápido para avaliar a qualidade de uma história é utilizar a formula dos três C . Consideramos uma história bem escrita quando está atende as seguintes características:
Cartão : Não é grande demais , cabe em um cartão.
Conversação: Facilita a comunicação entre o usuário e a squad, proporcionando um entendimento em comum da funcionalidade.
Confirmação: Possui critérios de aceite suficientes para a confirmação da funcionalidade.
Um outro método de avaliação muito utilizado é o I.N.V.E.S.T .
A história deve ser :
- Independente: Toda história de usuário deve ser independente de outras histórias.
- Negociável: Lembre-se toda história de usuário é apenas um desejo do usuário, logo, pode considerar ela sendo apenas um ponto de partida. Portanto, deve ser totalmente negociável.
- Valiosa: Deve representar valor de negócio, sempre. Sem valor de negócio não faz sentindo existir, é simples assim.
- Estimável: O time deve ser capaz de estima-la.
- Pequena (Small): Deve ser pequena e assim reduzindo as incertezas e dificuldades de estimativas.
- Testável: Todas histórias de usuário devem ser testáveis, ou seja, deve ser possível validar se atingem os critérios de aceitação.
Como identificar uma história ruim :
É muito comum observamos os exemplos abaixo, porém, devem ser evitados por que trazem dificuldade no desenvolvimento da funcionalidade. Devemos observar que as estórias não devem ser :
Muito grande: É muito comum observar estórias que são o agrupamento de muitas funcionalidades, resultando em confusão e dificuldades de desenvolver e testar.
Não proporciona comunicação: A história é utilizada como um documento funcional, servindo de desculpa para não existir a comunicação entre PO e DEV. A história de usuário não substitui a comunicação do time!
Muito técnicas: A história é a representação de uma necessidade do cliente, desta forma, devemos falar sobre como esta modificação técnica vai trazer benefícios ao negócio, facilitado a sua priorização e entendimento. Não devemos escrever história como:
Podemos escrever esta mesma história preservando a visão do negócio :
Quais destas seria mais fácil de priorizar o desenvolvimento ? Obviamente a segunda, pois aqui podemos facilmente entender qual o beneficio na sua implementação.
Sem valor de negocio : A entrega desta história não resultar em nenhum valor para o cliente, temos que tomar cuidado quando desagregamos funcionalidades de uma história, para que esta não fique sem sentido na visão do negócio.
Critérios de aceite: O fundamento da qualidade
A história pode estar muito bem escrita, porém, se esta não tiver critérios de aceite bem definidos, podem ter certeza que teremos problemas no desenvolvimento. Os critérios de aceite, irão definir o comportamento da funcionalidade a serem desenvolvidas, permitindo desta forma que todos os membros da squad possam equalizar o entendimento.
O critério de aceite, vai determinar qual o comportamento que deve ser observado após o desenvolvimento de determinada história, para esta ser aceita. São os famosos cenários de testes em que o usuário quer ver executado após a conclusão do desenvolvimento, de modo a validar se a história foi implementada de acordo. Por isso o nome critério de aceite.
A escrita correta traz os seguintes benefícios :
- Prover material para a equipe pensar em como uma funcionalidade será executada pelo ponto de vista do usuário.
- Eliminar ambiguidades quanto aos requisitos.
- Confirmar que a história está completa e funcionando.
- Garantir maior satisfação do usuário.
- Os cenários que serão testados no final já são de conhecimento de todo o time desde o início do processo.
Importante entender que critérios de aceite são diferentes do D.O.D (Definition of Done)
D.O.D determina quais atividades devem ser realizadas em determinada história para a conclusão da mesma.
Como criar um bom critério de aceite ?
Primeiro precisamos entender que a função do critério é informar o comportamento esperado de determinada história. Na escrita, devemos exercitar os comportamentos diferentes que podem ocorrer em cenários positivos, negativos e usabilidade da história. Não devemos ter medo de escrever muitos critérios de aceite, pois estes fornecerão os detalhes tão necessários para evitar problemas no desenvolvimento.
Na escrita do critério de aceite, utilizamos a linguagem gherkin e a técnica BDD (Behavior Driven Development), esta prática, leva a squad a pensar no comportamento do sistema para entender o que fazer antes de escrever qualquer linha de código.
Para a escrita utilizaremos as palavras dado, que e então :
Dado (Pré-condição do cenário, em que ponto ele se inicia)
Quando (Ação que está sendo desempenhada)
Então (Resultado esperado de suas ações )
Vamos analisar a seguinte história de usuário :
Devemos pensar, quais os comportamentos esperados que a funcionalidade terá, não apenas os positivos, mas também, como deve-se comportar em cenário de erro. Pois, é tão importante liberarmos um acesso para um usuário permitido, quanto é negarmos o acesso para um não permitido.
Devemos evitar de detalhar muito o cenário, pois estamos seguindo o BDD e não o BDT(Desenvolvimento orientado a testes). Precisamos nos focar no comportamento da funcionalidade.
Pode ser incluído também pelo líder técnico ou arquiteto da squad, critérios de aceite técnicos validando itens do desenvolvimento, como por exemplo, criação de serviços ou modelagem do banco de dados.
E por ultimo mas não menos importante os critérios de aceitem podem ser modificados, acrescentados e removidos no decorrer do ciclo de desenvolvimento da estória. Atualizar os critérios de aceite no decorrer da evolução da história evita possíveis “surpresas” na homologação do usuário.
Conclusão:
As estórias de usuário e os critérios de aceite, são a base da qualidade no ciclo de desenvolvimento, eles nos ajudam a entender o comportamento da aplicação de modo a antecipar possíveis defeitos que apenas seriam encontrados apenas na homologação do usuário. Antecipar problemas, agir na profilaxia dos defeitos é melhor do que passar a noite em claro corrigindo um erro de produção. A qualidade de software, não é apenas testar e automatizar, mas sim, agir em todos os steps do ciclo do software prevendo e atuando no problema o mais rápido possível! Escrever história e critérios de aceite da maneira correta é o segredo para o sucesso de uma squad!
