O Plano de 90 Dias para Conseguir Seu Primeiro Emprego QA

A maioria dos estudantes de QA passa meses em tutoriais e chega ao dia 90 com conceitos na cabeça mas sem portfólio. Este plano inverte isso: cada semana termina com algo que pode ser mostrado a um recrutador.

Dias 1–30: Fundação

O objetivo do primeiro mês não é se tornar especialista. É se sentir confortável com o vocabulário e a mentalidade de QA, entender como são casos de teste e relatórios de bug num time real. O primeiro teste Playwright funcionando também faz parte disso. Tudo em paralelo: conceitos de teste manual nas primeiras duas semanas, automação a partir da semana 3. No dia 30 você já tocou em tudo o que vai desenvolver nos próximos meses.

Semana 1: Fundamentos de teste manual

Passe a primeira semana entendendo como é um teste estruturado. O principal produto do trabalho de QA manual é o caso de teste: um conjunto documentado de passos, pré-condições, resultado esperado e resultado real. Escreva cinco casos de teste para o fluxo de login em lab.becomeqa.com à mão, numa planilha do Google ou num doc no Notion. Use colunas para: ID do Caso de Teste, Pré-condição, Passos, Resultado Esperado, Resultado Real e Status.

Não deixe os passos vagos. "Abrir a página de login, inserir o e-mail admin@becomeqa.com, inserir uma senha errada, clicar em Enviar, verificar se a mensagem de erro é 'Invalid credentials'" é um caso de teste. "Verificar se o login funciona" não é. Precisão é a habilidade em si.

Depois de escrever os casos de teste de login, escreva mais cinco para a lista de itens: verificar se os itens carregam, se a contagem bate com o que a API retorna, se a ordenação funciona, se a busca filtra os resultados, se uma busca sem resultado mostra um estado vazio com sentido. Rode cada um manualmente e registre os bugs que encontrar.

Quando encontrar um bug (e vai encontrar), documente como um relatório formal. Um relatório mínimo tem título, ambiente (navegador, sistema operacional), pré-condições, passos para reproduzir, comportamento esperado, comportamento real e severidade. Severidade não é o quanto você ficou irritado. Critical significa que o app está quebrado para todos os usuários. Major significa que uma funcionalidade central não funciona. Minor significa que algo parece errado mas não bloqueia nada. Trivial significa um erro de digitação.

Semana 2: Noções básicas de Agile e a mentalidade de QA no time

O trabalho real de QA acontece dentro de sprints Agile. Passe essa semana aprendendo como engenheiros de QA se encaixam nesse processo. Você precisa entender o que é uma user story e como os critérios de aceitação se relacionam com casos de teste. Aprenda também o que significa "definição de pronto" e por que QA faz parte disso, e como é uma revisão de sprint do ponto de vista de QA.

O exercício prático: pegue três user stories de um board público de gerenciamento de projetos (templates do Trello funcionam, ou crie os seus com base nas funcionalidades do lab.becomeqa.com) e escreva critérios de aceitação para cada uma. Depois converta esses critérios em casos de teste. Esse é o fluxo real num trabalho: a story chega, você escreve os testes antes do desenvolvimento terminar e verifica quando o desenvolvedor diz que está pronto.

Leia sobre a diferença entre verificação (construímos a coisa do jeito certo?) e validação (construímos a coisa certa?). Esses termos aparecem em entrevistas.

Semanas 3–4: Começar com Playwright

Instale o Node.js (versão LTS) e crie um novo projeto Playwright com npm init playwright@latest. Escolha TypeScript quando solicitado. O Playwright vai criar a estrutura de pastas e um teste de exemplo. Rode npx playwright test e veja passar. Essa estrutura (tests/, playwright.config.ts, package.json) é o que você vai usar nos próximos dois meses.

Seu primeiro teste para escrever do zero é um teste de login contra lab.becomeqa.com:

import { test, expect } from '@playwright/test';

test('login with valid credentials shows dashboard', async ({ page }) => {
  await page.goto('https://lab.becomeqa.com');
  await page.getByRole('button', { name: 'Login' }).click();
  await page.getByLabel('Username').fill('admin@becomeqa.com');
  await page.getByLabel('Password').fill('testpass123');
  await page.getByRole('button', { name: 'Submit' }).click();

  await expect(page.getByText('My Travel Items')).toBeVisible();
});

