Roadmap de Automação QA 2026: Habilidades Essenciais para Conseguir Emprego

Aprender Playwright antes de JavaScript significa que você vai copiar e colar código sem entender por que ele quebra. A ordem dessas nove habilidades é deliberada: cada uma habilita a próxima, e pular etapas custa mais tempo do que economiza.

Por que a ordem importa

Você não escreve testes reais sem JavaScript. Ponto final. E não automatiza uma API se ninguém nunca explicou o que uma API é. E definitivamente não configura CI/CD quando você ainda não tem testes que valham rodar.

Cada habilidade aqui desbloqueia a próxima. Pule etapas e você vai gastar o dobro do tempo confuso.

1. Playwright: seu framework de automação

O Selenium costumava ser a resposta. Não é mais. Não para quem está aprendendo em 2026.

O Playwright substituiu o Selenium na maioria dos projetos novos, por razões que ficam óbvias no momento em que você usa os dois. Ele aguarda elementos automaticamente em vez de fazer você adivinhar timers de sleep. Vem com test runner integrado, gravações de vídeo de falhas, interceptação de rede e um gerador de código que escreve locators enquanto você clica na página.

Como um teste Playwright real parece:

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

test('usuário consegue fazer login', 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();
});

Limpo. Sem boilerplate. Se nada disso faz sentido ainda, tudo bem (o curso de Playwright cobre exatamente isso).

2. JavaScript/TypeScript: a camada de linguagem

Algumas pessoas tentam pular isso e ir direto para os testes. Funciona por umas duas semanas. Depois algo quebra e elas não fazem a menor ideia do porquê, porque nunca aprenderam a linguagem, só copiaram e colaram.

Playwright é JavaScript. TypeScript é JavaScript com tipos adicionados. Os tipos pegam seus erros antes de você rodar qualquer coisa. O Playwright scaffolda TypeScript por padrão e depois de uma semana com ele você não vai querer voltar para JS puro.

O que você realmente precisa:

Comece com variáveis, tipos de dados, funções, arrays e objetos, e async/await. Esse último não é opcional. Cada ação no Playwright usa async/await. Sem entender isso você está no escuro.

Depois, quando você estiver escrevendo testes regularmente: destructuring, spread operator, módulos, tratamento de erros com try/catch, e classes para o Page Object Model.

Não espere "terminar JavaScript" antes de escrever testes. Isso é uma armadilha. Aprenda o essencial, comece a escrever testes, pegue o resto conforme precisar. Os testes te dão uma razão concreta para usar a linguagem.

3. Praticar em um site real

Teoria sem um site para automatizar é só leitura. Você precisa de formulários reais, tabelas reais, casos extremos reais.

A maioria dos sites de prática é trivialmente simples (um botão, um campo de texto) ou fica fora do ar aleatoriamente e dá erros que não têm nada a ver com o seu código de teste. Os dois são piores do que inúteis para aprender.

Construímos o lab.becomeqa.com para isso. Fluxo de login completo, tabelas de dados com ordenação, modais, upload de arquivo, formulário de pagamento conectado ao modo de teste do Stripe. Endpoints de API expostos para testes diretos. É mantido estável porque ambientes de prática instáveis ensinam os hábitos errados de debugging.

Outras opções decentes: SauceDemo, The Internet by Dave Haefner, TodoMVC. Mas o lab.becomeqa.com tem a API configurada para corresponder aos exercícios deste curso.

4. Testes de API: mais rápidos e estáveis do que testes de UI

A maioria dos iniciantes não sabe isso: a maioria dos bugs em aplicações web não está na UI. Está na API, a lógica de backend que a UI está chamando.

Testes de UI levam segundos. Testes de API levam milissegundos. E testes de API não quebram porque um botão deslocou dois pixels para a esquerda ou um spinner de carregamento demorou um pouco mais do que o esperado. São mais estáveis, mais rápidos de escrever, e pegam uma classe de bugs que testes de UI simplesmente nunca alcançam.

O Playwright tem testes de API integrados através da fixture request:

test('GET /api/items retorna uma lista', 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('destination');
});

Sem browser. Sem página. Só HTTP. Ferramentas que vale conhecer: a fixture request (já integrada ao Playwright), Postman para exploração manual de API, e métodos HTTP básicos (cobertos na habilidade 7).

5. CI/CD: faça seus testes serem úteis de verdade

Testes que só rodam no seu laptop não pegam bugs de produção. Pegam bugs quando você por acaso os roda manualmente. Isso não é automação, é só teste manual com delay.

Pipelines de CI/CD rodam seus testes em cada commit, cada PR, cada deploy. Automaticamente. Como as principais ferramentas diferem na prática:

Coloque seus testes Playwright no GitHub Actions primeiro. Você consegue fazer em um dia.

6. SQL básico: verifique o banco de dados você mesmo

Em algum momento você vai precisar verificar se o que a UI mostra foi realmente salvo no banco de dados. Ou ver dados que a UI nunca expõe. Isso exige SQL.

Boa notícia: SQL para QA não é SQL complexo. São talvez cinco padrões de query que cobrem 80% do que você vai precisar:

-- Verificar se um usuário existe
SELECT * FROM users WHERE email = 'test@example.com';

-- Verificar dados relacionados entre tabelas
SELECT orders.id, users.email, orders.status
FROM orders
JOIN users ON orders.user_id = users.id
WHERE orders.status = 'pending';

