Desenvolvimento Orientado a Testes: O Guia do Engenheiro QA

Num time que pratica TDD, os desenvolvedores escrevem testes antes do código, o que levanta uma pergunta prática: o que sobra para o QA? Testes unitários não substituem testes de integração, verificação E2E ou os casos extremos que os desenvolvedores não pensaram em especificar.

O que o TDD realmente é

O ciclo TDD tem três etapas:

1. Red: escreva um teste que falha para o comportamento que você quer

2. Green: escreva o código mínimo para fazer o teste passar

3. Refactor: limpe o código sem quebrar o teste

Repita para a próxima parte do comportamento.

A palavra-chave é "mínimo". Você escreve exatamente o suficiente para passar no teste, nada mais. Isso força a implementação a ser guiada pela especificação (o teste), e não o contrário.

O que o TDD muda no código

TDD produz código que é:

Onde os engenheiros de QA se encaixam em times TDD

Engenheiros de QA em times TDD enfrentam um paradoxo: os desenvolvedores já estão escrevendo testes. O que sobra?

Várias coisas:

Desenvolvimento orientado a testes de aceitação (ATDD)

ATDD é a versão do TDD relevante para QA. O fluxo de trabalho:

1. O stakeholder de negócio descreve uma feature em termos de usuário

2. O engenheiro de QA traduz isso em critérios de aceite e testes de aceitação

3. Os desenvolvedores implementam até os testes de aceitação passarem

4. O QA verifica tanto os testes quanto a implementação

Os testes de aceitação se tornam a fonte da verdade sobre o que "pronto" significa. Uma feature está pronta quando seus testes de aceitação passam.

Em termos de Playwright:

// Escrito antes de a implementação existir
test('usuário consegue redefinir senha via email', async ({ page }) => {
  // Dado um usuário com email cadastrado
  const userEmail = 'testuser@example.com';
  
  // Quando ele solicita um reset de senha
  await page.goto('/forgot-password');
  await page.getByLabel('Endereço de email').fill(userEmail);
  await page.getByRole('button', { name: 'Enviar link de reset' }).click();
  
  // Então ele vê uma mensagem de confirmação
  await expect(page.getByRole('alert')).toHaveText(
    'Se esse email estiver cadastrado, um link de reset está a caminho.'
  );
  
  // E recebe um email de reset (verificado via API de email de teste)
  const inbox = await testEmailAPI.getInbox(userEmail);
  expect(inbox.some(m => m.subject.includes('Redefina sua senha'))).toBe(true);
});

Esse teste é escrito antes de a feature ser construída. O trabalho do desenvolvedor é fazê-lo passar.

Behavior-Driven Development (BDD)

BDD é uma evolução do ATDD que adiciona uma linguagem compartilhada (geralmente Gherkin) para escrever testes que não-engenheiros conseguem ler:

Feature: Reset de senha

  Scenario: Usuário redefine senha via email
    Given um usuário com email "testuser@example.com" está cadastrado
    When ele submete o formulário de esqueci a senha com esse email
    Then ele vê "Se esse email estiver cadastrado, um link de reset está a caminho."
    And ele recebe um email de reset de senha em até 1 minuto

Esses cenários Gherkin se mapeiam para código de teste Playwright via uma camada de definição de passos (usando ferramentas como Cucumber.js ou plugins BDD do Playwright).

BDD é mais valioso quando stakeholders não técnicos escrevem ou revisam os cenários. Adiciona overhead para times onde todos os stakeholders conseguem ler código.

Engenheiros de QA deveriam praticar TDD eles mesmos?

Para código de automação de testes: na maioria das vezes não. TDD é projetado para código de produção, onde você está projetando um sistema. Código de teste deveria ser direto de escrever e verificar. Escrever testes para o seu código de teste cria complexidade desnecessária.

A exceção são engenheiros de QA que constroem frameworks de testes ou utilitários (helpers de page object, utilitários de fixture, integrações de relatório). Eles podem se beneficiar do TDD ao construir essas ferramentas.

O que aplicar na prática em times TDD

1. Envolva-se antes de o código ser escrito. Revise user stories para testabilidade. Escreva critérios de aceite. Defina casos extremos.

2. Escreva testes de aceitação cedo. Mesmo que os desenvolvedores não estejam fazendo ATDD formal, ter testes de aceitação escritos antes do desenvolvimento começa molda a implementação.

3. Mova os testes exploratórios para mais cedo. Em times TDD, os testes exploratórios se tornam mais importantes porque é o que encontra as coisas que os testes não especificaram.

4. Revise os testes dos desenvolvedores. Não pelos números de cobertura: pelo fato de os testes realmente verificarem comportamento que importa.

TDD não elimina a necessidade de engenheiros de QA. Muda onde o trabalho de QA acontece: de depois do código para junto dele.