Na era da IA, o QA não testa só software. Ele desenha confiança
A IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → escreve a função, gera os testes, executa a suíte, analisa a falha e corrige o código. Em alguns fluxos, ainda revisa o pull request antes de entregá-lo a uma pessoa.
Diante disso, a pergunta é inevitável: se a IA consegue fazer todas essas tarefas, ainda precisamos de QA?
Eu acredito que sim, embora talvez não precisemos mais daquele QA definido apenas como a pessoa que recebe uma feature pronta, executa alguns casos de teste e decide se ela pode seguir para produção.
Esse papel já estava mudando antes da IA. Agora ficou impossível ignorar a transformação. Quanto mais automatizamos a produção e a verificação do software, mais importante se torna uma pergunta anterior aos próprios testes:
Quem decidiu o que significa confiar nesse resultado?
A automação não eliminou a necessidade de confiança
O relatório DORA de 2025 constatou que 90% dos profissionais de tecnologia pesquisados já usavam IA. Mais de 80% percebiam ganhos de produtividade, e 59% relatavam impacto positivo na qualidade do código.
Os números sobre confiança, porém, contam outra parte da história. Apenas 24% disseram confiar muito ou bastante nas ferramentas de IA, enquanto 30% afirmaram confiar pouco ou nada.
Estamos usando mais, produzindo mais rápido e, ainda assim, não confiamos completamente no resultado.
Isso está longe de indicar que qualidade perdeu importância. Na prática, mostra o contrário. Quando a velocidade de produção aumenta, precisamos responder com a mesma rapidez:
- O comportamento está correto?
- Correto em relação a qual regra?
- O que foi realmente validado?
- Quais riscos ficaram fora da análise?
- Há evidência suficiente para liberar a mudança?
É nesse ponto que o trabalho de QA fica mais interessante.
O problema de a IA corrigir a própria prova
Imagine um agente recebendo a seguinte regra:
Clientes com assinatura Premium têm frete grátis em compras acima de R$ 100.
O agente implementa a função e depois gera os testes. Há, porém, um erro no código: o frete grátis é aplicado a qualquer cliente que compre mais de R$ 100, mesmo sem uma assinatura Premium.
O perigo está no passo seguinte. O mesmo contexto que levou o modelo a interpretar a regra incorretamente pode levá-lo a criar testes que confirmem essa interpretação.
O código passa. Os testes também. O CI fica verde, mas a regra de negócio continua errada.
Um estudo publicado em 2026 sobre fluxos de geração de código e testes por LLMs chamou a atenção para esse risco. Erros presentes no código podem se propagar para os testes gerados em seguida, produzindo uma implementação e uma suíte coerentes entre si, mas incorretas em relação ao requisito original.
Isso expõe uma fragilidade no modelo mental de que basta pedir à IA para gerar e, depois, testar o próprio trabalho.
Um teste só funciona como evidência quando existe algum grau de independência entre o que está sendo validado e o mecanismo usado para decidir o que é correto. Se a mesma interpretação equivocada produz a implementação e o teste, o resultado é concordância, não necessariamente qualidade.
Testes passando não significam software correto
O problema não nasceu com a IA. Uma suíte sempre pôde passar enquanto bugs permaneciam escondidos. Cobertura de 100% nunca foi sinônimo de ausência de defeitos.
Um teste pode executar uma linha sem verificar a regra certa. Pode afirmar o resultado errado, ignorar limites importantes ou cobrir apenas o caminho feliz, deixando de fora o que acontece quando o mundo real interfere.
A IA acrescenta velocidade e escala a esse problema. Ela produz testes rapidamente, e quantidade se parece muito com segurança quando olhamos para um pull request: dez arquivos de teste, centenas de assertions e um pipeline verde passam uma forte impressão de cobertura.
Essa impressão pode enganar. Um estudo da Microsoft Research publicado em 2025 encontrou test smells em testes gerados por LLMs em até 37% dos casos analisados. Outra pesquisa recente sobre geração automática de testes mostrou que os modelos podem atingir ótima cobertura e, mesmo assim, omitir de forma sistemática casos de robustez envolvendo valores especiais.
Isso não significa que a IA seja incapaz de produzir bons testes. Ela pode produzi-los. O problema é presumir que gerar mais testes resolve, por si só, a questão mais difícil: saber se estamos testando as coisas certas.
De executor de testes a designer de confiança
É aí que vejo uma oportunidade relevante para QA.
Em vez de disputar com a IA quem consegue escrever mais casos de teste, o profissional de qualidade pode trabalhar em outro nível. A pergunta deixa de ser “qual teste preciso executar?” e passa a ser:
Que evidências precisamos reunir para confiar que este comportamento está correto?
Não se trata apenas de trocar as palavras. A mudança coloca QA na posição de quem ajuda a desenhar o sistema de confiança do produto.
Esse trabalho inclui decidir:
- Quais propriedades do sistema devem permanecer invariáveis;
- Quais comportamentos são críticos para o negócio;
- Que tipos de erro precisam bloquear o pipeline;
- Quais cenários exigem revisão humana;
- Quais sinais devem ser observados em produção;
- Que métricas indicam degradação;
- Como separar uma falha do produto de uma falha do agente;
- Quanto risco o time aceita em cada categoria de mudança.
A automação continua fazendo parte do processo. A diferença é que ela passa a operar dentro de um modelo de confiança projetado de forma consciente.
O QA como designer de oráculos
Em testes, chamamos de test oracle↳Oracle22 conteúdosOracle lança Java 26 para aumentar produtividade de desenvolvedoresDev (Back & Front) · mar 2026Oracle oferece o primeiro cluster de computação em nuvem em escala ZettaDevSecOps · jan 2025Oracle abre inscrições para o ONE, programa gratuito de formação em tecnologia e inteligência artificialData · dez 2024Ver tudo em Data → o mecanismo usado para determinar se o resultado observado está correto.
A definição parece simples até surgirem perguntas como:
- Qual é o valor certo?
- Qual comportamento ainda é aceitável?
- Uma resposta diferente está errada ou apenas chegou ao mesmo objetivo por outro caminho?
- Quem decide isso?
Em software determinístico, muitas vezes uma assertion simples resolve:
entrada: 2 + 2 resultado esperado: 4
Agora pense em um agente que precisa:
- Abrir uma aplicação;
- Localizar um cadastro;
- Alterar um campo;
- Salvar;
- Confirmar que a mudança persistiu.
Há várias maneiras válidas de executar esse fluxo. O agente pode usar o teclado, clicar em outra sequência de elementos, esperar uma tela carregar ou voltar uma etapa antes de tentar novamente.
Se o teste exigir uma sequência fixa, uma execução perfeitamente válida pode ser marcada como falha apenas porque seguiu outro caminho.
Em maio de 2026, o GitHub publicou uma discussão sobre esse desafio na validação de comportamento agentic. A proposta foi construir uma Trust Layer que verifica os estados essenciais para o sucesso, sem exigir que toda execução percorra exatamente a mesma sequência.
A ideia muda o foco da validação. Em vez de perguntar se o sistema repetiu cada passo esperado, passamos a definir quais condições precisam ser verdadeiras para considerar que o objetivo foi alcançado.
Esse é um problema de desenho de confiança, e QA tem muito a contribuir nessa discussão.
Qualidade em sistemas não determinísticos
Software tradicional já apresenta comportamentos não determinísticos. Rede, concorrência, filas, sistemas distribuídos e integrações externas sempre introduziram variação. Os agentes ampliam essa característica, pois duas execuções corretas podem seguir caminhos diferentes e produzir resultados que não são idênticos.
Por isso, o trabalho de qualidade tende a lidar cada vez mais com:
- Propriedades, em vez de sequências rígidas;
- Tolerâncias adequadas ao contexto, em vez de valores absolutos para tudo;
- Invariantes;
- Avaliação semântica;
- Traces e observabilidade↳Observabilidade11 conteúdosObservabilidade para APIs: os desafios e benefícios dessa abordagemDev (Back & Front) · jan 2025Falhas em Observabilidade afetam os Apps e a Segurança das OrganizaçõesDev (Back & Front) · nov 2023ADK Java 1.0: O Google quer que você pare de gambiarra Python no seu backendMarketing Tech · abr 2026Ver tudo em DevSecOps →;
- Confiança estatística;
- Comparação de resultados;
- Análise de risco.
O foco sai de “gravei estes cinco cliques” e vai para “quais estados precisam ser alcançados e quais estados jamais podem ocorrer?”.
Esse trabalho exige compreender intenção, contexto, impacto e risco. A IA pode ajudar a gerar os testes, mas alguém ainda precisa definir o que eles estão tentando provar.
Um stack de confiança para times que usam IA
Se eu estivesse desenhando o processo de qualidade de um time fortemente assistido por IA, não colocaria toda a confiança em uma única camada. Usaria uma combinação de mecanismos.
Testes tradicionais
Testes unitários, de integração, de contrato e end-to-end continuam relevantes. A IA pode acelerar sua criação e ajudar na manutenção, mas esses testes ainda precisam estar ligados a comportamentos e riscos reais.
Análise estática
Tipos, linters, scanners de segurança, análise de dependências e políticas automatizadas conseguem rejeitar problemas conhecidos antes da execução. São controles baratos quando comparados ao custo de encontrar o mesmo defeito em produção.
Mutation testing
O mutation testing ajuda a responder se a suíte realmente percebe mudanças indevidas. Se alterações artificiais no código não fazem os testes falharem, talvez a suíte esteja passando sem proteger o comportamento que importa.
Observabilidade
Logs, métricas, traces e eventos mostram o que aconteceu quando o software encontrou usuários, dados e condições reais. Eles não substituem testes, mas revelam falhas nas premissas usadas durante a validação.
Evals para comportamento de IA
Quando o produto incorpora modelos, precisamos avaliar qualidade, segurança, consistência e comportamento em conjuntos representativos de cenários. Uma demonstração bem-sucedida não diz como o sistema se comportará diante da variedade encontrada em produção.
Testes adversariais
Além de verificar se o usuário consegue concluir uma tarefa, precisamos procurar formas de quebrar ou abusar do sistema. Isso inclui entradas inesperadas, informações contraditórias e tentativas de induzir o agente a agir fora do escopo.
Gates e escalonamento
Nem toda decisão precisa ser binária. Algumas mudanças podem seguir automaticamente, outras precisam de revisão humana e certas condições devem bloquear completamente a entrega. O nível de controle deve acompanhar o risco da mudança.
A confiança funciona melhor quando é construída em camadas e nenhuma delas precisa fingir que consegue provar tudo sozinha.
O que eu esperaria de QA em um time que usa agentes
Se eu estivesse contratando ou desenvolvendo um profissional de qualidade para um time que usa IA intensamente, o número de scripts escritos por dia não seria minha principal medida.
Eu me interessaria mais pela capacidade de investigar perguntas como estas:
- Onde o sistema pode falhar sem que ninguém perceba?
- Como sabemos que o teste detectaria uma implementação incorreta?
- Quem define o oracle?
- Existe independência suficiente entre quem gera o código e quem valida o comportamento?
- Quais cenários têm maior impacto financeiro, regulatório ou reputacional?
- Que evidência permite uma liberação automática?
- Quando uma pessoa precisa entrar no processo?
- Se o comportamento do agente variar entre execuções, o que continua sendo obrigatório?
- Como descobriremos, em produção, que nossa validação estava errada?
Essas perguntas se aproximam mais da engenharia de risco do que da execução manual de testes. Talvez essa seja justamente a evolução do papel.
O QA não morreu porque testar nunca foi o objetivo final
Testar sempre foi um meio. O objetivo é construir confiança suficiente para mudar uma linha, fazer merge, publicar uma versão, migrar dados ou permitir que um agente execute uma ação sozinho.
Durante muito tempo, os casos de teste executados por pessoas ou pipelines foram o principal instrumento para produzir essa confiança. Hoje também contamos com tipos, análise estática, geração automática, agentes, observabilidade, evals, mutation testing e um conjunto crescente de verificações automatizadas.
Isso não diminui a importância da qualidade. Apenas muda o ponto em que o profissional gera mais valor.
O QA que tentar competir com a IA pelo volume de testes escritos provavelmente perderá. Já o profissional capaz de definir o que precisa ser provado, quais evidências importam e como o sistema deve reagir quando essas evidências forem insuficientes pode se tornar ainda mais necessário.
Talvez o próximo grande papel de QA não seja executar testes, mas atuar como designer de confiança.
Quanto mais as máquinas produzirem e validarem software por conta própria, mais precisaremos de alguém responsável por responder à pergunta que vem antes do deploy:
O que precisa ser verdade para deixarmos esta mudança entrar em produção?
John Calistro é mentor de empregabilidade em tecnologia e autor de conteúdos práticos sobre portfólio que contrata, IA para estudar e revisar código, entrevistas e posicionamento no LinkedIn. Ajuda iniciantes e migrantes a sair da estagnação e conquistar o 1º emprego com projetos que mostram impacto real.