Dois SELECT. Um JOIN. Condições WHERE. Isso é genuinamente a maior parte. Vagas que pedem "experiência com SQL" quase sempre estão pedindo exatamente isso e não muito mais.

7. Como a internet funciona

Cada teste que você escreve está enviando requisições por uma rede. Entender o que acontece por baixo ajuda a ler mensagens de erro corretamente, identificar o que quebrou, e acompanhar o que os desenvolvedores estão descrevendo quando algo dá errado.

Digite https://lab.becomeqa.com em um browser e quatro coisas acontecem em sequência:

• Lookup DNS. O browser pergunta "qual é o IP do lab.becomeqa.com?" Recebe de volta algo como 104.21.8.42. Nomes de domínio são só aliases.
• Conexão TCP. O browser se conecta a esse IP na porta 443, que é a porta HTTPS padrão.
• Handshake TLS. Browser e servidor verificam identidades e negociam criptografia. É o S do HTTPS.
• Requisição/resposta HTTP. O browser envia GET / HTTP/1.1, o servidor devolve HTML.

Sub-100ms em uma conexão decente.

"Connection refused" é um problema diferente de "SSL certificate error", que é diferente de "404 Not Found." Três pontos diferentes nessa cadeia. Se você não conhece a cadeia, todo erro de rede parece igual e depurar leva cinco vezes mais tempo.

Básico de HTTP: requisições têm um método (GET lê, POST cria, PUT/PATCH atualiza, DELETE remove), um caminho, headers e opcionalmente um corpo. Respostas têm status codes: 200 é ok, 404 é caminho não encontrado, 500 significa que o próprio servidor travou. Cada clique e submit de formulário em um teste Playwright é uma dessas requisições acontecendo por baixo.

8. Git básico

Git é como o código de teste é compartilhado, versionado e publicado. Você o usa para armazenar seus testes, manter-se sincronizado com os desenvolvedores e disparar execuções de CI. Você não precisa entender os internos do git. Seis comandos e um arquivo de configuração é tudo.

git clone <repo-url>            # baixar o projeto para sua máquina
git pull                        # pegar as últimas mudanças do seu time
git checkout -b add-login-tests # criar uma branch para seus novos testes
git add tests/login.spec.ts     # preparar o arquivo que você mudou
git commit -m "add login tests" # salvar um snapshot com uma mensagem
git push origin add-login-tests # subir sua branch para o GitHub/GitLab

Clone uma vez. Pull antes de começar cada dia. Branch por feature. Push quando terminar. Esse é o loop.

O Playwright gera pastas cheias de screenshots, vídeos e relatórios HTML quando os testes rodam. Nada disso pertence ao repositório. Crie .gitignore na raiz do projeto:

node_modules/
playwright-report/
test-results/
.env

Pule esse arquivo e você vai subir centenas de megabytes de artifacts de teste. Seus colegas de time vão descobrir quem fez isso.

Testes passam localmente mas falham no GitHub Actions. Muito comum. Primeira coisa a verificar:

git log --oneline -5     # ver os últimos 5 commits
git diff main            # ver o que mudou em relação à branch main

Geralmente é um arquivo que você esqueceu de git add, ou uma versão de dependência que difere entre sua máquina e o ambiente de CI. O git log mostra exatamente o que foi commitado e o que não foi.

9. Agile/Scrum: fale a língua do time

A habilidade mais fácil da lista. A mais ignorada por quem está fazendo transição de carreira. Você não precisa de certificação. Você precisa não parecer confuso no seu próprio standup.

O que realmente importa: o que é uma sprint e como os standups funcionam. Standups seguem um padrão simples: o que você fez, o que vai fazer hoje, o que te bloqueia. Também importa o que é uma user story e o que "definition of done" significa do ponto de vista de QA, porque é diferente do que um desenvolvedor quer dizer.

A maioria dos times usa Jira. A ferramenta específica muda de empresa para empresa. Os conceitos não.

Quanto tempo leva de verdade?

Resposta honesta: quatro a seis meses de 1 a 2 horas por dia coloca a maioria das pessoas prontas para uma vaga de entrada. Isso assumindo que você está realmente praticando, não só lendo.

Quem demora mais quase sempre tem o mesmo padrão: duas semanas de prática intensa, depois nada por seis semanas. Consistência bate intensidade. Uma hora chata todo dia bate um fim de semana heroico todo mês.

FAQ

Não. A maioria dos engenheiros de automação de QA não tem graduação em TI. O que gera contratação é um repositório no GitHub com testes bem escritos e a capacidade de explicar o que eles fazem. Graduação não prova isso. Testes provam.

Playwright para quem está começando do zero em 2026. Se você está entrando em uma empresa que já usa Selenium, aprenda o setup deles. Para aprendizado novo, Playwright é mais rápido de pegar, melhor documentado e mantido ativamente.

Dá para gerenciar. Você não está construindo apps. Está lendo e escrevendo testes. É uma fatia pequena da linguagem. A maioria das pessoas fica confortável em quatro a seis semanas de prática diária.

lab.becomeqa.com, um repositório no GitHub com seus arquivos de teste, automatizando fluxos em sites públicos. Um portfólio que você consegue percorrer em um screen share durante uma entrevista vale mais do que qualquer certificação que existe.