QA Engineer Brasil 2026: Test Automation

Você está mandando currículo para vaga de QA Engineer, sabe testar bem, já achou bug que salvou release, mas chega na entrevista e parece que sempre falta “automação”, “CI/CD”, “Playwright”, “contrato”, “API”, “shift-left” ou alguma sigla nova. A sensação é chata: você não é iniciante, mas também não sabe exatamente o que o mercado brasileiro vai cobrar de QA em 2026.

QA Engineer Brasil 2026: Test Automation#

Se você quer crescer como QA Engineer no Brasil em 2026, a palavra-chave é clara: automação de testes com impacto real no produto.

Não basta dizer “sei Selenium” ou “já automatizei alguns fluxos”. Empresas como Nubank, Itaú, Stone, iFood, Magalu e Globo estão procurando pessoas que entendem risco, qualidade, entrega contínua e conseguem criar uma estratégia de testes que ajuda o time a lançar software com menos medo.

E sim, ainda existe espaço para QA manual. Só que o QA que combina análise crítica, automação, testes de API e comunicação com produto tende a disputar vagas melhores, inclusive posições remotas pagando de R$ 10k a R$ 18k no Brasil, ou vagas internacionais entre $60k e $100k por ano, dependendo do inglês e da senioridade.

Vamos falar de forma prática sobre o que aprender, como se posicionar, quais ferramentas importam e como montar um currículo que não morre no ATS.

O que mudou para QA Engineer no Brasil#

Durante muito tempo, muita empresa tratou QA como “a pessoa que testa no final”. O dev terminava, jogava no ambiente de homologação, e o QA tinha que sair clicando para ver se quebrava.

Esse modelo ainda existe, principalmente em empresas mais tradicionais. Mas ele está perdendo força, porque é caro, lento e estressa todo mundo.

Em 2026, os times mais maduros querem QA participando antes:

1. Na definição da história.
2. Na análise de critérios de aceite.
3. Na identificação de riscos.
4. Na criação de cenários automatizados.
5. Na validação de API e contrato.
6. No monitoramento de bugs em produção.

Isso muda o papel do QA Engineer.

Você deixa de ser apenas “quem encontra bug” e passa a ser alguém que ajuda o time a prevenir bug.

Na prática, isso aparece nas vagas com frases como:

• “Experiência com automação de testes end-to-end”
• “Conhecimento em testes de API”
• “Vivência com pipelines CI/CD”
• “Experiência com Cypress, Playwright ou Selenium”
• “Conhecimento em BDD”
• “Perfil colaborativo com squads ágeis”
• “Experiência com testes em microsserviços”

Se você lê isso e pensa “tenho pedaços disso, mas não tudo”, calma. A maioria dos candidatos também não tem tudo.

O segredo é organizar seus estudos e seu currículo em torno do que o mercado realmente valoriza.

Manual tester ainda tem espaço?#

Tem, mas com um aviso importante: QA manual puro tende a ficar mais limitado em salário e oportunidades.

Uma pessoa QA manual júnior no Brasil pode encontrar vagas entre R$ 3k e R$ 5k. Pleno pode ficar entre R$ 6k e R$ 9k. Sênior manual, em empresas maiores, pode chegar a R$ 10k ou R$ 12k, especialmente se tiver conhecimento forte de negócio, mobile, dados ou produtos financeiros.

Só que quando automação entra bem no pacote, a faixa sobe.

Um QA Automation pleno pode mirar algo entre R$ 8k e R$ 13k. Um QA Automation sênior pode disputar R$ 14k, R$ 18k ou mais em fintechs, bancos digitais, consultorias internacionais e empresas com produto próprio.

Em empresas como Itaú, Nubank, Stone e iFood, você vai ver combinações de:

• Testes automatizados para web.
• Testes de API.
• Qualidade em pipeline.
• Observabilidade básica.
• Dados para tomada de decisão.
• Comunicação forte com dev, produto e design.

O ponto não é abandonar teste manual.

O ponto é usar teste manual onde ele faz sentido: exploração, análise de risco, experiência do usuário, cenários novos e validações que ainda não merecem automação.

