Agentes de IA em QA: ganhos, riscos e julgamento humano

Agentes de IA podem ajudar um time de QA a explorar mais cenários, preparar testes e investigar falhas. Eu manteria QAs experientes responsáveis por interpretar as evidências e avaliar o risco de um release. Dar mais tarefas a um sistema também aumenta o volume de resultados que o time precisa validar.

Aqui, chamo de agente um sistema capaz de perseguir um objetivo de teste em várias etapas: escolher ações, usar ferramentas, observar resultados e ajustar o próximo passo. Um modelo que redige testes e um bot que explora um jogo são sistemas diferentes. A evidência sobre um deles não estabelece o que o outro consegue fazer.

O World Quality Report 2025-26 encontrou 89% das organizações respondentes com pilotos ou uso de IA generativa em engenharia de qualidade. Apenas 15% haviam implantado esse uso em toda a empresa. São respostas das organizações daquela pesquisa, e não um censo de todos os times de QA.

Para mim, essa diferença aponta para o trabalho depois de uma demonstração bem-sucedida: integrar ferramentas, definir o que torna um teste útil, proteger dados e manter a manutenção viável. Uma execução convincente em uma build precisa virar um processo repetível.

A pergunta útil é onde o agente pode remover esforço repetitivo e deixar evidências melhores para o time. Eu começaria com uma tarefa delimitada, uma referência de comparação e uma definição clara de falha. Assim, os benefícios e o trabalho restante ficam visíveis.

O TestGen-LLM, da Meta, traz um exemplo concreto. Os engenheiros relataram que 75% dos testes gerados compilaram, 57% passaram de forma confiável e 25% aumentaram a cobertura em uma avaliação de Instagram Reels e Stories. Em eventos separados de testes, os engenheiros aceitaram 73% das recomendações para produção.

Esses percentuais descrevem etapas e avaliações diferentes. A aceitação de 73% se refere às recomendações depois da filtragem. Os testes precisavam compilar, executar de forma confiável e ampliar a cobertura antes da revisão dos engenheiros. É um estudo industrial escrito pela própria empresa, sobre uma tarefa delimitada.

Eu aproveitaria esse princípio: gerar candidatos com baixo esforço, rejeitar automaticamente os inviáveis e concentrar a atenção humana nos que passaram. A cobertura ajuda nessa filtragem, mas ainda exige julgamento para decidir se o teste verifica algo relevante.

Games também têm exemplos além dos modelos de linguagem. Uma pesquisa da EA SEED, de 2023, descreve agentes treinados por aprendizado por reforço e imitação para navegar em jogos e descobrir falhas. Essas técnicas diferem de um agente com LLM escrevendo testes, e seus resultados não se transferem automaticamente para outro jogo.

Em um time mobile, eu consideraria começar por variações de cenários, organização de evidências e exploração de caminhos repetíveis. Cada saída precisa de uma checagem: o cenário representa um risco para o jogador, a falha é reproduzível e o relatório tem evidência suficiente para alguém agir?

A parte mais difícil de um teste muitas vezes é decidir o que deveria acontecer. Essa referência é chamada de oráculo de teste. Um agente que lê a implementação pode confundir o comportamento atual com o comportamento esperado e escrever uma verificação que preserva um bug.

Um preprint que estudou 24 repositórios Java encontrou oráculos gerados por LLMs que capturavam principalmente o comportamento real do programa, dificultando a detecção de bugs. É uma conclusão sobre aqueles métodos e repositórios. Para mim, reforça a necessidade de revisar os resultados esperados.

Imagine um jogo mobile fictício: a compra funciona, mas o jogador recebe a recompensa duas vezes. Um teste gerado a partir do código existente pode verificar que duas recompensas aparecem. O teste passa enquanto protege o defeito. Um QA que consulta a regra da compra tem uma referência independente para rejeitar esse resultado.

Na pesquisa de desenvolvedores do Stack Overflow de 2025, 46% desconfiavam da precisão das saídas de IA e 3% confiavam muito. É uma pesquisa de desenvolvedores, sem recorte específico de QA de games. Ela ajuda a entender por que uma resposta plausível precisa ser verificada.

