Testes de Aceitação: O que São, Quem os Faz e Como

O acceptance testing significa pelo menos três coisas diferentes dependendo de quem faz e quando. UAT é o processo de stakeholders de negócio confirmando requisitos antes da aprovação final. ATDD são testes executáveis escritos antes do desenvolvimento começar. Functional acceptance testing é o QA verificando que o spec foi totalmente implementado. Os modos de falha que importam: testar tarde demais, envolver as pessoas erradas, e escrever critérios vagos o suficiente para gerar discussão.

O Que Acceptance Testing Realmente Significa

O termo cobre vários conceitos relacionados:

Na prática, "acceptance testing" geralmente significa uma de duas coisas: UAT feito por pessoas de negócio, ou functional acceptance testing feito pelo QA contra os requisitos formais.

Critérios de Aceitação: A Base

O acceptance testing começa com os critérios de aceitação: as condições específicas que uma funcionalidade precisa atender para ser considerada completa.

A página de login deve funcionar corretamente.

- Usuários podem fazer login com e-mail e senha válidos e são redirecionados para o dashboard

- Se o e-mail ou senha estiverem errados, aparece a mensagem de erro "Invalid email or password"

- Após 5 tentativas falhas em 10 minutos, a conta é bloqueada e aparece a mensagem "too many attempts"

- Login bem-sucedido cria uma sessão que expira após 24 horas de inatividade

- O link "Forgot password" na página de login envia um e-mail de redefinição em até 2 minutos

Bons critérios são específicos, testáveis e sem ambiguidade.

Escrevendo Critérios de Aceitação com Gherkin

Gherkin é uma linguagem estruturada para escrever critérios de aceitação no formato Given/When/Then. É legível por stakeholders não técnicos e executável por ferramentas como Cucumber:

Feature: User Login

  Scenario: Successful login with valid credentials
    Given I am on the login page
    When I enter "user@example.com" as email
    And I enter "ValidPass1" as password
    And I click the "Sign In" button
    Then I should be redirected to the dashboard
    And I should see "Welcome, Test User" in the header

  Scenario: Login with invalid credentials
    Given I am on the login page
    When I enter "user@example.com" as email
    And I enter "WrongPassword" as password
    And I click the "Sign In" button
    Then I should see "Invalid email or password"
    And I should remain on the login page

  Scenario: Account lockout after failed attempts
    Given I am on the login page
    When I enter "user@example.com" with wrong password 5 times
    Then I should see "Too many failed attempts. Try again in 10 minutes."
    And the Sign In button should be disabled

Processo de UAT: Passo a Passo

1. Definir o escopo do teste

Quais funcionalidades estão incluídas neste ciclo de UAT? Geralmente ligado a uma release ou sprint.

2. Escrever cenários de teste com usuários de negócio

Envolva os usuários reais ou product owners na criação dos cenários. Eles sabem como é o "correto" do ponto de vista do negócio.

3. Preparar o ambiente

O UAT deve rodar num ambiente próximo ao de produção: mesmos dados, mesmas integrações, mesma configuração. O notebook de um desenvolvedor não é um ambiente de UAT.

4. Criar dados de teste

Os usuários precisam de dados de teste realistas que representem seus casos de uso reais, não apenas "test@test.com" com "test123" como senha.

5. Executar os testes

O ideal é que usuários reais rodem os testes. Se não for possível, o QA os executa, mas os critérios de aceitação precisam ser definidos pelos stakeholders de negócio, não pelo QA.

6. Documentar resultados

Cada teste recebe um status de aprovado/reprovado. As falhas viram bug reports com passos para reproduzir.

7. Corrigir e retestar

Bugs encontrados no UAT voltam para os desenvolvedores. O QA retesta depois que forem corrigidos.

8. Aprovação formal

Os stakeholders de negócio aprovam formalmente a release. Sem aprovação, não se faz deploy.

UAT vs Testes de QA

| Aspecto | Testes de QA | UAT |

|---------|-------------|-----|

| Quem faz | Engenheiros de QA | Usuários de negócio / product owners |

| Objetivo | Encontrar bugs | Confirmar que os requisitos foram atendidos |

| Foco | Correção técnica | Valor para o negócio |

| Quando | Durante o desenvolvimento | Antes da release |