Rode com npx playwright test --headed para ver o navegador abrindo e preenchendo os campos sozinho. É esse momento que conquista a maioria das pessoas. Depois escreva mais dois testes: um para credenciais inválidas (verifique se a mensagem de erro aparece), outro para logout (verifique se o botão de login volta a aparecer). Até o final da semana 4 você deve ter de seis a oito testes passando e uma noção de como o Playwright pensa sobre páginas.

Dias 31–60: Habilidades de Automação

O segundo mês é onde o trabalho de verdade acontece. É esse material que os entrevistadores técnicos vão perguntar.

Semana 5: Localizadores e assertions

O Playwright oferece várias formas de encontrar elementos na página. A hierarquia correta, do mais ao menos recomendado: getByRole, getByLabel, getByPlaceholder, getByText, getByTestId, e por último seletores CSS. O motivo dessa ordem é a resiliência. Localizadores baseados em role e label continuam funcionando quando um desenvolvedor renomeia uma classe CSS ou troca um div por section. Seletores CSS quebram.

Passe a semana 5 escrevendo localizadores para cada elemento principal do lab.becomeqa.com usando os métodos recomendados. Use npx playwright codegen https://lab.becomeqa.com para ver como o Playwright identifica os elementos enquanto você clica. Depois reescreva manualmente cada localizador gerado no formato preferido. É um exercício deliberado: o codegen costuma usar seletores CSS, e você quer criar o hábito de escolher opções melhores.

Para as assertions, pratique tanto a versão "soft" quanto a "hard". Uma assertion hard (expect(locator).toBeVisible()) para o teste imediatamente se falhar. Uma soft assertion (expect.soft(locator).toBeVisible()) registra a falha mas continua o teste para capturar mais problemas numa única passagem. Use soft assertions quando quiser verificar o estado de uma página inteira de uma vez; use hard assertions quando uma falha significa que nada mais no teste pode ser confiado.

Semana 6: Page Object Model

A essa altura seus testes provavelmente estão ficando repetitivos. Todo teste que precisa de um usuário logado repete as mesmas quatro linhas. O Page Object Model (POM) elimina essa duplicação e faz seus testes lerem como documentação.

Crie uma pasta pages/. Comece com dois arquivos: LoginPage.ts e ItemsPage.ts.

// pages/LoginPage.ts
import { Page } from '@playwright/test';

export class LoginPage {
  constructor(private page: Page) {}

  async navigate() {
    await this.page.goto('https://lab.becomeqa.com');
  }

  async login(username: string, password: string) {
    await this.page.getByRole('button', { name: 'Login' }).click();
    await this.page.getByLabel('Username').fill(username);
    await this.page.getByLabel('Password').fill(password);
    await this.page.getByRole('button', { name: 'Submit' }).click();
  }

  async getErrorMessage() {
    return this.page.getByRole('alert').textContent();
  }
}

// pages/ItemsPage.ts
import { Page, Locator } from '@playwright/test';

export class ItemsPage {
  readonly itemRows: Locator;

  constructor(private page: Page) {
    this.itemRows = this.page.getByRole('row');
  }

  async getItemCount() {
    return this.itemRows.count();
  }

  async searchFor(term: string) {
    await this.page.getByPlaceholder('Search').fill(term);
  }
}

Reescreva todos os seus testes existentes para usar essas classes. Um teste que antes tinha doze linhas de setup agora tem quatro. Mais importante: se o rótulo do botão de login mudar amanhã, você corrige num único arquivo em vez de vinte.

Semana 7: Git e GitHub

Você está escrevendo código há um mês. Agora precisa controlar as versões corretamente e colocar isso em algum lugar visível. Instale o Git se ainda não tiver. Crie uma conta no GitHub. Suba seu projeto Playwright como repositório público.

O fluxo Git que você precisa para o trabalho: git status para ver o que mudou, git add para preparar arquivos específicos, git commit -m "mensagem" para salvar um snapshot, git push para enviar. Nesta fase você está trabalhando sozinho, então não precisa de fluxos com branches ainda. Mas pratique mesmo assim: crie uma branch com git checkout -b add-items-tests, escreva seus testes lá, faça commit e mescle com git checkout main && git merge add-items-tests. É assim que todo time que você vai trabalhar opera.

Escreva um README para o seu repositório. Não precisa ser longo. Diga ao leitor o que é o projeto, como instalar as dependências (npm install), como rodar os testes (npx playwright test), e qual site você está testando. Um README que existe e tem instruções que funcionam já é melhor que a maioria dos portfólios júnior.

