O que são critérios de aceitação? Como escrever condições com que toda a gente concorda

Os critérios de aceitação são as condições que um trabalho tem de cumprir antes de alguém lhe chamar terminado. São escritos antes de o trabalho começar, por quem o pede, e acordados com quem o vai construir e testar.

A função deles é adiantar uma discussão no tempo. Sem eles, “isto está pronto?” resolve-se depois do trabalho, por quem defender a sua posição com mais força. Com eles, já estava resolvido antes, por pessoas que estavam calmas.

O que não são

Não são uma descrição da funcionalidade. “O utilizador pode filtrar o relatório” é um resumo. Um critério diz o que tem de ser verdade: que filtros, o que acontece quando nenhum corresponde, em que estado fica o ecrã depois de recarregar.

Não são um desenho. Os critérios descrevem resultados, não disposições no ecrã. “Uma lista pendente no canto superior direito” decide a solução e tira-a a quem está em melhor posição para a escolher.

Não são casos de teste. Um critério é uma condição; um caso de teste é um procedimento para verificar uma. De um único critério costumam pender vários casos de teste, e são escritos mais tarde, por alguém que pode não ser a mesma pessoa.

Os dois formatos que se usam

Uma lista de verificação é o mais simples dos dois, e chega para a maior parte do trabalho.

Pronto quando:
- Uma pessoa com sessão iniciada vê apenas as suas próprias encomendas
- Uma encomenda sem linhas aparece à mesma, com um total de 0,00
- A lista carrega em menos de dois segundos numa conta com 10.000 encomendas
- A ordenação por data mantém-se de uma página de resultados para a outra

Dado, quando, então é mais formal, e a cerimónia extra compensa quando o comportamento depende do estado.

Dado um cliente com um cartão expirado
Quando submete o formulário de pagamento
Então o pagamento é recusado
E os campos do cartão mantêm os valores que introduziu
E a mensagem diz que campo é preciso corrigir

O valor está no dado. A maior parte dos mal-entendidos vive no estado de partida - uma conta de experiência, um token expirado, uma lista vazia - e não na acção, e o formato obriga alguém a nomeá-lo.

Nenhum dos dois é melhor. Usem a lista de verificação por omissão e recorram a dado-quando-então onde a mesma acção tem de se comportar de maneira diferente conforme a situação.

O que separa um bom critério de um mau

O teste é se duas pessoas podiam discordar sobre se está cumprido.

Fraco

A página deve carregar depressa e mostrar resultados relevantes

Melhor

A primeira página de resultados aparece em menos de dois segundos numa conta com 10.000 encomendas, e mostra apenas as encomendas dessa conta

Quatro hábitos produzem quase todos os fracos:

• Adjectivos em vez de limiares. Rápido, intuitivo, robusto, fácil de usar. Nenhum se pode verificar; sobre todos se pode discutir.
• Só o caminho feliz. Critérios que descrevem o que acontece quando tudo funciona deixam cada falha ao critério de alguém às quatro da tarde do dia do lançamento.
• Soluções. “Acrescentar uma janela de confirmação” em vez de “o utilizador não pode apagar uma factura sem confirmar”.
• Tudo de uma vez. Uma história com dezanove critérios são várias histórias, e vai ficar a meio durante quinze dias.

Quem os escreve, e quando

Quem pede o trabalho é que os redige, e são acordados antes de alguém começar. É a parte que as equipas saltam, e saltá-la é o que transforma uma tarefa de dois dias numa semana de esclarecimentos.

Não tem de ser pesado. Um programador que lê o rascunho e pergunta “o que deve acontecer se ainda não tiver encomendas nenhumas?” é o processo inteiro a funcionar: a pergunta é barata agora e cara depois de o código existir.

Escrevam-nos onde vive o trabalho, não numa mensagem de chat. Critérios que só existem na lembrança que alguém tem de uma reunião produzem exactamente a discussão que vinham evitar.

Onde acabam por contar

Dois sítios, e são a razão por que vale o esforço.

A aceitação. Quem faz os testes de aceitação precisa de alguma coisa contra a qual aceitar. Sem critérios, aquilo torna-se um inquérito de opiniões sobre software que alguém já pagou.

A triagem de erros. A discussão mais maçadora do software é se uma coisa é um defeito ou um pedido de alteração, e é decidida pelo que foi acordado. Um defeito é um comportamento que contradiz um critério; tudo o resto é um pedido novo, por muito razoável que seja. As equipas sem critérios escritos têm essa discussão uma vez por lançamento, para sempre.

É também por isso que o relatório de um defeito deve dizer o que era esperado além do que aconteceu - é a mesma frase que o critério que contradiz.

O guia de relatórios de erro cobre o resto do que esse relatório precisa, e o seu modelo tem uma linha para o comportamento esperado.

A versão curta

Condições, escritas antes do trabalho, acordadas entre quem o pediu e quem o vai construir, suficientemente concretas para que duas pessoas não possam discordar sobre se estão cumpridas. Uma lista de verificação costuma chegar; dado-quando-então quando o estado de partida decide o resultado. Cubram o que acontece quando as coisas falham, não só quando funcionam.