Eu revisaria mudanças nas verificações dos testes com o mesmo cuidado dedicado ao código de produção. Um teste corrigido que deixou de conferir a quantidade da recompensa precisa de uma explicação. O mesmo vale para cenários ignorados, tentativas extras sem justificativa e falhas reclassificadas como esperadas.

Também há custos operacionais. Eu reservaria orçamento para execução, revisão e manutenção, além de definir quais builds, logs ou dados de jogadores podem chegar a um serviço externo. O tempo economizado na geração pode perder valor se o time gastar mais para resolver resultados pouco confiáveis.

Um agente pode percorrer uma fase e coletar sinais. Avaliar se a dificuldade combina com o público envolve designers, feedback de jogadores e julgamento de QA. As fontes revisadas aqui não demonstram que um agente valide diversão ou game feel de forma independente. Esse é um limite da evidência disponível, sem concluir que essas capacidades nunca vão melhorar.

Eu pediria ao QA que examinasse o que os números deixam de fora: se o feedback faz sentido depois de uma jogada malsucedida, se o toque parece responsivo, se o tutorial explica a próxima ação e se uma interrupção deixa o jogador em um estado recuperável.

O desempenho em aparelhos reais também pode ser medido por automação. É preciso executar no hardware relevante e analisar as medições. Uma partida simulada, sozinha, não informa sobre regularidade dos frames, aquecimento, pressão de memória ou uma falha específica de determinado celular.

O Google Play define um limite de mau comportamento quando ao menos 8% dos usuários ativos diários de um único modelo de aparelho sofrem um crash percebido pelo usuário. Ultrapassar esse limite pode reduzir a descoberta do app nos aparelhos afetados e gerar um aviso na loja. O limite geral, considerando todos os modelos, é 1,09%.

Por isso, eu escolheria aparelhos a partir do público e dos riscos observados, combinando execuções automatizadas com sessões humanas direcionadas. Incluiria atualizações, interrupções de rede, ida para segundo plano e recuperação de compras quando relevantes. Registrar build, aparelho, condições e evidências permite que outra pessoa reproduza o resultado.

QAs experientes conectam um sintoma técnico ao impacto no jogador e ajudam a decidir o que merece atenção primeiro. Essa responsabilidade fica especialmente útil quando agentes aumentam o volume de achados.

Na Kakunyn, adotamos uma estratégia AI first em vários aspectos: consideramos desde o início onde a IA pode tornar um fluxo mais eficiente. Nossa experiência também mostra a necessidade de manter pessoas experientes na validação. Vejo a IA como uma alavanca para ampliar a capacidade do time e encurtar ciclos de feedback.

Já conseguimos ganhos de até 100% na velocidade de etapas específicas de pipelines com IA. Isso descreve nossa experiência em situações determinadas, sem servir como benchmark geral. Dobrar a capacidade de uma etapa não significa dobrar todo o pipeline ou cortar cada custo pela metade. O objetivo é abrir espaço para testes úteis e reduzir retrabalho e desperdício evitáveis.

Medir faz diferença. No experimento da METR com ferramentas do início de 2025, 16 desenvolvedores experientes demoraram 19% mais com IA, embora acreditassem, depois, ter ficado 20% mais rápidos. Em fevereiro de 2026, a METR disse que ferramentas mais novas provavelmente traziam ganhos maiores, mas vieses de seleção tornavam os novos dados pouco confiáveis. Eu mediria o fluxo completo, incluindo revisão.

Também usamos nossa própria ferramenta em diversas etapas do fluxo de QA, com validação dos resultados por um QA experiente. Como essa ferramenta apoia o processo merece um post separado.

Nossos serviços de QA para games mobile incluem testes funcionais, compatibilidade e desempenho. Se você está decidindo onde encaixar agentes nos testes, eu começaria mapeando o trabalho repetitivo, os riscos para o jogador e as decisões que precisam de uma revisão responsável. Isso dá um escopo útil à automação e mantém o time de QA focado em qualidade.

Se quiser conversar sobre esse equilíbrio no seu jogo, fale conosco pela página de contato do site.

Meu checklist inicial seria: