O QA quase morreu quatro vezes — e segue mais vivo que nunca

De tempos em tempos alguém anuncia, com bastante convicção, que o QA acabou. Já vi essa cena se repetir tantas vezes que virou quase um ritual da indústria. E, curiosamente, o QA continua aqui — mais central no processo de entrega do que era há dez anos.

Bora lá.

Primeira “morte”: automação (~2010)

A primeira onda foi a tese de que o desenvolvedor testaria o próprio código. Ferramentas de teste unitário maduraram, surgiram frameworks como Selenium, e a conclusão fácil foi: “se o dev escreve teste, pra que QA?”.

Na prática, teste unitário cobre a unidade. Não cobre o fluxo do usuário, não cobre a regra de negócio combinada com o legado, não cobre o caminho que ninguém pensou em cobrir. Automação multiplicou o trabalho de QA — não substituiu.

Segunda “morte”: ágil (~2012)

Veio o Scrum, veio o XP, e com eles a frase que todo QA viu pelo menos uma vez: “o time todo é responsável pela qualidade”.

Concordo. Sempre concordei. Mas “todo mundo é responsável” é diferente de “ninguém precisa cuidar disso em tempo integral”. O time vira responsável pela qualidade do mesmo jeito que vira responsável pelo banco de dados — alguém ainda precisa de profundidade no assunto.

O ágil não matou o QA. Ele matou o QA fora do time, aquele que recebia build no fim do mês para “validar”. Quem estava dentro do squad, fazendo shift-left, virou peça mais essencial ainda.

Terceira “morte”: DevOps (~2016)

Aí veio a era do “CI/CD resolve”. Pipeline robusto, testes automatizados rodando a cada commit, deploy contínuo. Pra que ter QA se a esteira já garante?

A esteira executa o que alguém escreveu. Ela não decide o que merece ser testado, não modela cenário, não negocia critério de aceitação, não olha pro produto e pergunta “e se o usuário fizer X em vez de Y?”. CI/CD virou multiplicador do trabalho de QA — quem domina pipeline + teste vale ouro. Esse carinha, o DevOps, virou amigo do QA, não substituto.

Quarta “morte”: IA (2023 em diante)

A onda atual: “o agente escreve teste sozinho, não precisa mais de QA”.

Aqui falo com skin in the game. Uso IA no fluxo desde 2024, todos os dias. Apoio em escrita de teste, planejamento, geração de cenário, revisão de PR. É ferramenta, igual IDE e terminal.

E mesmo com isso a parede continua lá: alguém precisa decidir o que vai ser testado, validar se o que foi gerado faz sentido, e cobrar o comportamento real do sistema diante do usuário real. O agente acelera a execução. Não acelera o julgamento. Quanto mais código a IA gera, mais review, mais teste de aceitação, mais validação de comportamento — exatamente o trabalho do QA.

Por que esse padrão se repete

Toda onda repete a mesma confusão: misturar executor com responsável.

• O dev pode rodar teste — não substitui quem pensa o teste.
• O time pode ser responsável — não substitui quem tem profundidade.
• A esteira pode validar — não substitui quem decide o critério.
• A IA pode escrever — não substitui quem julga.

Tenha isso em mente: cada ferramenta nova transforma o trabalho do QA. Nenhuma elimina a função, porque a função não é apertar botão de “rodar teste”. É cuidar da relação entre o que foi combinado e o que foi entregue. Esse cuidado é humano por natureza.

No fim do dia

O profissional de QA que insiste em ser “executor de caso de teste manual” sente cada onda como uma ameaça real — e, sinceramente, é mesmo. Mas o QA que entende o próprio papel como dono da estratégia de qualidade, e que adota cada nova ferramenta como alavanca, sai mais forte de cada ciclo.

O problema nunca foi as pessoas. Foi a estratégia mal desenhada — confundir cargo com tarefa, confundir ferramenta com responsável.

Por fim, se você é QA e está se perguntando se vale continuar na área: vale. A próxima onda vai chegar — alguém vai anunciar de novo o fim do QA — e quem estiver junto da ferramenta, e não contra ela, vai sair de novo do outro lado mais essencial do que entrou.

Você já viu quantas “mortes” do QA na sua carreira?