Automatizar tudo sem pensar também é erro de QA inexperiente.

O kit básico de automação para 2026#

Se você está tentando decidir por onde começar, não escolha ferramenta só porque está na moda. Escolha uma combinação que apareça em vaga e que permita mostrar resultado.

Para o mercado brasileiro em 2026, um kit forte seria:

1. JavaScript ou TypeScript

Playwright e Cypress são muito usados com JavaScript ou TypeScript. Se você já sabe lógica, vale investir em TypeScript porque dá mais clareza, ajuda em projetos maiores e aparece bastante em times modernos.

Você não precisa virar dev full stack.

Mas precisa saber:

• Variáveis, funções e arrays.
• Promises e async/await.
• Organização de arquivos.
• Boas práticas básicas.
• Como ler erro no terminal.
• Como usar npm.
• Como versionar no Git.

Se seu currículo diz “automação com Cypress”, mas você trava quando perguntam como tratar uma requisição assíncrona, a entrevista complica.

2. Playwright ou Cypress

Cypress cresceu muito no Brasil, principalmente em aplicações web. Playwright vem ganhando espaço forte porque lida bem com múltiplos navegadores, paralelização e cenários modernos.

Qual aprender primeiro?

Se você está começando hoje, eu recomendaria Playwright com TypeScript. Mas se as vagas da sua região ou empresas-alvo pedem Cypress, vá de Cypress sem culpa.

O que importa não é decorar comando. É saber criar testes úteis:

• Login com massa controlada.
• Cadastro com dados dinâmicos.
• Compra ou pedido em e-commerce.
• Validação de mensagens de erro.
• Interceptação de chamadas.
• Execução headless no pipeline.
• Relatório de falhas.
• Screenshots e vídeos quando quebra.

Pense em um fluxo do Magalu: buscar produto, adicionar ao carrinho, validar frete e finalizar pedido até antes do pagamento. Isso é um exemplo melhor de portfólio do que um teste simples de “clicar no botão”.

3. Testes de API

Muita gente entra em automação pela tela, mas QA forte testa API também.

E empresas amam isso por um motivo simples: teste de API costuma ser mais rápido, mais estável e pega problema antes do front.

Você pode usar:

• Postman.
• Bruno.
• Insomnia.
• REST Assured, se for Java.
• Supertest, se for JavaScript.
• Playwright API testing.

Você deve saber validar:

1. Status code.
2. Contrato da resposta.
3. Campos obrigatórios.
4. Mensagens de erro.
5. Autenticação.
6. Permissões.
7. Cenários de limite.
8. Idempotência, quando fizer sentido.

Imagine uma API de pagamento da Stone. Você não quer descobrir só pela interface que uma transação aprovada voltou com campo incorreto. Um teste de API bem feito pega isso antes.

4. Git e CI/CD

Esse é um divisor de águas em entrevista.

Muitos candidatos sabem rodar teste local. Menos candidatos sabem colocar isso no GitHub Actions, GitLab CI, Jenkins ou Azure DevOps.

Você não precisa ser especialista em DevOps. Mas precisa entender:

• Como abrir pull request.
• Como rodar testes em cada push.
• Como falhar pipeline quando teste crítico quebra.
• Como gerar relatório.
• Como separar smoke, regressão e testes completos.
• Como usar variáveis de ambiente.

Um projeto no GitHub com Playwright, README decente e pipeline rodando já coloca você acima de muita gente.

A pirâmide de testes ainda importa?#

Sim, mas sem virar religião.

A pirâmide de testes diz que você deve ter muitos testes unitários, uma camada média de testes de integração/API e poucos testes end-to-end pela interface.

Na vida real, muita empresa brasileira tem uma “casquinha de sorvete”: muitos testes manuais e E2E frágeis, poucos testes unitários e quase nada de integração.

Como QA, você pode ajudar a corrigir isso.

Você não precisa escrever todos os testes unitários do time, mas precisa conversar com devs sobre cobertura, risco e onde cada teste deve morar.

Um bom raciocínio em entrevista seria:

“Eu não automatizaria todos os cenários pela UI. Para regras de negócio e validações de contrato, eu priorizaria API ou integração. Pela interface, deixaria os fluxos críticos de usuário, como login, checkout, contratação ou cancelamento.”

