Como se Tornar QA Engineer em 2026: O Roadmap Completo (Sem Diploma)

A maioria dos iniciantes desperdiça meses em exercícios abstratos de programação antes de escrever um único teste. O caminho melhor é Playwright primeiro: escreva um teste real contra um site real no primeiro dia. Use a confusão de linguagem que você encontra pelo caminho como sinal do que estudar a seguir.

A função tem dois sabores e você precisa escolher logo

Quando a maioria das pessoas fala "QA engineer" está pensando em dois empregos diferentes. Testers manuais exploram software à mão, escrevem casos de teste, reportam bugs e comunicam descobertas para desenvolvedores e gerentes de produto. QA engineers de automação escrevem código que testa software automaticamente, rodando verificações em cada deploy sem um humano clicando em nada.

Manual é mais fácil de entrar. Automação paga significativamente mais e tem melhor trajetória de carreira a longo prazo. O salário mediano de um QA automation engineer nos EUA é $95.000–$115.000 dependendo de localização e tamanho da empresa. Vagas de QA manual ficam tipicamente $20.000–$30.000 abaixo.

Este guia cobre o caminho de automação, porque é para onde o mercado está indo e onde o crescimento de carreira se acumula. Se você está começando do zero, é esse o caminho que vale a pena seguir.

A boa notícia: você não precisa de diploma em ciência da computação para nenhuma das duas funções. Dezenas de QA automation engineers trabalhando hoje começaram como professores, atendentes de suporte, gerentes de projetos e contadores. As habilidades técnicas são aprendíveis. O que você está vendendo em uma entrevista é prova de que as aprendeu.

As únicas habilidades técnicas que realmente importam para um primeiro emprego

Vagas de QA automation júnior em 2026 se concentram na mesma lista curta. Se você vê uma vaga pedindo 15 habilidades específicas, a maioria é aspiracional. O que realmente te faz passar pela triagem técnica é isso:

Playwright ou Selenium (Playwright fortemente preferido para quem está começando agora), JavaScript ou TypeScript (TypeScript é o que a maioria dos projetos modernos usa). Também testes básicos de API, Git e entendimento de como o CI funciona. É isso. Todo o resto é diferencial que você pega no trabalho.

Aqui está um exemplo do mundo real do que um QA automation engineer júnior faz no primeiro dia. Você clona um repositório de testes, roda a suite existente, vê alguns testes passando e alguns falhando, e sua primeira tarefa é descobrir por que os que falharam estão falhando. Isso exige Git para pegar o código, Node.js para rodá-lo, TypeScript para lê-lo e Playwright para entender os erros. Mais nada. Sem certificação, sem checklist de 30 habilidades.

Comece com Playwright antes de qualquer outra coisa

Essa é a parte contraintuitiva do roadmap. A maioria das pessoas começa "aprendendo programação" porque é isso que os guias de carreira dizem. O problema com essa abordagem é que exercícios puros de programação são abstratos e entediam rápido. Você passa semanas em problemas de fizzbuzz e manipulação de arrays enquanto o motivo real pelo qual quis aprender (quebrar e testar software) fica permanentemente no futuro.

Comece com Playwright primeiro. Aceite que você vai copiar e colar código que não entende completamente. Rode. Veja funcionar. Quebre deliberadamente. Veja qual erro volta.

Aqui está o primeiro teste que vale escrever, usando o lab.becomeqa.com:

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

test('login with valid credentials', 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 isso. Assista abrir um navegador, preencher campos e clicar em botões sem você tocar em nada. Essa sensação de ver a automação funcionar pela primeira vez é o que mantém as pessoas avançando pelas partes mais difíceis.

Depois escreva um segundo teste que usa credenciais erradas e faz assertion que a mensagem de erro aparece. Depois um terceiro que faz logout e verifica que a página volta ao estado de login. Três testes, todos em UI real, e você já praticou locators, assertions e estrutura de teste.

JavaScript e TypeScript: aprenda o suficiente, depois continue

Assim que você estiver escrevendo testes, vai bater em paredes de linguagem. Você vai ver async e await e não vai saber o que significam. Vai querer guardar um valor de um passo do teste e usá-lo em outro e não vai saber como variáveis funcionam através de chamadas await. Esses são os momentos para parar e aprender o conceito de linguagem que está te bloqueando.

O mínimo de JavaScript/TypeScript que você precisa antes de escrever testes reais: variáveis e const/let, funções, arrays e objetos, async/await e por que existe, e operações básicas de string. São aproximadamente duas a três semanas de prática diária se você nunca escreveu código antes.

Os conceitos que você vai pegar enquanto escreve mais testes: tipos e interfaces TypeScript, destructuring, módulos e imports, e classes quando chegar no Page Object Model.

Um exemplo concreto de como async/await confunde as pessoas no começo. Se você escrever isso:

const text = page.getByText('Welcome').textContent();
console.log(text); // imprime uma Promise, não o texto

Você recebe um objeto Promise impresso no console, não o texto real. A versão correta é:

const text = await page.getByText('Welcome').textContent();
console.log(text); // imprime 'Welcome'

O await diz ao JavaScript: para aqui, espera essa operação assíncrona terminar, depois me dá o resultado. Toda ação do Playwright usa await. Entender por quê torna o debug dez vezes mais rápido.

Testes de API não são opcionais

A maioria dos iniciantes pula testes de API porque parece uma habilidade separada e mais difícil. Não é nenhuma das duas coisas. Um teste de API é apenas uma requisição HTTP com assertions na resposta. Sem navegador, sem cliques, sem locators.

É por isso que pertence à sua lista de aprendizado cedo. Testes de API são cinco a dez vezes mais rápidos que testes de UI e falham por menos razões não relacionadas. Um teste de UI pode falhar porque um botão se moveu, um spinner de carregamento demorou um segundo a mais ou um tooltip cobriu o elemento. Um teste de API falha porque os dados estão errados, que é o que você realmente se importa.

O Playwright tem testes de API integrados no mesmo framework que você já está usando:

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

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

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

Sem novas ferramentas. Sem framework separado. As mesmas funções test e expect que você já conhece, com request em vez de page.

Passe algumas horas também no Postman. Não porque você vai usá-lo para automação, mas porque explorar uma API manualmente antes de escrever testes para ela economiza tempo. Você envia requisições, vê os formatos de resposta, entende os headers de auth, e depois seu código de teste faz sentido em vez de ser copiado cegamente da documentação.

Construa algo que você possa mostrar, não apenas algo que você entenda

É aqui que a maioria dos autodidatas trava. Eles passam por tutoriais, escrevem exercícios e sentem que estão progredindo. Então alguém pergunta "posso ver seu trabalho?" e não tem nada para compartilhar.

Gestores de contratação olham perfis do GitHub para candidatos QA júnior. Não porque esperam suites de testes polidas de nível sênior. Mas porque um repositório no GitHub prova que você realmente escreveu o código e não apenas assistiu vídeos sobre isso.

Um portfólio que vai te gerar entrevistas é direto: um repositório GitHub com uma suite Playwright cobrindo um site real. Configuração TypeScript, Page Object Model para pelo menos duas páginas, testes de UI e de API, e um workflow do GitHub Actions rodando em cada push. É isso. Esse é o bar.

A parte do Page Object Model parece intimidante antes de fazer. Aqui está o conceito: em vez de escrever page.getByLabel('Username').fill(username) em todo teste que precisa fazer login, você cria uma classe LoginPage com um método login(username, password). Os testes chamam loginPage.login('admin@becomeqa.com', 'testpass123'). Se o formulário de login mudar, você corrige em um lugar.

// pages/LoginPage.ts
export class LoginPage {
  constructor(private page: Page) {}

  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();
  }
}

