Testes de Fumaça vs Testes de Regressão: Qual é a Diferença?

A maioria dos times roda a suite completa do Playwright depois de cada deploy e chama isso de teste de regressão. Quando algo quebra em produção às 23h, uma suite de 45 minutos não é útil. Você precisa de 10 testes que confirmem que o login funciona, que a API responde e que a ação principal do usuário é concluída.

Smoke testing

Um smoke test responde uma pergunta: o sistema está fundamentalmente funcionando?

O nome vem de testes de hardware: ligue um dispositivo, veja se fuma. Passar essa verificação significa que vale a pena ir mais fundo. Falhar significa que testes mais profundos são inúteis.

Em software, um smoke test é um subconjunto pequeno e rápido de testes que verifica se os caminhos mais críticos estão operacionais. Geralmente 10 a 20 testes, executáveis em menos de 5 minutos.

• A aplicação inicia e carrega
• Autenticação funciona
• A ação mais crítica do usuário é concluída (fazer um pedido, enviar um formulário, realizar um pagamento)
• Os endpoints principais da API respondem

• Casos extremos
• Estados de erro
• Features secundárias
• Performance sob carga

Quando rodar smoke tests

• Após cada deploy (mesmo para produção)
• Após mudanças de infraestrutura (reinicializações de servidor, mudanças de config)
• Como primeiro passo no CI, antes da suite completa rodar
• Quando você precisa de uma verificação rápida antes de uma demo

Exemplo de smoke test no Playwright

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

test.describe('@smoke', () => {
  test('app carrega', async ({ page }) => {
    await page.goto('/');
    await expect(page).toHaveTitle(/MyApp/);
    await expect(page.getByRole('navigation')).toBeVisible();
  });

  test('login funciona', async ({ page }) => {
    await page.goto('/login');
    await page.getByLabel('Email').fill(process.env.TEST_USER_EMAIL!);
    await page.getByLabel('Password').fill(process.env.TEST_USER_PASSWORD!);
    await page.getByRole('button', { name: 'Log in' }).click();
    await expect(page).toHaveURL('/dashboard');
  });

  test('API principal está respondendo', async ({ request }) => {
    const response = await request.get('/api/health');
    expect(response.status()).toBe(200);
    const body = await response.json();
    expect(body.status).toBe('ok');
  });

  test('fluxo de pedido funciona do início ao fim', async ({ page }) => {
    // caminho crítico resumido
    await page.goto('/products');
    await page.getByRole('link', { name: 'Laptop Pro' }).click();
    await page.getByRole('button', { name: 'Add to cart' }).click();
    await page.goto('/checkout');
    // ... passos mínimos do checkout
    await expect(page.getByText('Pedido confirmado')).toBeVisible();
  });
});

Rodar apenas smoke tests:

npx playwright test --grep @smoke

Teste de regressão

Uma suite de regressão verifica que a funcionalidade existente ainda funciona após uma mudança. A preocupação não é "o sistema funciona em absoluto": é "quebramos algo que estava funcionando antes."

Testes de regressão são mais amplos e lentos do que smoke tests. Uma suite de regressão completa pode cobrir centenas de cenários e levar de 20 a 60 minutos para rodar.

• Todas as features, incluindo cenários secundários e casos extremos
• Tratamento de erros
• Condições de fronteira
• Comportamento cross-browser
• Pontos de integração entre serviços

Quando rodar testes de regressão

• Antes de cada release
• Após mudanças significativas de código (novas features, refatoração)
• Na branch principal após merges de PR
• Nightly para suites grandes

Tipos de teste de regressão

Diferenças principais

| | Smoke Testing | Teste de Regressão |

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

| Propósito | O sistema está funcionando? | Quebramos algo? |

| Escopo | Apenas caminhos críticos | Todas as features |

| Velocidade | Rápido (2 a 5 min) | Lento (20 a 60+ min) |

| Frequência | A cada deploy | Antes de releases, após mudanças |

| Quantidade de testes | 10 a 30 testes | Centenas a milhares |

| Ação em caso de falha | Rollback ou parar | Corrigir antes do release |

Construindo a divisão certa

A maioria dos times roda a suite inteira como regressão e não tem uma camada de smoke dedicada. Isso cria um problema: quando você faz deploy para produção e algo está errado, não consegue verificar rapidamente os caminhos críticos. A suite de regressão completa de 45 minutos não é a ferramenta certa para esse momento.

Uma estrutura melhor:

@smoke (rodar a cada deploy, máximo 5 min)
├── App carrega
├── Auth funciona
├── Feature principal é concluída

@regression (rodar antes do release, 30 a 60 min)
├── testes @smoke (incluídos)
├── Todos os outros testes de feature
├── Casos extremos
└── Cross-browser

Tageie seus testes mais críticos com @smoke. Rode-os após cada deploy. Rode a suite completa antes de cada release.

O que não é teste de regressão

A confusão vem do uso amplo da palavra "regressão": no uso comum, qualquer teste automatizado que roda após uma mudança é chamado de teste de regressão. No uso formal, teste de regressão significa especificamente verificar que funcionalidades que estavam funcionando antes ainda funcionam.

Os dois usos são válidos na prática. O que importa é ter clareza sobre o que você está verificando e por quê.