Critérios de Aceitação

Os critérios de aceitação são as condições específicas que um trabalho deve satisfazer para ser considerado concluído. Eles acompanham um requisito ou história de usuário, são acordados antes do início do trabalho e fornecem a base objetiva sobre a qual o resultado é avaliado. Sua função é converter uma descrição geral da intenção em algo que possa ser verificado em vez de debatido.

A ausência desses critérios gera um padrão previsível e dispendioso. O trabalho é descrito em termos gerais, construído segundo a interpretação de uma pessoa e revisado por outra com uma interpretação diferente, momento em que a discordância surge como retrabalho no momento menos conveniente. Escrever os critérios primeiro adia essa discordância para um ponto em que resolvê-la exige uma conversa em vez de uma reformulação completa.

Dois formatos predominam. Uma lista de verificação simples define cada condição que deve ser atendida, o que é adequado para requisitos diretos e rápido de escrever. A estrutura "dado-quando-então", derivada do desenvolvimento orientado a comportamento (BDD), define um contexto inicial, uma ação e um resultado esperado, o que é adequado para comportamentos condicionais e se aplica diretamente a testes automatizados. Nenhum dos dois é inerentemente superior, e a consistência dentro da equipe importa mais do que a escolha.

Os critérios mais valiosos são aqueles que abrangem o que a narrativa omite. O cenário ideal geralmente é óbvio e raramente contestado; as disputas dizem respeito a regras de validação, estados de erro, dados vazios e extremos, limites de permissão, o que acontece quando um serviço externo falha e como o comportamento difere entre dispositivos. As equipes que escrevem critérios apenas para o caso esperado descobrem o restante durante os testes, que é onde o cronograma geralmente é definido.

Os critérios descrevem resultados em vez de implementação, o que preserva a capacidade da equipe de escolher uma abordagem. Afirmar que um usuário deve receber uma confirmação dentro de um período definido é um critério; definir qual tecnologia de fila deve enviá-la é uma decisão de projeto que não pertence a uma declaração de aceitação. Critérios que especificam a implementação restringem as pessoas mais indicadas para decidir sobre ela e frequentemente codificam uma solução que acaba sendo desnecessária.

A rastreabilidade entre critérios e testes é o que impede que os dois divirjam ao longo do tempo. Quando cada critério corresponde a uma verificação, seja ela automatizada ou manual, a cobertura é visível e uma alteração no requisito leva a uma alteração no teste. Quando são mantidos separadamente, os testes gradualmente passam a descrever o que o sistema faz em vez do que ele deveria fazer, o que elimina sua capacidade de detectar regressões em relação à intenção.

Expectativas não funcionais devem constar nos critérios quando forem relevantes e, geralmente, são omitidas. Limiares de desempenho, requisitos de acessibilidade, suporte a navegadores e dispositivos e restrições de segurança são todas condições de aceitação, e deixá-las implícitas significa que serão tratadas de forma inconsistente ou descobertas em uma auditoria posterior. Quando uma equipe tem uma definição compartilhada de "concluído" que abrange todos esses aspectos do trabalho, os critérios individuais precisam apenas especificar os desvios dessa definição.

A elaboração colaborativa é o que traz benefícios, e não o documento em si. Critérios redigidos por uma pessoa e entregues a outros transformam-se em uma especificação; critérios discutidos entre quem deseja a funcionalidade, quem a desenvolve e quem a testa revelam as ambiguidades enquanto ainda são pouco custosos. A discussão frequentemente altera os requisitos, e esse é o objetivo.

Como os critérios definem o que será testado, eles conectam a definição de requisitos diretamente à garantia da qualidade, em vez de tratá-las como etapas sequenciais. Na prática, eles são escritos em desenvolvimento de produtos como parte do aprimoramento, com as condições de usabilidade e acessibilidade definidas pelos padrões estabelecidos por meio de Auditoria de experiência do usuário trabalho, de modo que o que é considerado aceitável reflita a experiência que o produto deve proporcionar, e não apenas seu comportamento funcional.