Isso soa maduro.

Bem mais maduro do que “eu automatizo tudo com Selenium”.

Ferramentas que aparecem bastante em vagas#

Você não precisa aprender todas. Mas precisa reconhecer o que elas fazem.

Automação web

• Playwright
• Cypress
• Selenium
• WebdriverIO

Selenium ainda existe muito em bancos, consultorias e sistemas legados. Itaú e grandes consultorias podem ter muita coisa em Java com Selenium. Já startups e empresas de produto podem preferir Cypress ou Playwright.

API

• Postman
• Bruno
• REST Assured
• Supertest
• Karate DSL

Karate aparece em alguns times por ser bom para API e contrato. REST Assured aparece forte em ecossistemas Java.

Mobile

• Appium
• Maestro
• Detox

Se você quer QA mobile, principalmente em fintech, delivery ou mídia, mobile pode ser diferencial. Nubank, iFood e Globo têm produtos mobile críticos, então saber testar Android e iOS é bem valorizado.

Performance

• k6
• JMeter
• Gatling

Você não precisa ser especialista para toda vaga de QA Automation. Mas se você souber criar um teste básico de carga com k6, explicar percentil 95 e identificar gargalo simples, isso chama atenção.

Qualidade e gestão

• Jira
• Azure DevOps
• TestRail
• Zephyr
• Xray
• Qase

Ferramenta de gestão não contrata sozinha, mas mostra que você sabe trabalhar em processo real.

O que colocar no portfólio de QA Automation#

Portfólio de QA é subestimado.

Dev mostra GitHub. Designer mostra Behance. QA muitas vezes só manda currículo e torce.

Você pode se destacar com 2 ou 3 projetos bem montados.

Projeto 1: Automação web com Playwright

Escolha um site de prática ou uma aplicação demo. Evite automatizar site real de empresa sem cuidado, porque mudanças externas podem quebrar seu projeto.

Inclua:

• TypeScript.
• Page Object ou padrão similar.
• Testes de login, cadastro e fluxo crítico.
• Dados dinâmicos.
• Relatório HTML.
• Screenshots em falha.
• GitHub Actions.
• README explicando como rodar.

No README, escreva como profissional:

• Objetivo do projeto.
• Tecnologias usadas.
• Estrutura de pastas.
• Como executar localmente.
• Como ver o relatório.
• Decisões técnicas.
• Próximos passos.

Isso mostra comunicação, não só código.

Projeto 2: Testes de API

Use uma API pública de prática ou crie uma simples.

Inclua:

• Cenários positivos e negativos.
• Validação de schema.
• Autenticação, se possível.
• Variáveis de ambiente.
• Relatório.
• Execução no CI.

Você pode fazer com Postman e Newman, ou com Playwright API testing.

Projeto 3: Estratégia de testes

Esse é diferente e poderoso.

Crie um documento no GitHub com uma estratégia de testes para um produto fictício, por exemplo:

“App de delivery estilo iFood”

Inclua:

1. Riscos principais.
2. Fluxos críticos.
3. O que testar manualmente.
4. O que automatizar na UI.
5. O que testar na API.
6. Critérios de entrada e saída.
7. Plano de smoke test.
8. Métricas de qualidade.
9. Bugs exemplos com severidade e prioridade.

Muita entrevista de QA sênior é sobre pensamento, não ferramenta. Esse projeto mostra como você pensa.

Como responder entrevistas de QA em 2026#

Entrevistador não quer só saber se você decorou comandos. Ele quer descobrir se você ajuda ou atrapalha o fluxo do time.

Prepare respostas para perguntas como:

“O que você automatizaria primeiro?”

Uma boa resposta:

“Eu começaria pelos fluxos críticos de negócio, de alto impacto e repetitivos. Por exemplo, login, criação de conta, pagamento, checkout ou contratação. Também avaliaria estabilidade do ambiente e massa de dados, porque automatizar em ambiente instável gera falso negativo e perde confiança do time.”

Isso mostra prioridade.

“Quando não vale automatizar?”