Semana 8: 20+ testes e cobertura de API

Essa é a semana de execução. Seu objetivo é chegar a 20 ou mais testes passando contra lab.becomeqa.com. Parece muito. Não é. Entre fluxos de login, operações CRUD de itens, busca, filtros e os endpoints de API, há facilmente 40 cenários que valem testar.

Para testes de API, o Playwright já tem isso integrado. Nenhuma ferramenta separada necessária:

import { test, expect } from '@playwright/test';

test('GET /api/items returns a list with required fields', async ({ request }) => {
  const response = await request.get('https://lab.becomeqa.com/api/items');

  expect(response.status()).toBe(200);

  const items = await response.json();
  expect(items.length).toBeGreaterThan(0);
  expect(items[0]).toHaveProperty('id');
  expect(items[0]).toHaveProperty('destination');
});

Escreva pelo menos cinco testes de API. Um GET de happy path, um POST que cria um item, um DELETE que o remove. Um teste para autenticação: o que acontece se você chamar a API sem token? E um que valida se o formato da resposta bate com o que a UI exibe. Misture testes de API e de UI na mesma suite. É assim que projetos reais são estruturados.

Dias 61–90: Portfólio e Busca de Emprego

O terceiro mês é sobre converter tudo que você construiu em algo que vai te contratar. A busca por emprego e o aprendizado acontecem em paralelo. Não espere o dia 90 para mandar a primeira candidatura.

Semana 9: GitHub Actions CI

Uma suite de testes que só roda no seu notebook vale menos para um recrutador do que uma que roda na nuvem a cada commit. Configure o GitHub Actions criando um arquivo em .github/workflows/playwright.yml:

name: Playwright Tests

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - name: Install dependencies
        run: npm ci
      - name: Install Playwright browsers
        run: npx playwright install --with-deps
      - name: Run tests
        run: npx playwright test
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: playwright-report
          path: playwright-report/
          retention-days: 30

Faça push desse arquivo. Olhe a aba Actions no seu repositório do GitHub. Você deve ver um workflow disparar e seus testes rodarem num container Linux. Quando passarem, aparece um checkmark verde ao lado do seu último commit. Esse checkmark verde é algo que você pode printar e usar nos seus posts no LinkedIn. É também evidência concreta de que você entende CI, uma pergunta que aparece em quase toda entrevista técnica.

Se alguns testes forem instáveis no CI (passam localmente mas falham intermitentemente no pipeline), isso é uma lição importante por si só. Testes instáveis geralmente falham no CI por causa de timing: a página carrega mais lentamente numa máquina na nuvem do que no seu notebook. A correção é quase sempre substituir esperas fixas (page.waitForTimeout(2000)) por esperas adequadas do Playwright (page.waitForSelector, ou simplesmente confiar que as assertions do Playwright já esperam automaticamente). Rastreie cada teste instável e corrija. Um CI com um teste vermelho intermitente é pior que um CI com 15 testes em vez de 20.

Semana 10: Polir o portfólio

Seu repositório no GitHub precisa de três coisas antes de você começar a se candidatar: uma contagem de testes que vale mencionar (20+), um badge de CI no README, e documentação que um desconhecido consiga seguir.

Adicione um badge de CI ao README copiando a URL do badge do seu workflow no GitHub Actions. Em Markdown fica assim:

