Como Construir um Portfolio de QA que Te Contrata (GitHub + Playwright)

A maioria dos engenheiros de QA que concorre a vagas de automação não tem código público para mostrar. O engenheiro de contratação revisando a candidatura lê texto sobre experiência com testes e toma uma decisão subjetiva. Um repositório no GitHub com um pipeline de CI passando conta a mesma história em 30 segundos sem exigir nenhuma subjetividade.

Por que um portfólio importa para vagas de QA

Automação de QA é uma habilidade técnica. Empresas contratando para ela querem ver código, não descrições de código.

Um CV que diz "5 anos de experiência com Playwright e TypeScript" e um portfólio que mostra essa experiência produzem resultados diferentes na triagem de candidaturas.

O engenheiro de contratação revisando sua candidatura tem 30 a 60 segundos antes de decidir continuar lendo ou seguir em frente. Um link para um repositório no GitHub com código de teste limpo e bem estruturado faz mais naqueles 30 segundos do que um parágrafo de texto.

A barreira é menor do que parece. A maioria dos engenheiros de QA não tem portfólio público. Aparecer com um coloca você numa categoria diferente imediatamente.

O que colocar num portfólio de QA

Você não precisa de um projeto enorme. Precisa de evidência de competências específicas. Cada item do portfólio deve demonstrar algo concreto.

Uma suite de testes Playwright contra uma aplicação real

Essa é a peça central. Um repositório com testes para uma aplicação real: não um app de tutorial, não localhost, mas um site publicamente acessível de verdade.

O que testar: o ambiente de prática da BecomeQA em lab.becomeqa.com existe exatamente para esse propósito. É uma aplicação React com login, operações CRUD, upload de arquivo e uma seção de pagamento. Escreva testes contra ela.

O que a suite deve incluir:

• Fluxo de login (happy path + casos negativos)
• Operações CRUD para a feature principal (adicionar item, editar item, deletar item)
• Testes de validação de formulário
• Pelo menos um teste de API usando a fixture request do Playwright
• Estrutura de Page Object Model

Tamanho mínimo viável: 15 a 20 testes que realmente passam. Qualidade acima de quantidade.

Estrutura de diretórios que reflete conhecimento real

my-playwright-tests/
├── playwright.config.ts
├── package.json
├── tests/
│   ├── auth/
│   │   ├── login.spec.ts
│   │   └── logout.spec.ts
│   └── items/
│       ├── create-item.spec.ts
│       ├── edit-item.spec.ts
│       └── delete-item.spec.ts
├── pages/
│   ├── BasePage.ts
│   ├── LoginPage.ts
│   └── ItemsPage.ts
└── utils/
    └── testHelpers.ts

Essa estrutura mostra que você entende Page Object Model, organização de testes e separação de lógica de teste da lógica de página. Um diretório plano com 20 arquivos .spec.ts na raiz mostra o contrário.

Um README que explica o que você construiu

Escreva um README que cubra:

1. O que a suite de testes faz (qual aplicação, quais cenários)

2. Como rodá-la (npm install && npx playwright test)

3. Quais tecnologias são usadas (Playwright, TypeScript, padrão POM)

4. O que você adicionaria a seguir (mostra que você consegue pensar em escopo e prioridades)

Mantenha curto, 200 a 400 palavras. O README é lido por engenheiros de contratação decidindo se vale olhar o código.

O que faz o código do portfólio se destacar

A diferença entre código de portfólio que impressiona e código que passa despercebido:

// Fraco
await expect(page).toHaveURL('/dashboard');

// Forte
await expect(page.getByRole('heading', { name: 'My Travel Items' })).toBeVisible();
await expect(page.getByRole('navigation')).toContainText('admin@becomeqa.com');

Configurando o repositório do portfólio

# Inicializar um novo projeto
mkdir my-playwright-portfolio
cd my-playwright-portfolio
npm init playwright@latest

# Escolha TypeScript quando solicitado
# Selecione tests/ como diretório de testes
# Confirme o workflow do GitHub Actions