| Critérios | Casos de teste | Critérios de aceitação |

| Aprovação | QA lead | Stakeholder de negócio |

Ambos são necessários. O QA encontra os bugs antes do UAT para que os usuários de negócio não fiquem caçando problemas básicos.

Modos de Falha Comuns no Acceptance Testing

UAT agendado 2 dias antes da release sem margem para correções. Todo bug encontrado vira uma crise.

Fazer UAT com desenvolvedores invalida o propósito. Eles sabem como o código funciona e não vão testá-lo como um usuário.

"O checkout deve ser tranquilo" gera discussões sobre o que "tranquilo" significa quando bugs aparecem.

UAT num servidor de desenvolvimento com dados de teste que não refletem volumes ou integrações reais vai deixar bugs reais passarem.

Bug encontrado no UAT, corrigido, publicado, mas ninguém verifica se a correção quebrou algo mais.

Acceptance Testing Automatizado

Você pode automatizar acceptance tests com Playwright:

// acceptance/login.spec.ts
import { test, expect } from '@playwright/test';

test.describe('Login — Critérios de Aceitação', () => {
  test('CA1: Credenciais válidas redirecionam para o dashboard', async ({ page }) => {
    await page.goto('/login');
    await page.fill('[data-testid="email"]', 'user@test.com');
    await page.fill('[data-testid="password"]', 'ValidPass1');
    await page.click('[data-testid="submit"]');
    
    await expect(page).toHaveURL('/dashboard');
    await expect(page.getByTestId('welcome')).toContainText('Welcome');
  });

  test('CA2: Credenciais inválidas mostram mensagem de erro', async ({ page }) => {
    await page.goto('/login');
    await page.fill('[data-testid="email"]', 'user@test.com');
    await page.fill('[data-testid="password"]', 'SenhaErrada');
    await page.click('[data-testid="submit"]');
    
    await expect(page.getByTestId('error-message')).toHaveText('Invalid email or password');
    await expect(page).toHaveURL('/login');
  });

  test('CA3: Sessão expira após 24h de inatividade', async ({ page, context }) => {
    // Normalmente testado com mock de tempo ou manipulação de API
    await page.goto('/login');
    await page.fill('[data-testid="email"]', 'user@test.com');
    await page.fill('[data-testid="password"]', 'ValidPass1');
    await page.click('[data-testid="submit"]');
    
    // Simula expiração de sessão via API
    await page.request.post('/api/auth/expire-session');
    await page.reload();
    
    await expect(page).toHaveURL('/login');
  });
});

Checklist de Acceptance Testing

Antes de começar o UAT:

• [ ] Critérios de aceitação escritos e revisados pelo negócio
• [ ] Funcionalidade publicada no ambiente de UAT (não em dev ou staging)
• [ ] Dados de teste preparados (realistas, não triviais)
• [ ] Usuários de negócio orientados sobre o que testar
• [ ] Processo de registro de bugs estabelecido
• [ ] Cronograma inclui tempo para correções e retestes
• [ ] Responsável pela aprovação identificado

Durante o UAT:

• [ ] Testes executados contra os critérios de aceitação
• [ ] Todas as falhas documentadas com passos para reproduzir
• [ ] Screenshots/gravações para problemas complexos
• [ ] Severidade atribuída a cada achado

Após o UAT:

• [ ] Todos os bugs P1/P2 corrigidos e retestados
• [ ] Aprovação formal do negócio recebida por escrito
• [ ] Release notes atualizadas com os problemas conhecidos P3/P4

Resumo

O acceptance testing confirma que o software entrega o valor de negócio para o qual foi construído. Pontos principais:

• Baseado em critérios de aceitação escritos pelos stakeholders de negócio, não pelo QA
• O UAT envolve usuários reais; o functional acceptance testing é feito pelo QA contra os requisitos
• Gherkin (Given/When/Then) torna os critérios legíveis por stakeholders técnicos e não técnicos
• Executa em um ambiente próximo ao de produção com dados realistas
• Exige aprovação formal antes da release
• Pode ser automatizado com Playwright, especialmente valioso para regressão em mudanças futuras

A diferença entre uma aprovação de QA e uma aprovação de negócio importa: o QA diz que o código funciona; o negócio diz que a funcionalidade resolve o problema deles.