Critérios de Aceitação Dado-Quando-Então Explicados
Formato: Os critérios dado-quando-então definem um comportamento de software claro e testável, promovendo um entendimento partilhado entre os membros da equipa.
Estrutura: Cada cenário neste formato inclui o contexto, a ação do utilizador e o resultado esperado, numa linguagem simples.
Boas Práticas: Dê prioridade à simplicidade, à colaboração e ao detalhe para melhorar a clareza dos critérios de aceitação.
Erros Comuns: Evite juntar cenários, escrever detalhes técnicos e ignorar casos extremos.
Os critérios de aceitação dado-quando-então (GWT) proporcionam uma forma simples e testável de descrever como o software deve comportar-se, para que programadores, testadores e partes interessadas tenham um entendimento comum. Quando os critérios de aceitação são vagos, as equipas perdem tempo a debater requisitos, a criar a solução errada e a descobrir lacunas numa fase tardia do desenvolvimento.
Neste guia, vou explicar detalhadamente o formato dado-quando-então, apresentar exemplos reais em cenários comuns, compará-lo com outras abordagens aos critérios de aceitação e partilhar as práticas que ajudam as equipas ágeis a escrever histórias de utilizador mais claras e eficazes.
O que são os critérios de aceitação dado-quando-então?
Dado-quando-então é um modelo de três partes para escrever critérios de aceitação numa história de utilizador. Cada cenário descreve uma parte do comportamento esperado numa linguagem simples, que programadores, testadores e partes interessadas conseguem ler.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Eis como funciona a estrutura:
- Dado indica o que já tem de ser verdade antes de o utilizador final fazer qualquer coisa.
- Quando introduz a ação. É aquilo que o utilizador faz ou o evento que o sistema desencadeia.
- Então revela o resultado. É o resultado que prova que o sistema respondeu corretamente.
Como escrever critérios de aceitação dado-quando-então
Como escrever cada cláusula para que seja consistente durante o desenvolvimento e os testes de software.
Dado: definir o contexto e as pré-condições
A cláusula dado descreve o que já tem de ser verdade. Isto inclui o estado do sistema, a função do utilizador, as condições dos dados e a configuração do ambiente. As afirmações dado fortes são específicas. Evite escrever "Dado que o utilizador tem sessão iniciada" quando o cenário depende da função. Em vez disso, escreva "Dado que um cliente registado com uma subscrição válida se encontra na página de definições da conta".
Eis algumas orientações para escrever a cláusula dado:
- Indique a função ou a persona do utilizador quando for relevante.
- Indique condições do sistema, como sinalizadores de funcionalidades, estados dos dados ou conectividade.
- Combine várias pré-condições com "E", em vez de as incluir à força numa única cláusula.
Quando: definir a ação ou o acionador
A cláusula quando regista a ação ou o evento que desencadeia o comportamento que está a testar. Deve descrever uma interação do utilizador ou um evento do sistema, e não uma sequência. Utilize a voz ativa. Escreva "Quando o cliente clica em 'Aplicar cupão'" em vez de "Quando o botão do cupão é clicado". Isto elimina a ambiguidade sobre quem executa a ação.
Mantenha esta cláusula concisa. Se precisar de mais do que uma afirmação quando, é provável que esteja a descrever dois cenários distintos. Separe-os.
Então: especificar o resultado esperado
A cláusula então indica o que o utilizador deve observar ou o que o sistema deve fazer depois da ação. Descreva resultados observáveis. "Então o painel é carregado" é uma formulação fraca. "Então o sistema apresenta o painel do cliente no prazo de dois segundos" é testável. Inclua detalhes como mensagens de erro, destinos de redirecionamento, alterações nos dados, acionadores de e-mail ou alterações do estado da interface.
Utilize E para encadear vários resultados quando uma única ação produz mais do que um resultado observável. Por exemplo, "Então a página de confirmação da encomenda é apresentada" E "o cliente recebe um e-mail de confirmação no prazo de 60 segundos".
Exemplos de dado-quando-então
Eis alguns exemplos de critérios de aceitação dado-quando-então em diferentes áreas.
Início de sessão do utilizador
Cenário 1: início de sessão bem-sucedido com credenciais válidas
Dado que um utilizador registado se encontra na página de início de sessão Quando o utilizador introduz um e-mail válido e a palavra-passe correta e clica em "Iniciar sessão" Então o sistema redireciona o utilizador para o painel da sua conta
A cláusula dado é deliberadamente simples neste caso, porque o cenário não depende do nível da subscrição nem do estado da conta. Repare na cláusula quando composta: introduzir as credenciais e clicar num botão é uma única ação lógica (submeter um formulário de início de sessão), por isso mantenho tudo junto em vez de dividir cada pressão de tecla num cenário separado.
Cenário 2: início de sessão falhado com credenciais inválidas
Dado que um utilizador registado se encontra na página de início de sessão Quando o utilizador introduz um e-mail válido e uma palavra-passe incorreta e clica em "Iniciar sessão" Então o sistema apresenta a mensagem "E-mail ou palavra-passe inválidos" E o utilizador permanece na página de início de sessão
A cláusula Então especifica o texto exato da mensagem de erro. A segunda cláusula E é importante porque confirma que o utilizador não é redirecionado acidentalmente para outro local.
Carrinho de compras e finalização da compra
Cenário 1: Adicionar um artigo ao carrinho
Dado que um cliente está a consultar a página de detalhes de um produto disponível em stock Quando o cliente clica em "Adicionar ao carrinho" Então o ícone do carrinho é atualizado para mostrar um artigo E é apresentada uma mensagem de confirmação com o texto "Artigo adicionado ao carrinho"
A cláusula Dado inclui "disponível em stock" porque o comportamento é diferente para artigos esgotados, sendo esse um cenário separado.
Cenário 2: Aplicar um código de desconto válido
Dado que um cliente tem dois artigos no carrinho, num total de $80.00 Quando o cliente introduz o código de desconto "SAVE20" e clica em "Aplicar" Então o sistema aplica um desconto de 20% E o total do carrinho é atualizado para $64.00
Os valores monetários específicos tornam impossível qualquer interpretação errada. Este tipo de cenário de desconto pode ajudar a detetar um erro de arredondamento em produção, em que um desconto percentual sobre um total não inteiro produzia um preço com três casas decimais. É a precisão na cláusula Dado ($80.00) e na cláusula Então ($64.00) que torna o cenário valioso.
Recuperação da palavra-passe
Cenário 1: Solicitar a reposição da palavra-passe com um e-mail registado
Dado que um utilizador se encontra na página de início de sessão Quando o utilizador clica em "Esqueci-me da palavra-passe", introduz um endereço de e-mail registado e clica em "Enviar" Então o sistema apresenta a mensagem "Foi enviada uma ligação de reposição para o seu e-mail" E o sistema envia um e-mail de reposição da palavra-passe no prazo de 60 segundos
O quando composto representa aqui um único fluxo lógico: solicitar uma reposição. A restrição temporal de 60 segundos na cláusula Então é fundamental. Sem ela, um e-mail de reposição que chegasse 20 minutos mais tarde seria tecnicamente considerado "bem-sucedido". Os resultados condicionados pelo tempo são um dos detalhes mais frequentemente omitidos.
Cenário 2: Utilizar uma ligação de reposição expirada
Dado que um utilizador recebeu um e-mail de reposição da palavra-passe há mais de 24 horas Quando o utilizador clica na ligação de reposição existente no e-mail Então o sistema apresenta a mensagem "Esta ligação expirou. Solicite uma nova reposição."
A cláusula Dado inclui uma condição temporal, o que obriga a discutir qual deve ser o período de validade.
Validação de formulários
Cenário 1: Submeter um formulário com campos obrigatórios em falta
Dado que um utilizador se encontra no formulário de registo Quando o utilizador deixa o campo "E-mail" em branco e clica em "Enviar" Então o sistema apresenta a mensagem de erro em linha "O e-mail é obrigatório" abaixo do campo E-mail E o formulário não é submetido
A cláusula Então especifica onde aparece o erro ("abaixo do campo E-mail"), e não apenas que este aparece.
Cenário 2: Exceder o limite de caracteres num campo de texto
Dado que um utilizador está a preencher o campo "Biografia", com um limite de 500 caracteres Quando o utilizador introduz 501 caracteres Então o sistema impede a introdução de mais caracteres E é apresentada a mensagem "São permitidos no máximo 500 caracteres"
GWT vs. Listas de verificação vs. Casos de utilização
Eis alguns outros tipos de critérios de aceitação e os casos em que poderá utilizar cada um:
| Aspeto | Dado-Quando-Então | Lista de verificação orientada por regras | Caso de utilização |
|---|---|---|---|
| Estrutura | Dado, Quando, Então | Lista de regras com marcadores | Passos numerados com fluxos |
| Mais adequado para | Cenários comportamentais, BDD | Regras de negócio, especificações de IU | Funcionalidades complexas com vários fluxos |
| Pontos fortes | Testável, automatizável, rico em contexto | Rápido de escrever, fácil de consultar | Abrangente, cobre casos-limite |
| Limitações | Extenso para alterações simples | Sem fluxo de cenário, difícil de automatizar | Pesado, lento de manter |
| Público-alvo | Desenvolvimento, QA, produto | Produto, design, partes interessadas | Equipas externas, conformidade |
| Âmbito | Um único comportamento | Toda a funcionalidade | Toda a funcionalidade |
| Nível de detalhe | Três cláusulas | Flexível | Pré-condições, pós-condições, acionadores e passos numerados |
Verifiquei que os casos de utilização funcionam melhor quando é necessário documentar um sistema para fins de conformidade regulamentar ou entregá-lo a um fornecedor externo. Para o trabalho diário dos sprints, o formato dado-quando-então é mais simples e rápido.
Boas práticas do Dado-Quando-Então
Eis algumas boas práticas para o ajudar a utilizar GWT de forma eficaz:
- Evite linguagem vaga ou ambígua: Em vez de “Então, a página carrega rapidamente”, escreva “Então, a página de resultados da pesquisa carrega em menos de dois segundos.” Substitua adjetivos como “adequado” ou “relevante” por valores mensuráveis. Se não puder testá-lo, reformule-o.
- Mantenha os cenários simples e focados: Siga a regra de um comportamento por cenário. Cada cenário deve testar exatamente uma coisa. Quando combina várias ações ou resultados, cria casos de teste difíceis de depurar e manter. Se um cenário tiver mais de duas instruções «E» na secção «Então», pergunte a si próprio se está a testar um comportamento ou dois.
- Realize uma sessão dos três amigos: Uma sessão dos três amigos é uma conversa curta e focada na qual uma pessoa de produto (proprietário do produto ou analista de negócio), um programador e um testador analisam em conjunto as histórias futuras antes do início do sprint. Escrevem ou aperfeiçoam os critérios GWT em grupo, o que evita retrabalho.
- Mantenha a consistência na terminologia e no estilo: Escolha termos padrão e mantenha-os em todas as histórias. Se utilizar “cliente” num cenário e “utilizador” noutro, criará confusão. Crie um pequeno glossário, se necessário. Utilize a mesma estrutura de frase nas suas cláusulas.
Cinco antipadrões comuns
Eis alguns erros comuns a evitar ao escrever critérios de aceitação no formato dado-quando-então:
- Escrever detalhes de implementação em vez de comportamento: Cenários como "Dado que a chamada à API devolve um código de estado 200" descrevem a implementação técnica, não o comportamento do utilizador. Reescreva na perspetiva do utilizador: "Dado que o catálogo de produtos foi carregado na página inicial." Guarde os detalhes técnicos para o código de automatização de testes.
- Incluir vários cenários num só: Um cenário que testa o início de sessão, a navegação e o processo de compra num único bloco é um teste de integração, não um critério de aceitação. Divida cada comportamento no seu próprio cenário. Obterá resultados mais claros e uma depuração mais fácil.
- Ignorar cenários negativos e casos-limite: As equipas de desenvolvimento ágil escrevem frequentemente o percurso de sucesso e esquecem o que acontece quando algo corre mal. Para cada cenário bem-sucedido, pergunte: e se a entrada for inválida? E se a rede falhar? E se os dados estiverem em falta? Escreva pelo menos um cenário negativo por história para detetar problemas antes de chegarem à produção.
- Tratar o GWT como o único formato aceitável: Utilize o GWT para o comportamento e listas de verificação para tudo o resto. Se obrigar todas as histórias a seguir o formato dado-quando-então, incluindo alterações à cor dos botões, atualizações de texto e configuração da infraestrutura, acabará com alguns resultados absurdos (por exemplo, “Dado que a página inicial existe, Quando o utilizador a visualiza, Então o tipo de letra do cabeçalho tem 16px”).
- Escrever cenários isoladamente: Não escreva os critérios GWT sozinho. O valor do formato advém da conversa que provoca. Se os seus cenários não forem discutidos por, pelo menos, duas disciplinas antes do início do desenvolvimento do software, está a utilizar o GWT como formato de documentação, quando o seu verdadeiro poder reside em ser um formato de colaboração.
O que se segue?
Critérios de aceitação claros no formato dado-quando-então são apenas uma parte da concretização de projetos bem-sucedidos. Desenvolva essa base com uma adesão gratuita à DPM e obtenha acesso a modelos práticos, recursos especializados e estruturas comprovadas que ajudam a transformar requisitos bem definidos numa execução mais simples e em resultados mais sólidos.
