“O entendimento é o conhecimento do mal entendido”
~ Zivarnna Smithies
Os critérios de aceitação devem ser implícitos
Todas as coisas na vida são implícitas. Quando minha esposa pergunta ‘você pode ir ao mercado e comprar um pouco de leite’, ela também não tem que me dizer ‘e não compre nada mais’, ‘e certifique-se que é de 2 litros de leite de vaca não pasteurizado homogeneizado com 2% de gordura’, ‘tenha certeza que está refrigerado’ e ‘pague em dinheiro e use nosso cartão de desconto’. Este são os critérios implícitos de nosso conhecimento compartilhado.
Os critérios de aceitação são a mesma coisa. Se eu tivesse que descrever explicitamente cada critério de aceitação para toda história; escrever critérios de aceitação seria uma tarefa sem fim.
Recentemente eu tenho, relutantemente, passado a incluir os critérios de aceitação que realmente devem ser implícitos: ‘a página tem título’, ‘as páginas passam nos critérios WAVE de acessibilidade’, etc. Mas onde você traça a linha que delimita o que é implícito? Em seguida estarei escrevendo “funciona em um navegador web”, e “funciona na internet”.
Mantenha os critérios de aceitação focados no que é necessário, não no que é óbvio.
Os critérios de aceitação devem ser explícitos
“Vale a pena ser óbvio, especialmente se você tem uma reputação para sutileza.”
~ Isaac Asimov
“O óbvio é aquilo que nunca é visto até que alguém expresse isso de forma simples.”
~ Kahlil Gibran
Se você não tem critérios de aceitação explícitos, então pode ser muito difícil determinar se o que foi desenvolvido está realmente completo.
Quanto mais esforço você colocar em escrever critérios de aceitação claros e explícitos você será melhor recompensado ao receber uma história que tem todas as funcionalidades exigidas incluídas nela. Isto significa menos retrabalho, pois cada vez que você encontrar um bug induzido pelo critério de aceitação isto significa que o programador tem que mudar de contexto para fixa-lo, o que é menos tempo trabalhando em uma nova história.
Conduzir uma iniciação de história de usuário com o programador antes do desenvolvimento, e poder rodar testes automatizados sobre todo o sistema assim que o desenvolvimento é concluído é uma excelente maneira de garantir que o critério de aceitação que você escreveu é explícito, e que foi implementado exatamente como pretendido.
Mesmo que algumas coisas sejam requisitos óbvios (ex.: ‘a página passa nos critérios WAVE de acessibilidade’), estes são frequentemente esquecidos, então se paga ter uma lista padronizada de critérios de aceitação comuns incluídos em cada história de usuário.
Tradução/Adaptação do livro Pride and Paradev, de Alister Scott.
Ainda sobre os critérios de aceitação… eles devem ser especificados como Dado/Quando/Então ou como checklists?
TALKING ABOUT TESTING 