O mesmo título "SDET" pode descrever alguém clicando manualmente em uma aplicação web e alguém projetando a infraestrutura de uma plataforma de testes usada por 200 engenheiros. O setor nunca padronizou qual trabalho cada título representa. Filtrar vagas por título desperdiça meses nas posições erradas.
Por que os títulos de trabalho em QA são completamente bagunçados
A maioria dos setores tem títulos que significam mais ou menos a mesma coisa em diferentes empresas. Um contador faz trabalho de contabilidade. Um engenheiro civil projeta obras de engenharia civil. Em QA, o mesmo título pode descrever dois trabalhos que quase não têm sobreposição no dia a dia.
O caos vem de algumas fontes. Os testes como disciplina evoluíram rápido: de testadores manuais dedicados nos anos 1990, para cargos focados em automação nos anos 2000, para posições com forte carga de engenharia hoje. Os títulos nunca foram padronizados no setor. As empresas também copiam e colam títulos de job boards sem pensar no que significam. Alguém de RH vê "QA Automation Engineer" numa vaga de um concorrente e republica o mesmo título mesmo que o trabalho real seja 90% manual. Os requisitos de habilidades de automação também mudaram drasticamente em pouco tempo, e o mercado não se atualizou com o vocabulário.
O resultado: "QA Engineer", "Software QA Engineer", "QA Automation Engineer", "SDET" e "Software Development Engineer in Test" podem descrever qualquer coisa. Desde clicar manualmente em uma aplicação web até projetar infraestrutura para uma plataforma de testes usada por 200 engenheiros.
Isso significa que você não pode usar o título para entender o trabalho. Você precisa ler os requisitos de verdade. Mais sobre isso adiante.
O que "QA Engineer" significa hoje
Historicamente, QA Engineer significava testes manuais. Testes exploratórios, escrita de casos de teste em planilhas ou Jira, rastreamento de bugs, talvez coordenação de aprovações de releases. Sem necessidade de código.
Essa definição está em grande parte obsoleta, mas o título permanece e hoje pode significar uma ampla gama de coisas. Na prática, quando uma empresa posta uma vaga de "QA Engineer" em 2026, geralmente quer alguém que faz testes manuais como trabalho principal com alguma automação como complemento. "Alguma automação" pode significar rodar os testes Playwright de outra pessoa, escrever alguns scripts em um framework existente, ou manter coleções no Postman para smoke tests de API.
Imagine esse cenário: uma startup de 40 pessoas tem um time de produto lançando features a cada duas semanas. Eles abrem vaga para "QA Engineer". O que precisam de verdade é de alguém que trabalhe próximo de desenvolvedores e gerentes de produto. Que identifique problemas antes que features cheguem ao usuário, escreva casos de teste que documentem o comportamento esperado, e conduza a conversa sobre qualidade durante o planejamento do sprint. Se essa pessoa também conseguir escrever alguns testes de smoke automatizados, ótimo. Mas o cargo é fundamentalmente sobre julgamento de qualidade do produto, não sobre output de engenharia.
Esse é o perfil ideal de QA Engineer na maioria das contratações fora de empresas de tecnologia: alguém que entende o produto profundamente, comunica defeitos com clareza. Tem exposição suficiente à automação para não ser travado por ela.
A faixa salarial para QA Engineers nesse sentido tradicional é a mais baixa dos três títulos discutidos aqui. A diferença reflete o diferencial de demanda técnica, não um julgamento de valor sobre o trabalho.
O que SDET significa e de onde veio
SDET significa Software Development Engineer in Test. A Microsoft criou esse título no início dos anos 2000 com uma definição precisa: um SDET escreve código de qualidade de produção que testa software. Os critérios de engenharia são os mesmos dos desenvolvedores de software.
Na Microsoft, SDETs eram engenheiros completos que focavam em testabilidade e infraestrutura de qualidade em vez de features de produto. Eles projetavam frameworks de testes, escreviam ferramentas que o restante da organização de QA usava, e revisavam código de produção para testabilidade. A responsabilidade se estendia a subsistemas inteiros da plataforma de testes. Um SDET sênior podia passar seis meses construindo um sistema de execução de testes distribuída que reduzia o tempo de CI de duas horas para quinze minutos. Sem escrever nenhum teste de produto em si.
Essa definição com foco em engenharia se espalhou, mas foi diluída. Hoje "SDET" é usado de forma inconsistente. Em empresas como Amazon, Google ou Meta, SDET ainda significa o que a Microsoft pretendia: engenharia de software séria aplicada à qualidade. O critério de codificação é próximo ao de um engenheiro de software. Em empresas menores, "SDET" às vezes significa apenas "queremos mais rigor de engenharia do que o título QA Engineer implica".
Um exemplo concreto de trabalho real de SDET: uma empresa rodando 8.000 testes end-to-end percebe que o pipeline de CI leva 90 minutos. Um SDET é encarregado de resolver isso. Ele analisa a distribuição dos testes e constrói um sistema de sharding que paraleliza a execução em 20 containers. Também escreve infraestrutura como código para provisioná-los dinamicamente e adiciona ferramentas de observabilidade para que testes flaky sejam detectados e quarentenados. Ao fim do projeto, o tempo total de CI é 12 minutos. O SDET provavelmente escreveu 500 linhas de código de testes de produto nesse trimestre e 3.000 linhas de código de framework e infraestrutura.
Isso não é trabalho de QA. É trabalho de engenharia de software que torna o trabalho de QA possível.
Vagas de SDET em empresas que aplicam o título rigorosamente pagam significativamente mais do que vagas de QA Engineer: tipicamente 20 a 35% a mais para níveis equivalentes de senioridade. O diferencial varia por empresa e região. Especificamente nas grandes empresas de tecnologia, SDETs costumam estar na mesma faixa de remuneração que engenheiros de software.
O que QA Automation Engineer significa
Essa é a posição do meio, e o título mais comum que você vai ver em 2026.
Um QA Automation Engineer escreve testes automatizados e mantém o framework em que esses testes rodam. É mais focado em código do que um QA Engineer tradicional: automação não é uma tarefa secundária, é o trabalho principal. Mas não está construindo infraestrutura de testes do zero como um SDET faria. Trabalha dentro de um framework existente, expandindo-o e escrevendo a cobertura de testes de verdade.
Na prática: um time usa Playwright com TypeScript, tem uma estrutura de Page Object Model no lugar, e roda testes no GitHub Actions. Um QA Automation Engineer entra e gasta 70 a 80% do tempo escrevendo novos testes para features conforme são entregues. Atualiza testes existentes quando a UI muda, investiga testes flaky e melhora a confiabilidade da suite. Pode adicionar um utilitário auxiliar ao framework, melhorar o reporting de erros, ou configurar uma nova suite de testes para uma nova área do produto. Redesenhar a arquitetura do framework é território de SDET.
O cenário fica assim: um desenvolvedor entrega um novo fluxo de checkout. O QA Automation Engineer lê os critérios de aceite e escreve seis testes Playwright cobrindo o happy path e os principais casos extremos. Roda localmente contra o ambiente de staging, encontra dois casos extremos que não foram tratados e abre bugs. Faz merge dos testes para a branch principal depois que os bugs são corrigidos. Um trabalho rotineiro de dois dias. Sem design de framework, sem trabalho de infraestrutura. Só cobertura de testes automatizados sólida e bem estruturada para uma feature real.
Esse é o trabalho de QA Automation Engineer. Exige capacidade real de codificação: escrever código de teste limpo e legível em uma linguagem real, entender padrões assíncronos, trabalhar com controle de versão. E debugar falhas sem depender de desenvolvedores. Não exige background em engenharia de software.
O salário fica entre QA Engineer e SDET. Empresas contratando QA Automation Engineers geralmente estão dispostas a pagar significativamente mais do que pelo QA tradicional. Precisam de output de código, mas não estão conduzindo um loop completo de entrevista de engenharia.
Como descobrir o que uma vaga realmente quer
Ignore o título completamente. Vá direto para a seção de requisitos e procure três sinais.
Sinal 1: Que linguagem de programação e framework eles mencionam? Se dizem "experiência com Playwright, Selenium ou Cypress", querem automação de testes. Se especificam "habilidades fortes de programação em Python ou Java" e listam construção de frameworks ou trabalho de "infraestrutura de testes", você está olhando para território de SDET. Se os requisitos mencionam Jira, TestRail ou "documentação de casos de teste" mas codificação é opcional ou secundária, é uma vaga de QA com foco manual. Sinal 2: O que o trabalho do dia a dia envolve? "Você vai escrever testes automatizados para novas features" é trabalho de QA Automation Engineer. "Você vai projetar e manter nosso framework de automação de testes" pende para SDET. "Você vai coordenar testes entre releases e gerenciar o ciclo de vida de defeitos" é QA Engineer tradicional. Sinal 3: Com quem eles dizem que você vai trabalhar? Trabalhar próximo de "gerentes de produto e desenvolvedores" sinaliza foco em qualidade de produto (QA Engineer). Trabalhar com "o time de plataforma para melhorar a confiabilidade do CI" ou "engenheiros de infraestrutura" sinaliza trabalho de tipo SDET.Um exemplo de contraste real. A vaga A diz: "3+ anos de experiência com automação, Playwright ou Selenium obrigatório, habilidades fortes em TypeScript, experiência escrevendo suites de testes E2E." Isso é uma vaga de QA Automation Engineer independente do título.
A vaga B diz: "Habilidades fortes de codificação obrigatórias, experiência construindo frameworks de testes, conhecimento de sistemas distribuídos como diferencial, projetar infraestrutura de testes para centenas de engenheiros." Isso é uma vaga de SDET mesmo que o título diga "QA Engineer".
Leia também a seção "nice to have". Se listam Docker, Kubernetes, administração de plataforma de CI, ou ferramentas de observabilidade de testes como diferenciais, a empresa está pensando em termos de SDET. Mesmo que o título não diga isso.
Qual caminho seguir com base no seu perfil
Se você vem de um background completamente não técnico (suporte, gestão de projetos, análise de negócios), comece pela trilha de QA Engineer. Construa fundamentos de testes, fique confortável com Jira e rastreamento de defeitos, e adicione habilidades básicas de automação com o tempo. O cargo de QA Engineer é o ponto de entrada mais acessível. As empresas se importam mais com pensamento sobre o produto e comunicação do que com output de código.
Se você tem algum background de codificação (bootcamp de desenvolvimento web, experiência com scripts, trabalho em TI), vá direto para QA Automation Engineer. Você já tem o modelo mental para escrever código; o que precisa é do conhecimento específico de testes por cima: como suites de testes são estruturadas, Playwright, integração com CI. Essa é a trilha mais rápida para uma vaga bem remunerada em QA para a maioria de quem está em transição de carreira.
Se você tem background em desenvolvimento de software, um diploma em TI, ou vários anos de experiência em desenvolvimento, SDET é o alvo certo. O diferencial de remuneração é significativo e o trabalho é genuinamente interessante em nível técnico. O processo de entrevista é mais difícil, mas suas habilidades existentes se transferem diretamente.
Uma observação: o título de QA Automation Engineer é onde a maioria do crescimento de carreira acontece para pessoas que entram como QA Engineers e querem avançar sem migrar para desenvolvimento puro. Adicionar habilidades de automação a uma base de QA Engineer é uma trilha confiável para remuneração maior e trabalho mais interessante.
O que isso significa para sua busca de emprego
Pare de filtrar por título. Filtre por requisitos. Quando estiver montando sua lista de candidaturas, faça duas verificações rápidas em cada vaga: o trabalho descrito combina com meu nível atual de habilidade? A expectativa de codificação combina com o que consigo demonstrar numa entrevista?
Se você mira vagas de QA Automation Engineer, seu portfólio precisa mostrar código de testes. Não descrições de trabalho de automação. Arquivos de teste de verdade no GitHub, organizados de forma limpa, com um readme que explica o que os testes fazem e como rodá-los. Um gerente de contratação quer ver código de teste que um desenvolvedor respeitaria: legível, manutenível, organizado de forma cuidadosa.
Se você mira vagas de SDET, você precisa disso mais evidência de julgamento de engenharia. Decisões de design de framework que você tomou e por quê. Trabalho de infraestrutura. Idealmente, algo que você construiu que outras pessoas usaram. A entrevista de SDET vai aprofundar mais do que "você consegue escrever um teste Playwright?", então esteja pronto para discutir trade-offs de design.
Se você mira vagas de QA Engineer, seu portfólio deve mostrar pensamento sobre qualidade: bug reports bem escritos, planos de teste para features não triviais, exemplos de casos extremos que você encontrou e que importaram. Automação é um diferencial, não o argumento central.
O mercado paga significativamente mais para cargos mais altos no espectro de engenharia. Isso não é um argumento de que o trabalho tradicional de QA tem menos valor; bom julgamento de qualidade de produto é genuinamente difícil de encontrar. É uma observação factual sobre o que o mercado precifica atualmente. Saber em qual direção você está construindo ajuda a investir o tempo de aprendizado nos lugares certos.
Os três títulos descrevem três trabalhos diferentes. O caos vem do fato de que ninguém concordou em qual título vai com qual trabalho. Agora que você sabe o que procurar nos requisitos, o caos deixa de ser um problema.
→ Veja também: Carreira em QA: De Júnior a Engenheiro QA Sênior | Descrição de Vaga QA Automation Engineer: O que as Empresas Realmente Querem | Como Construir um Portfolio de QA que Te Contrata (GitHub + Playwright) | QA Manual vs QA Automação: Quem Ganha Mais em 2026?