![Playwright Tests](https://github.com/SEU_USUARIO/SEU_REPO/actions/workflows/playwright.yml/badge.svg)

Quando os testes passam, esse badge aparece verde no seu README. É um detalhe pequeno que sinaliza que você se importa com boas práticas profissionais.

Expanda o README para incluir uma descrição do projeto e o que você está testando e por que (lab.becomeqa.com é uma aplicação de prática para engenheiros de QA). Adicione uma tabela listando cada arquivo de teste e o que ele cobre. Inclua também como rodar grupos específicos de testes com npx playwright test --grep @api (adicione tags como @api e @ui nos seus testes para habilitar isso). O objetivo é que alguém que nunca viu o seu projeto consiga cloná-lo, rodar e entender o que está vendo em menos de dez minutos.

Semana 11: LinkedIn e currículo

Seu perfil no LinkedIn precisa de quatro coisas para atrair atenção de recrutadores de QA. Um título que diga o que você está buscando ("QA Automation Engineer | Playwright | TypeScript"). Uma seção Sobre com 3 a 4 frases explicando sua transição para QA e o que você construiu. Uma seção Em Destaque com link para o seu repositório no GitHub. Uma seção de Habilidades listando Playwright, TypeScript, JavaScript, Git, GitHub Actions, API Testing e Agile.

Se você vem de outra área, não esconda isso. Enquadre como uma vantagem. "Background em atendimento ao cliente me deu uma perspectiva diferente sobre como usuários reais interagem com o software" é mais interessante do que fingir que sempre foi da área de tecnologia.

Para o currículo, liste o projeto do portfólio no GitHub como uma entrada de experiência, não como uma nota de rodapé. Escreva assim: "Playwright Automation Framework (Projeto Pessoal): construí uma suite de testes com 25+ testes de UI e API contra uma aplicação web real usando TypeScript e Playwright. Configurei pipeline de CI/CD com GitHub Actions. Implementei Page Object Model para manutenibilidade." Cada palavra é verdadeira, específica e bate diretamente com o que as vagas pedem.

Se você não tem experiência profissional em QA, seu currículo tem duas seções. O projeto de portfólio e suas experiências anteriores, enquadradas pelas habilidades transferíveis: atenção a detalhes, orientação a processos, comunicação, trabalho técnico se houver. Mantenha em uma página.

Semana 12: Candidatar-se e continuar

Comece a se candidatar antes de se sentir pronto. Você se sentiu despreparado no dia 30, no dia 60, e vai se sentir despreparado no dia 90. A forma de saber quais lacunas você tem é entrar em entrevistas e ver o que perguntam. Uma rejeição após uma entrevista técnica onde você não conseguiu responder uma pergunta sobre fixtures ou gerenciamento de dados de teste te diz exatamente o que estudar a seguir. Isso é valioso.

Candidate-se a 5 a 10 empresas na semana 12. Priorize empresas com times de QA menores: você vai aprender mais e ter mais autonomia. Prefira também empresas cujos produtos você realmente usa, porque interesse genuíno aparece nas entrevistas. Foque em vagas que contratam explicitamente engenheiros de automação júnior, não apenas "analista de QA" puramente manual.

Depois de cada entrevista, anote todas as perguntas que não conseguiu responder. Passe uma hora em cada tema no dia seguinte. Você vai se sair melhor na segunda entrevista do que na primeira, e melhor na terceira do que na segunda.

Perguntas Frequentes

Vinte é o mínimo. Trinta a quarenta é sólido. Não precisa de mais do que isso. O objetivo é demonstrar amplitude (testes de UI, testes de API, POM, CI), não volume. Cinco testes cobrindo login, lista de itens, um endpoint de API e mostrando Page Object Model é mais impressionante do que cinquenta testes de login copiados.

A maioria dos projetos Playwright modernos usa TypeScript. Você não precisa ser especialista em TypeScript. A tipagem estática ajuda mais do que atrapalha. Comece com TypeScript desde o dia 1, deixe o editor te dizer quando os tipos estiverem errados e pesquise o que o erro significa. Isso é 90% de como você aprende.

Se o volume de candidaturas for menor que 30 e você estiver se candidatando há menos de quatro semanas, é cedo demais para tirar conclusões. Se você passou de 30 candidaturas sem retorno, o problema geralmente é o currículo ou o perfil no LinkedIn, não as suas habilidades. Peça a alguém de QA ou tecnologia para revisar o seu currículo. Entre em comunidades de QA no LinkedIn e Discord. As pessoas dessas comunidades costumam compartilhar vagas abertas e podem te indicar internamente, o que bypassa a triagem de currículos.

Não em vez do portfólio, jamais. Se você tiver tempo sobrando no primeiro mês enquanto os conceitos técnicos ainda são leves, ler o syllabus do ISTQB Foundation Level é útil para vocabulário. Mas um portfólio no GitHub com CI é uma evidência mais concreta das suas capacidades do que qualquer certificação. Recrutadores que te disserem o contrário são minoria.

Continue se candidatando e continue construindo. Adicione um segundo projeto ao portfólio. Escreva testes para uma aplicação diferente. Muitos projetos open source aceitam contribuições que incluem testes, o que te dá experiência colaborativa real. Comece um blog técnico simples documentando o que aprendeu; mesmo dois ou três posts sobre problemas específicos que você resolveu sinaliza que consegue comunicar ideias técnicas. O plano de 90 dias te leva à linha de largada, não à de chegada. A maioria das pessoas consegue sua primeira oferta de QA entre o 4º e o 6º mês.