Resposta madura:

“Quando o fluxo muda toda semana, quando o custo de manutenção é maior que o ganho, quando é um cenário raramente usado, ou quando teste exploratório entrega mais valor. Eu também evitaria automatizar pela UI regras que podem ser validadas melhor em API ou unidade.”

Isso mostra que você não é refém de ferramenta.

“Como lidar com teste flaky?”

Teste flaky é aquele que falha às vezes sem bug real. Ele destrói credibilidade da automação.

Você pode dizer:

“Eu investigaria se é problema de espera, dados, ambiente, dependência externa ou paralelismo. Evitaria waits fixos e preferiria esperar por estado real da aplicação. Também isolaria massa de dados e registraria evidências para entender padrão da falha.”

Boa resposta.

“Como você mede sucesso da automação?”

Não diga só “pela cobertura”.

Melhor:

• Redução de bugs em produção.
• Menor tempo de regressão.
• Mais confiança para deploy.
• Falhas relevantes encontradas cedo.
• Menos retrabalho.
• Estabilidade dos testes.
• Tempo de execução aceitável.
• Adoção pelo time.

Automação boa não é quantidade de testes. É confiança útil.

Currículo de QA Engineer que passa no ATS#

ATS é o sistema que muitas empresas usam para filtrar currículos antes do recrutador ler. Se seu currículo está bonito, mas não tem palavras-chave certas, ele pode sumir.

Para QA Automation, seu currículo precisa falar a língua da vaga.

Inclua termos como:

• QA Engineer
• Quality Assurance
• Test Automation
• Automação de testes
• Playwright
• Cypress
• Selenium
• API testing
• Postman
• REST
• CI/CD
• GitHub Actions
• GitLab CI
• JavaScript
• TypeScript
• Java
• BDD
• Cucumber
• Jira
• Agile
• Scrum

Mas cuidado: não liste ferramenta que você não consegue defender.

Se você colocou “performance testing com k6”, esteja pronto para explicar VUs, thresholds e tempo de resposta.

Exemplo ruim de experiência

“Responsável por testar sistema, abrir bugs e participar de reuniões.”

Isso é genérico demais.

Exemplo melhor

“Criei suíte de automação com Cypress para fluxos críticos de login, cadastro e pagamento, reduzindo o tempo de regressão manual de 2 dias para 4 horas e aumentando a confiança nos deploys semanais.”

Muito melhor.

Outro exemplo bom

“Implementei testes de API com Postman e Newman no GitLab CI, validando contratos de endpoints críticos e reduzindo falhas identificadas tardiamente em homologação.”

Percebe a diferença?

Você mostra ferramenta, contexto e resultado.

Palavras-chave por nível de senioridade#

Seu currículo deve combinar com sua fase.

QA Júnior

Foque em base e vontade prática:

• Testes funcionais.
• Casos de teste.
• Relato de bugs.
• Jira.
• Noções de API.
• Postman.
• SQL básico.
• Git básico.
• Projeto pessoal com Cypress ou Playwright.

Salário comum: R$ 3k a R$ 5k, podendo passar disso em empresas maiores ou com inglês.

QA Pleno

Foque em autonomia:

• Planejamento de testes.
• Automação web.
• Testes de API.
• CI/CD.
• Critérios de aceite.
• Trabalho com squad.
• Análise de risco.
• Métricas de qualidade.

Salário comum: R$ 7k a R$ 12k, com chances de R$ 13k ou R$ 14k em empresas fortes.

QA Sênior

Foque em estratégia e influência:

• Estratégia de testes.
• Arquitetura de automação.
• Mentoria.
• Qualidade no ciclo de desenvolvimento.
• Testes em microsserviços.
• Contratos.
• Observabilidade.
• Performance básica.
• Decisões de trade-off.
• Comunicação com liderança.

Salário comum: R$ 13k a R$ 20k no Brasil, podendo passar disso em vagas remotas internacionais.

Inglês muda o jogo para QA#

Se você já tem automação e inglês intermediário para conversação, seu mercado aumenta muito.

Vagas internacionais para QA Automation podem pagar $50k a $90k por ano. Em posições mais fortes, com experiência em cloud, performance, backend e liderança técnica, pode passar de $100k.

