SDET soa como cargo inventado pra deixar o LinkedIn bonito, mas o papel é real e resolve um problema chato: qualidade não pode ser responsabilidade de um time que entra só no fim.
SDET não é QA com outro nome
O QA clássico recebe a feature pronta e sai procurando onde quebra. O SDET entra antes, escreve código e trata qualidade como parte do produto. A diferença não é a ferramenta, é o momento e a mentalidade.
Dono da qualidade significa se preocupar com testabilidade da arquitetura, com o que é fácil ou impossível de verificar, com o custo de cada teste. Achar bug é consequência, não o objetivo.
Estratégia antes de sair automatizando
O erro mais comum é automatizar tudo que aparece pela frente. Seis meses depois você tem 800 testes E2E lentos que ninguém confia e todo mundo ignora.
Estratégia é decidir o que vale automatizar, em qual nível, e o que deixar de fora. Um teste que ninguém lê quando quebra é pior que teste nenhum: dá falsa sensação de segurança e ainda cobra manutenção.
A pirâmide (e por que a maioria monta ela invertida)
A pirâmide de testes é simples: muita coisa em unit, um pouco em integração, pouquíssimo em E2E. Rápido e barato embaixo, caro e frágil em cima.
A maioria dos times monta o cone de sorvete: uma pilha de testes E2E frágeis e quase nada de unit. Fica bonito no relatório de cobertura e insuportável na prática — cada deploy vira loteria. Se seus testes de UI são a primeira linha de defesa, algo já saiu do lugar bem antes.
Teste flaky é dívida, não detalhe
Teste flaky é aquele que passa e falha sem você mudar nada. Parece inofensivo. Não é. Ele treina o time a ignorar o vermelho, e no dia que quebrar de verdade ninguém vai olhar.
Regra dura: teste flaky ou conserta ou sai da suíte. Deixar 'só esse' ali é como deixar uma janela quebrada — em pouco tempo metade da suíte é ruído e o CI vira decoração que todo mundo aprende a ignorar.
Automação sem CI é teatro
Teste que roda só na sua máquina não protege ninguém. O valor aparece quando ele roda em cada pull request e trava o merge se quebrar.
Uma suíte rápida e confiável no pipeline muda o comportamento do time: dá pra refatorar sem medo, porque o CI avisa na hora. Suíte lenta e instável faz o oposto — todo mundo aprende a dar skip e clicar em 'merge' assim mesmo.
Quando o manual ainda ganha
Automação não mata o teste manual, muda o foco dele. Robô é ótimo pra repetição e péssimo pra julgamento. Exploratório, usabilidade, aquele 'isso tá estranho' que ninguém escreveu no requisito — é território humano.
Bom SDET automatiza o repetitivo pra liberar tempo de gente pro que exige cabeça. Testar na mão o mesmo fluxo pela milésima vez não é dedicação, é desperdício.
SDET trabalha COM o dev, não contra
SDET que joga bug por cima do muro e some vira inimigo do time. O papel bom é o oposto: aproximar. Ajudar o dev a escrever teste, revisar testabilidade no PR, deixar a qualidade fácil de fazer.
Quando funciona, a fronteira entre 'quem desenvolve' e 'quem testa' some. Todo mundo vira dono da qualidade, e o SDET é quem entrega as ferramentas pra isso acontecer.
No fim, SDET não é a pessoa que aperta o botão de testar no último minuto. É quem faz o time inteiro conseguir entregar rápido sem quebrar tudo — e isso vale muito mais que qualquer relatório de bug bonito.
