Todo mundo já viu um bug escapar pra produção num sexta à noite. O SDET é a pessoa que trata isso como falha de engenharia, não de azar.
O que é um SDET, afinal
SDET significa Software Development Engineer in Test. Traduzindo o crachá: é um engenheiro de software cuja especialidade é qualidade. Não é alguém que "testa depois que fica pronto" — é quem constrói as ferramentas, os frameworks e as automações que fazem a qualidade acontecer de forma repetível.
A sacada central é essa: o SDET escreve código para testar código. E olha o produto inteiro — API, banco, fila, front, pipeline — não só a telinha.
SDET não é QA manual com outro crachá
QA manual e SDET compartilham o objetivo (produto que funciona), mas o método é diferente. O QA manual explora o sistema como usuário, encontra o inesperado, valida fluxo e experiência — trabalho valioso e que não morre.
O SDET pega o que é repetitivo e determinístico e transforma em código que roda sozinho a cada commit. Regressão que levava duas horas de clique vira dois minutos de pipeline. A diferença não é "melhor ou pior": é manual e exploratório de um lado, automação e infraestrutura do outro.
E também não é só o dev que escreve teste
Todo bom dev escreve teste unitário do próprio código. Isso não faz dele SDET. O foco muda o ângulo.
O dev de produto pensa "como faço isso funcionar". O SDET pensa "de quantos jeitos isso quebra e como eu provo que não quebrou". Ele vive nas fronteiras: integração entre serviços, dados de teste, ambientes, contratos de API, flakiness. Constrói o test harness que o time inteiro usa. É desenvolvimento de verdade — só que o "produto" é a confiança no sistema.
A mentalidade: qualidade é problema de engenharia
Aqui mora o coração do papel. Qualidade não é uma etapa no fim, é uma propriedade que se projeta desde o começo.
O SDET pensa em risco: o que dói mais se quebrar? Onde vale investir automação e onde não vale? Ele odeia teste que passa quando devia falhar e teste que falha sem motivo — ruído destrói confiança. E é crítico por profissão: assume que tudo pode quebrar e desenha pra detectar rápido quando quebra. É ceticismo aplicado, não pessimismo.
As skills que o papel cobra
Na prática, o SDET precisa de:
- Programação de verdade. Uma linguagem bem (Python, Java, JS/TS...), estruturas de dados, código limpo. Automação ruim vira dívida técnica.
- Automação e frameworks. Playwright, Selenium, Cypress no front; testes de API e contrato; construir abstração, não só roteirizar clique.
- CI/CD. Teste que não roda no pipeline quase não existe. Entender GitHub Actions, GitLab CI, paralelização, gates de merge.
- Fundamentos. HTTP, banco, Docker, um pouco de rede e observabilidade. Pra testar o sistema é preciso entender o sistema.
Não precisa dominar tudo no dia um. Precisa estar disposto a aprender continuamente, porque o papel encosta em toda a stack.
Por onde a carreira começa
Existem dois caminhos comuns. Vem do QA manual e aprende a programar, trocando clique por código aos poucos. Ou vem do dev e migra o foco pra qualidade e infraestrutura de teste. Os dois funcionam.
Um começo honesto: automatize um fluxo que você hoje testa na mão. Depois coloque no CI. Depois torne confiável. A progressão vai de SDET júnior a sênior e a especialista em qualidade ou SET, e a base de engenharia abre portas pra platform e SRE também.
SDET não é QA "turbinado" nem dev "de segunda". É a engenharia de fazer o software provar, sozinho e o tempo todo, que ainda funciona. Se sexta à noite te dá calafrio, esse papel é sobre dormir tranquilo.