Não precisa falar como nativo.

Você precisa conseguir:

• Explicar um bug.
• Participar de daily.
• Defender uma estratégia de teste.
• Escrever documentação.
• Entender requisito.
• Perguntar quando algo está ambíguo.

Uma frase simples e clara vale mais que tentar parecer sofisticado.

Treine respostas para entrevistas em inglês:

• “How do you decide what to automate?”
• “How do you handle flaky tests?”
• “What is your experience with CI/CD?”
• “Tell me about a critical bug you found.”
• “How do you work with developers?”

Se você trava no inglês, treine com roteiro. Grave sua resposta. Repita. Melhora mais rápido do que parece.

Como estudar sem se perder#

A maior armadilha é abrir 20 abas e não terminar nada.

Use um plano de 8 semanas.

Semanas 1 e 2: base de programação

• JavaScript ou TypeScript.
• Git e GitHub.
• npm.
• Async/await.
• Leitura de erros.

Meta: criar pequenos scripts e subir no GitHub.

Semanas 3 e 4: Playwright ou Cypress

• Instalação.
• Seletores.
• Assertions.
• Page Objects.
• Dados de teste.
• Screenshots.
• Relatório.

Meta: automatizar 5 a 8 cenários web.

Semana 5: API testing

• Métodos HTTP.
• Status codes.
• Headers.
• Body.
• Autenticação.
• Schema.
• Cenários negativos.

Meta: criar coleção ou suíte com 15 testes de API.

Semana 6: CI/CD

• GitHub Actions.
• Rodar testes no push.
• Publicar relatório.
• Separar smoke e regressão.

Meta: pipeline funcionando no GitHub.

Semana 7: estratégia de testes

• Pirâmide de testes.
• Risco.
• Critérios de aceite.
• Plano de regressão.
• Bugs bem escritos.
• Métricas.

Meta: escrever documento de estratégia para um produto fictício.

Semana 8: currículo e entrevista

• Ajustar LinkedIn.
• Reescrever currículo com resultados.
• Treinar perguntas.
• Fazer mock interview.
• Aplicar para vagas.

Meta: 20 candidaturas bem direcionadas, não 200 cliques aleatórios.

Como escrever bugs como profissional#

Parece detalhe, mas bug report ruim irrita dev e reduz sua credibilidade.

Um bom bug tem:

1. Título claro.
2. Ambiente.
3. Versão.
4. Usuário ou perfil.
5. Passos para reproduzir.
6. Resultado atual.
7. Resultado esperado.
8. Evidências.
9. Severidade.
10. Prioridade, se o processo usar.

Exemplo ruim:

“Botão não funciona.”

Exemplo bom:

“Checkout não finaliza pedido com cartão salvo no ambiente staging”

Passos:

1. Acessar conta com cartão salvo.
2. Adicionar produto ao carrinho.
3. Selecionar entrega padrão.
4. Escolher cartão salvo.
5. Clicar em finalizar pedido.

Resultado atual: sistema exibe erro genérico “Ops, tente novamente”.

Resultado esperado: pedido deve ser criado e usuário deve ver tela de confirmação.

Impacto: bloqueia compra para usuários com cartão salvo.

Isso ajuda o dev a resolver mais rápido e mostra maturidade.

QA em fintech, e-commerce, mídia e delivery#

Cada setor cobra um olhar diferente.

Fintechs como Nubank, Itaú e Stone

Aqui qualidade tem relação direta com dinheiro, risco, segurança e regulação.

Você precisa se preocupar com:

• Pagamento.
• Saldo.
• Extrato.
• Antifraude.
• Permissões.
• Auditoria.
• Dados sensíveis.
• Experiência mobile.
• Alta disponibilidade.

Um bug pequeno pode virar prejuízo grande.

E-commerce como Magalu

O foco é conversão e operação.

Pontos críticos:

• Busca.
• Estoque.
• Preço.
• Carrinho.
• Frete.
• Cupom.
• Pagamento.
• Pedido.
• Nota fiscal.
• Pós-venda.

