Como começar em QA: o que estudar e como dar os primeiros passos

· Algoritmos e guias, QA e automação, Qualidade de software

Neste guia, você vai entender o que um profissional de QA faz no dia a dia, quais fundamentos estudar primeiro, como escrever casos de teste e bug reports que as pessoas realmente leem, o básico de HTTP, APIs, SQL e Git, e como montar seus primeiros projetos práticos usando o nosso Lab e a API de prática. No fim, sugiro uma rotina de estudo e aponto os erros mais comuns de quem está começando.

O que faz um QA, afinal?

QA (Quality Assurance) é a pessoa que ajuda o time a entregar software confiável. Isso vai muito além de “clicar na tela procurando erro”. Um bom QA participa desde o refinamento das histórias, fazendo perguntas que evitam ambiguidades, até a validação em produção. No meio do caminho, ele planeja testes, executa testes exploratórios, automatiza verificações repetitivas, analisa riscos e comunica problemas de forma clara.

Trabalho com qualidade de software desde 2010 e, se eu tivesse que resumir a profissão em uma frase, seria: QA é quem pergunta “e se?” antes que o usuário descubra a resposta. E se o campo vier vazio? E se a rede cair no meio do pagamento? E se dois usuários editarem o mesmo registro ao mesmo tempo? Curiosidade e comunicação valem tanto quanto qualquer ferramenta.

Fundamentos: tipos e níveis de teste

Antes de qualquer framework, aprenda o vocabulário. Ele aparece em entrevistas, em reuniões e em toda documentação séria.

Níveis de teste dizem respeito a “onde” o teste atua:

  • Unitário: verifica uma função ou classe isolada, geralmente escrito por quem desenvolve.
  • Integração: verifica se partes diferentes conversam bem (serviço com banco, front com API).
  • Sistema / ponta a ponta (E2E): valida o fluxo completo, como o usuário usaria.
  • Aceitação: confirma se o que foi entregue atende ao que o negócio pediu.

Tipos de teste dizem respeito a “o quê” está sendo avaliado: testes funcionais (o sistema faz o que deveria?), não funcionais (desempenho, usabilidade, acessibilidade, segurança), de regressão (o que funcionava continua funcionando?) e de confirmação (o bug corrigido foi mesmo corrigido?). Vale conhecer também a ideia da pirâmide de testes: muitos testes rápidos na base, menos testes lentos e caros no topo.

Técnicas de teste que você vai usar sempre

Ninguém consegue testar todas as combinações possíveis. Técnicas de teste existem para escolher bons casos com pouco esforço. Comece por duas:

Partição de equivalência: divida as entradas em grupos que o sistema deveria tratar da mesma forma e teste um representante de cada grupo. Se um campo aceita idade de 18 a 60 anos, há três partições: abaixo de 18 (inválida), de 18 a 60 (válida) e acima de 60 (inválida). Testar 25 e 40 não traz informação nova; testar 25, 10 e 70 traz.

Análise de valor-limite: erros adoram as bordas. No mesmo exemplo, teste 17, 18, 60 e 61. É ali que aparecem os clássicos “<” no lugar de “<=”.

Depois, explore tabela de decisão (para regras com várias condições), transição de estados (para fluxos como pedido criado, pago, enviado, cancelado) e teste exploratório guiado por sessões com um objetivo claro.

Como escrever casos de teste

Um caso de teste bom é aquele que outra pessoa consegue executar sem te chamar no chat. Ele tem um objetivo único, pré-condições, passos objetivos e um resultado esperado verificável. Um formato simples que funciona:

ID: CT-LOGIN-03
Título: Login bloqueado para usuário com conta travada
Pré-condição: usuário "locked_user" cadastrado e bloqueado
Passos:
  1. Acessar a tela de login
  2. Informar usuário "locked_user" e a senha correta
  3. Clicar em "Entrar"
Resultado esperado: o acesso é negado e uma mensagem
informa que a conta está bloqueada; o usuário permanece
na tela de login.

Precisa de dados para preencher formulários? O gerador de massa de testes e o validador de CPF ajudam a montar entradas válidas e inválidas rapidamente.

Como escrever um bug report que resolve

O bug report é o principal “produto” visível do QA. Ele precisa ser reproduzível, objetivo e sem tom de acusação. Inclua sempre:

  • Título que descreve o problema e onde ele acontece.
  • Ambiente (navegador, versão do app, sistema, ambiente de homologação ou produção).
  • Passos para reproduzir, numerados.
  • Resultado atual versus resultado esperado.
  • Evidências: print, vídeo, trecho de log, request e response.
  • Severidade (impacto técnico) e, se o time usar, prioridade (urgência de negócio).

Evite “não funciona” como descrição. Diga exatamente o que acontece. Para anexar logs legíveis, o formatador de log e o formatador JSON deixam a evidência muito mais fácil de analisar.