Isso te dá uma configuração Playwright funcionando com TypeScript e um arquivo de workflow do GitHub Actions que roda seus testes no CI.

Adicione os testes

// tests/auth/login.spec.ts
import { test, expect } from '@playwright/test';
import { LoginPage } from '../../pages/LoginPage';

test.describe('Login', () => {
  test('user can log in with valid credentials', async ({ page }) => {
    const loginPage = new LoginPage(page);
    await loginPage.goto();
    await loginPage.login('admin@becomeqa.com', 'testpass123');
    
    await expect(page.getByRole('heading', { name: 'My Travel Items' })).toBeVisible();
  });

  test('shows error with incorrect password', async ({ page }) => {
    const loginPage = new LoginPage(page);
    await loginPage.goto();
    await loginPage.login('admin@becomeqa.com', 'wrongpassword');
    
    await expect(page.getByText('Invalid credentials')).toBeVisible();
    await expect(page).not.toHaveURL('/dashboard');
  });
});

Faça push para o GitHub com CI passando

O workflow do GitHub Actions que npm init playwright@latest cria vai rodar seus testes automaticamente a cada push. Ter um pipeline de CI passando é mais impressionante do que ter testes que "funcionam na minha máquina".

Verifique a aba Actions após o push. Se os testes passarem: seu portfólio agora mostra um pipeline de CI rodando testes Playwright ao vivo. Isso vale mais do que qualquer coisa que você pode escrever num CV.

Se falharem: corrija antes de compartilhar o link.

O que mais incluir

Exemplos de bug reports

Uma coleção de 3 a 5 bug reports bem escritos. Não precisam ser de uma empresa. Podem ser bugs que você encontra em qualquer aplicação pública, incluindo lab.becomeqa.com.

Formate-os exatamente como o template de A Anatomia de um Bug Report que os Desenvolvedores Realmente Corrigem: título, ambiente, pré-condições, passos, esperado, real, severidade, anexos.

Coloque-os numa pasta /bug-reports como arquivos markdown. Isso demonstra comunicação escrita e habilidades de bug report que testes automatizados não mostram.

Plano de teste ou documento de casos de teste

Um documento curto mostrando como você abordaria testar uma feature do zero. Escolha uma feature específica (o upload de arquivo no lab.becomeqa.com, por exemplo) e escreva:

• Os cenários de teste que você cobriria
• Por que você escolheu esses cenários
• O que você priorizaria e por quê

Isso demonstra pensamento estratégico sobre testes, não só execução.

Onde compartilhar o portfólio

Erros comuns a evitar

// Ruim
await page.fill('#email', 'admin@becomeqa.com');

// Melhor (embora para um portfólio, credenciais de teste hardcoded para um app de teste sejam ok)
await page.fill('#email', process.env.TEST_EMAIL || 'admin@becomeqa.com');

FAQ

Construa um portfólio usando ambientes de teste públicos. lab.becomeqa.com existe para esse propósito. Outras opções: the-internet.herokuapp.com, automationexercise.com, saucedemo.com. A aplicação não importa. A qualidade do código importa.

Um portfólio mínimo viável (15 a 20 testes, estrutura POM, CI passando, README) leva 15 a 25 horas de trabalho focado para quem conhece Playwright. Se você ainda está aprendendo, planeje 30 a 40 horas distribuídas ao longo de algumas semanas.

Sim, se você os tiver. Um ou dois testes de API usando a fixture request do Playwright mostram que você entende o stack completo de testes:

test('API: create item returns 201', async ({ request }) => {
  const response = await request.post('/api/items', {
    data: { destination: 'Tokyo', status: 'Planned' },
    headers: { Authorization: `Bearer ${token}` },
  });
  expect(response.status()).toBe(201);
});

Sim, notavelmente. Engenheiros de QA sem portfólios competem no texto do CV. Engenheiros de QA com portfólios dão aos engenheiros de contratação algo concreto para avaliar. Na prática, quem tem portfólio avança mais no processo de triagem em empresas de tecnologia.