Teste de API e contrato ajuda muito aqui, porque são vários sistemas conversando.

Delivery como iFood

Aqui tempo real pesa.

Você testa:

• Geolocalização.
• Restaurante aberto ou fechado.
• Cardápio.
• Pedido.
• Pagamento.
• Status de entrega.
• Notificações.
• Cancelamento.
• Reembolso.

Mobile e API são muito importantes.

Mídia como Globo

Você pode lidar com streaming, login, assinatura e alto volume de acesso.

Pontos importantes:

• Playback.
• Dispositivos diferentes.
• Login.
• Assinatura.
• Recomendação.
• Performance.
• Picos de audiência.
• Acessibilidade.

Se você adapta sua fala ao setor, a entrevista fica muito mais forte.

Erros que travam sua carreira em QA#

Alguns erros aparecem muito.

1. Só estudar ferramenta

Ferramenta muda. Fundamento fica.

Aprenda risco, técnica de teste, API, dados e comunicação.

2. Não saber explicar impacto

“Automatizei 100 testes” é menos forte que “reduzi regressão de 16 horas para 3 horas”.

3. Currículo sem números

Coloque números quando forem verdadeiros:

• “Reduzi tempo de regressão em 60%”
• “Automatizei 35 cenários críticos”
• “Cobri 12 endpoints de pagamento”
• “Apoiei 3 squads”
• “Participei de deploys semanais”

4. Não ter GitHub

Para QA Automation, GitHub ajuda muito. Não precisa ser perfeito, precisa ser legível.

5. Ignorar SQL

SQL básico ainda aparece muito.

Você deve saber:

• SELECT
• WHERE
• JOIN básico
• COUNT
• ORDER BY
• UPDATE em ambiente seguro, se aplicável
• Entender massa de dados

Muitos bugs vivem no banco.

6. Falar mal de dev

QA maduro não entra em guerra com dev.

Você pode discordar, apontar risco e defender qualidade sem criar clima ruim. Empresas querem gente que melhora o time, não alguém que transforma todo bug em briga.

O futuro do QA com IA#

IA vai mudar bastante o trabalho de QA, mas não vai eliminar quem pensa bem.

Ferramentas com IA já ajudam a:

• Gerar casos de teste.
• Sugerir cenários de borda.
• Criar dados sintéticos.
• Escrever automações iniciais.
• Resumir bugs.
• Analisar logs.
• Criar documentação.

Mas IA também inventa coisa, erra contexto e pode gerar teste frágil.

O QA valioso em 2026 vai saber usar IA como assistente, não como muleta.

Você pode usar IA para acelerar:

• Ideias de cenários.
• Refatoração de teste.
• Mensagens de bug.
• Geração de massa.
• Explicação de erro.

Mas você continua responsável por decidir o que importa.

Seu plano prático para conseguir vaga melhor#

Se eu fosse organizar sua evolução como QA Engineer para 2026, faria assim:

1. Escolha uma stack principal: Playwright com TypeScript ou Cypress com JavaScript.
2. Monte um projeto web com README e pipeline.
3. Monte testes de API com cenários positivos e negativos.
4. Aprenda o básico de SQL.
5. Escreva uma estratégia de testes no GitHub.
6. Ajuste seu currículo para cada vaga.
7. Coloque resultados, não só tarefas.
8. Treine respostas de entrevista.
9. Melhore seu inglês um pouco toda semana.
10. Candidate-se com consistência.

Não espere “estar pronto” para aplicar. Você melhora aplicando, errando entrevista, ajustando discurso e voltando mais forte.

Conclusão#

QA Engineer no Brasil em 2026 não é só a pessoa que clica em tela e abre bug. É a pessoa que entende risco, automatiza com critério, testa API, conversa com dev, participa cedo das decisões e ajuda o produto a chegar melhor ao usuário.

Se você quer vagas melhores, foque em automação útil, portfólio visível e currículo com palavras-chave certas. Mostre que você sabe pensar, não só rodar teste.

Antes de mandar mais candidaturas, vale conferir se seu currículo está passando pelos filtros certos. Teste grátis agora no ATS Checker da JobRise: https://jobrise.io/pt/free-ats-checker/