Critérios de Aceitação

Sobre este documento

Formato BDD (Behaviour Driven Development):
Given (Dado que) — o contexto / estado inicial do sistema antes da ação.
When (Quando) — a ação que o ator executa.
Then (Então) — o resultado esperado, observável e verificável.

Cada cenário deve ser independente, atômico e testável por uma pessoa que não participou da escrita.

Histórias e Critérios de Aceitação

US-001

Login no sistema

Aprovado

História de usuário

Como colaborador cadastrado,
Quero fazer login com meu e-mail e senha,
Para que eu possa acessar o sistema de forma segura e ver as funcionalidades do meu perfil.

Cenários BDD

Cenário 1 — Login com credenciais válidas Caminho feliz

Cenário: Usuário se autentica com sucesso

Dado que o usuário está na tela de login

E que possui uma conta ativa com e-mail "usuario@empresa.com"

Quando insere o e-mail e senha corretos

E clica no botão "Entrar"

Então deve ser redirecionado ao painel inicial do seu perfil

E deve visualizar a mensagem "Bem-vindo, [Nome]"

Cenário 2 — Credenciais inválidas Cenário negativo

Cenário: Sistema rejeita credenciais incorretas

Dado que o usuário está na tela de login

Quando insere e-mail ou senha incorretos

E clica no botão "Entrar"

Então deve permanecer na tela de login

E deve ver a mensagem "E-mail ou senha incorretos"

E o número de tentativas restantes deve ser decrementado

Cenário 3 — Bloqueio após múltiplas tentativas Regra de negócio

Cenário: Conta bloqueada após 5 tentativas inválidas

Dado que o usuário errou a senha 4 vezes consecutivas

Quando insere a senha incorreta pela 5ª vez

Então a conta deve ser bloqueada por 15 minutos

E deve exibir "Conta bloqueada. Tente novamente após [horário]"

E um e-mail de alerta deve ser enviado ao endereço cadastrado

Definition of Done (DoD)

Todos os cenários BDD acima passam nos testes automatizados
Testado nos browsers: Chrome, Edge e Firefox (versões atuais)
Testado em mobile (iOS Safari e Android Chrome)
Log de acesso registrando IP, data e hora confirmado pelo time de QA
Aprovado pelo PO em ambiente de homologação
Sem regressões em funcionalidades relacionadas

US-[00X]

[Nome descritivo da história — use verbos de negócio]

A revisar

História de usuário

Como [tipo de usuário — seja específico: não "usuário", mas "gerente financeiro"],
Quero [ação / funcionalidade desejada],
Para que [benefício de negócio — o "porquê" justifica a história; sem ele, questione se vale a pena construir].

Cenários BDD

Cenário 1 — [Nome do cenário — caminho feliz] Caminho feliz

[Título descritivo do cenário]

Dado que [contexto inicial — estado do sistema e do usuário]

E que [condição adicional se necessário]

Quando [ação executada pelo usuário]

E [ação adicional se necessário]

Então [resultado observável e verificável]

E [resultado adicional se necessário]

Cenário 2 — [Cenário negativo / edge case] Cenário negativo

[Título do cenário negativo]

Dado que [contexto de erro ou situação limite]

Quando [ação do usuário]

Então [como o sistema deve responder ao erro — mensagem, estado, ação]

Definition of Done (DoD)

[Critério específico e verificável — ex.: "Todos os cenários BDD passam nos testes"]
[Critério de qualidade — ex.: "Testado nos browsers X, Y, Z"]
[Critério de integração — ex.: "Dados salvos corretamente no banco"]
[Critério de aprovação — ex.: "Aprovado pelo PO em homologação"]
Sem regressões em funcionalidades relacionadas
Código revisado (code review aprovado)

Regras de negócio transversais

ID	Regra	Histórias impactadas
`RN-001`	[Ex.: "Qualquer ação realizada por usuário deve ser registrada em log com data, hora e ID do usuário."]	Todas as histórias
`RN-002`	[Regra de negócio que afeta múltiplas histórias]	[US-XXX, US-YYY]