O básico de HTTP e APIs

Quase todo sistema moderno conversa por APIs, e muitos bugs nascem ali, não na tela. Entenda os conceitos principais: métodos (GET para consultar, POST para criar, PUT/PATCH para alterar, DELETE para remover), status codes (2xx sucesso, 4xx erro do cliente, 5xx erro do servidor), headers (como Content-Type e Authorization) e o corpo da requisição, geralmente em JSON.

Uma requisição típica, feita com curl, tem esta cara:

curl -X POST "https://exemplo.com/api/login" \
  -H "Content-Type: application/json" \
  -d '{"username": "standard_user", "password": "sua_senha"}'

Ao testar, pergunte: o que acontece sem o header de autenticação? Com um campo obrigatório faltando? Com um tipo errado? O status code faz sentido? Muitas APIs usam tokens JWT; o decodificador JWT mostra o que vai dentro deles, e o conversor de timestamp traduz campos de expiração.

SQL e Git: o mínimo que faz diferença

SQL permite conferir se o que a tela mostra corresponde ao que foi gravado, preparar dados e investigar bugs. Comece por SELECT com WHERE, ORDER BY, JOIN e funções de agregação:

SELECT p.id, p.status, c.email
FROM pedidos p
JOIN clientes c ON c.id = p.cliente_id
WHERE p.status = 'CANCELADO'
ORDER BY p.criado_em DESC;

Git é obrigatório assim que você começar a automatizar, porque seus testes vão viver no mesmo repositório (ou em um vizinho) do código. Aprenda o fluxo básico:

git clone <url-do-repositorio>
git checkout -b teste/login-bloqueado
git add .
git commit -m "Adiciona teste de login com usuário bloqueado"
git push origin teste/login-bloqueado

Depois disso, entenda o que é um pull request e como funciona uma revisão de código. Revisar e ser revisado é parte da rotina de quem automatiza.

Primeiros projetos práticos com o Lab

Teoria sem prática não se fixa, e portfólio vale mais que uma lista de cursos. Criamos o Lab justamente para isso: uma loja de prática com cinco versões de front-end (HTML puro, React, Vue, um front legado e outro com Shadow DOM), além de uma página de elementos difíceis. Sugestões de projetos, em ordem de dificuldade:

  • Projeto 1, manual: escolha um fluxo da loja (login, carrinho, checkout), escreva casos de teste aplicando partição de equivalência e valor-limite, execute e registre os bugs que encontrar.
  • Projeto 2, API: leia a especificação OpenAPI da API de prática, monte uma coleção de requisições e teste cenários positivos e negativos com usuários diferentes, como standard_user e locked_user.
  • Projeto 3, automação web: automatize o mesmo fluxo no front HTML e depois tente rodá-lo nos fronts React, Vue e Shadow DOM. Você vai aprender na prática por que seletores estáveis importam.
  • Projeto 4, automação de API: transforme a coleção do projeto 2 em testes automatizados com asserções de status, schema e conteúdo.

Publique cada projeto em um repositório com um README explicando o que foi testado, como rodar e o que você aprendeu. É isso que recrutadores e líderes técnicos querem ver.

Uma rotina de estudo possível

Constância vence intensidade. Em vez de maratonas no fim de semana, prefira blocos curtos e frequentes. Uma divisão que costuma funcionar:

  • Fase de fundamentos: conceitos de teste, técnicas, casos de teste e bug reports, sempre praticando no Lab.
  • Fase técnica: HTTP, APIs, SQL e Git, com o projeto de API como fio condutor.
  • Fase de automação: uma linguagem de programação e um framework de automação, aplicados aos projetos 3 e 4.
  • Em paralelo: leia sobre qualidade, acompanhe comunidades de teste e escreva sobre o que aprendeu. Explicar algo é a melhor prova de que você entendeu.

Se quiser uma referência estruturada para os fundamentos, o syllabus Foundation Level do ISTQB organiza bem o vocabulário da área e é a base da certificação CTFL (istqb.org, consultado em 13/10/2026).

Erros comuns de iniciantes

  • Pular direto para a automação. Automatizar sem saber o que testar só gera scripts frágeis que verificam pouco.
  • Testar só o caminho feliz. Os bugs mais caros moram nos cenários negativos e nas bordas.
  • Colecionar cursos sem projetos. Certificados ajudam, mas um repositório bem documentado mostra que você sabe fazer.
  • Bug reports vagos ou com tom de culpa. O objetivo é resolver o problema, não apontar quem errou.
  • Ignorar a API e o banco. Olhar só para a tela esconde metade dos problemas.
  • Ter medo de perguntar. Perguntar é literalmente parte do trabalho de QA.

Próximos passos