Use o lab.becomeqa.com como o site que você automatiza para o portfólio. Tem complexidade suficiente (login, tabelas de dados, modais, upload de arquivo, endpoints de API) para demonstrar habilidades reais sem o site cair ou bloquear tráfego automatizado.

Como aplicar isso segunda-feira de manhã

Se você está lendo isso num domingo à noite e quer um plano concreto para a próxima semana, aqui está.

Segunda: instale Node.js e Playwright. Siga o quickstart oficial. Faça um teste rodar contra o lab.becomeqa.com. Não avance até ver um teste verde no terminal.

Terça: escreva mais cinco testes. Login com sucesso, login com falha, navegar para uma seção específica, verificar que os dados carregam, e um que usa o endpoint de API diretamente. Você vai encontrar problemas. Essa é a prática de verdade.

Quarta: aprenda o conceito de async/await de verdade. Leia o artigo do MDN sobre Promises. Assista um vídeo curto. Volte e releia o código de testes existente. Deve fazer mais sentido.

Quinta: crie uma conta no GitHub se não tiver. Faça push do repositório de testes. Deixe o README honesto: "Aprendendo Playwright, trabalho em progresso" está ótimo.

Sexta: adicione um arquivo de workflow do GitHub Actions. A documentação do Playwright tem um exemplo para copiar e colar. Faça os testes rodarem no GitHub Actions. Tire um screenshot do check verde. Guarde.

Semana dois: Page Object Model para o fluxo de login. Semana três: interfaces TypeScript para os dados de resposta da API. Semana quatro: candidate-se a uma vaga de QA júnior mesmo que não se sinta pronto. Ler a descrição da vaga vai te dizer exatamente o que estudar a seguir.

As pessoas que são contratadas não esperam até se sentir prontas. Elas constroem evidências de que conseguem fazer o trabalho, colocam em algum lugar visível e começam a falar com empresas enquanto continuam aprendendo.

FAQ

Quatro a seis meses de prática diária para a maioria das pessoas sem experiência prévia em programação. Menos se você vem de um background de desenvolvimento. Mais se você só pratica nos fins de semana. A variável não é talento. É consistência e a qualidade do que você constrói para mostrar.

Não para ser contratado na maioria das empresas hoje. O Playwright substituiu o Selenium na maioria dos projetos novos. Se uma empresa específica que você quer entrar usa Selenium, você consegue aprender as diferenças em uma semana quando já sabe Playwright. Os conceitos são quase idênticos, a sintaxe difere.

O ISTQB Foundation Level é a certificação mais reconhecida em QA. Demonstra familiaridade com teoria e terminologia de testes. Algumas empresas filtram por ela, a maioria não exige. Se você está escolhendo entre se certificar pelo ISTQB e construir um projeto de portfólio, construa o projeto. Um repositório GitHub com testes funcionando é evidência mais forte do que uma prova de múltipla escolha.

Seu portfólio no GitHub, especificamente. Liste o projeto com um link. Descreva o que você construiu ("Suite Playwright com 40+ testes cobrindo fluxos de UI e endpoints REST, rodando em CI via GitHub Actions") e note as tecnologias. Recrutadores veem links do GitHub e realmente os seguem. Coloque o currículo na frente de pessoas que vão clicar no link antes de se preocupar em como formular todo o resto.

Automação. Paga mais, é para onde a indústria está indo, e a curva de aprendizado é concentrada no início. Uma vez que você passa por ela, é empregável. Começar com QA manual e fazer a transição para automação depois significa aprender duas vezes. A única exceção é se você consegue uma vaga de QA manual rapidamente. Use-a para fazer a transição internamente em uma empresa que vai pagar pelo seu tempo de desenvolvimento.