O Problema da Confiança no Fracasso dos Testes de IA

Na Pesquisa de Desenvolvedores de 2025 do Stack Overflow1, 84% dos desenvolvedores afirmaram usar ou planejar usar ferramentas de IA em seu fluxo de trabalho, um aumento em relação aos 76% do ano anterior. Na mesma pesquisa, 46% disseram desconfiar ativamente da precisão dos resultados dessas ferramentas, contra 33% que confiam nelas.  

A adoção aumentou, enquanto a confiança diminuiu, tudo ao mesmo tempo. 

Isso não é fase. É o que acontece quando uma grande população de pessoas qualificadas usa uma ferramenta por tempo suficiente para calibrá-la. 

O paradoxo da confiança é uma resposta racional. 

DORA do Google para 20252 O relatório constatou a mesma divisão sob uma perspectiva diferente: mais de 80% dos desenvolvedores relataram que a IA aumentou sua produtividade, enquanto 30% relataram pouca ou nenhuma confiança no código gerado por ela. Útil e não confiável não são mutuamente exclusivos, e os desenvolvedores atribuem valor a ambos. 

As pessoas mais experientes são as mais céticas. Os dados do Stack Overflow mostram que os desenvolvedores com mais experiência relatam as menores taxas de alta confiança e as maiores taxas de alta desconfiança. Vale a pena refletir sobre isso, porque essas são as pessoas que avaliarão qualquer recurso de IA que você apresentar a uma organização de engenharia, e elas não serão convencidas por uma resposta que soe confiante. 

A análise de falhas é onde o ceticismo barato se torna caro. 

Muitas das aplicações de IA no fluxo de trabalho de um desenvolvedor têm baixo risco de serem verificadas. Se uma sugestão de código estiver errada, você descobre rapidamente, e o custo é de apenas alguns minutos. 

A triagem de falhas em testes não funciona dessa maneira. Quando algo falha, a questão não é apenas o que quebrou, mas em qual camada falhou — o aplicativo, o script de automação, o dispositivo ou o ambiente. Essa resposta determina quem ficará responsável pelo problema. Se você errar, não terá perdido apenas alguns minutos; terá encaminhado o defeito para a equipe errada, gasto um ciclo inteiro com ele e devolvido a falha para onde começou, com um dia já perdido. 

Os sinais já estão aí. Tudo o que é necessário para explicar a falha é capturado durante a execução — script, registros do dispositivo, registros do servidor, tudo o que o aplicativo registrou ao ser interrompido. As evidências não estão faltando; a análise, sim. É por isso que ainda cabe a alguém abrir os arquivos, decidir quais centenas de linhas são relevantes e colá-las no sistema. 

Se o software for realizar essa análise, o padrão exigido é mais elevado do que "geralmente correto". Deve ser algo em que você possa confiar. A questão não é se o modelo é preciso, mas sim se o sistema consegue demonstrar seu funcionamento de forma suficientemente clara para que você possa tomar suas próprias decisões. 

Um índice de confiança deve medir a evidência. 

A maioria das métricas de confiança em produtos de IA mede a coisa errada: o quão certo o modelo parece. Os modelos de linguagem são muito bons em parecer certos. Esse número indica o quão fluente é a resposta, não se ela está correta. 

Uma pontuação melhor mede a evidência. Ela deve aumentar quando várias fontes distintas apontam para a mesma falha. Deve aumentar quando há uma mensagem de erro real em vez de um palpite baseado em um tempo limite, e quando é possível acompanhar a sequência desde o que desencadeou o problema até o que finalmente o causou. 

E deveria diminuir quando uma fonte de registro estivesse ausente, quando apenas uma fonte corroborasse a conclusão ou quando outra explicação não pudesse ser descartada. 

 

A confiança como medida de corroboração — o que aumenta a pontuação, o que a diminui e como as bandas são interpretadas. 

O indicador é se o número alguma vez diminui. 

Um sistema de pontuação que nunca reporta baixa confiança é mera formalidade. Se todas as análises retornarem um resultado alto, a pontuação não está medindo nada. Uma pontuação real cai quando os dados são escassos: quando uma fonte de log está faltando, isso é indicado em vez de preencher a lacuna. 

Ninguém quer demonstrar a tela em que a ferramenta diz que não tem certeza. Mas é nessa tela que os engenheiros acreditam, porque corresponde à forma como as investigações realmente acontecem. Uma ferramenta que admite quando não sabe está mostrando que tem uma limitação, e você pode confiar nela dentro dessa limitação. 

Três perguntas que vale a pena fazer a qualquer fornecedor, inclusive a nós. 

Atualmente, todos os fornecedores de automação de testes afirmam que sua IA explica as falhas. A afirmação em si não é um diferencial; o que a sustenta, sim, são as evidências. Três questões os distinguem rapidamente: 

• “Se a análise estiver errada, como vou descobrir?” Se a única resposta for "você mesmo investigaria isso", a ferramenta não salvou a investigação, apenas adicionou uma etapa a ela. 

• “Mostre-me um resultado com baixo nível de confiança.” Não se trata de uma seleção criteriosa. Se nada no ambiente de demonstração obtiver uma pontuação baixa, pergunte o que seria necessário para produzir uma. 

• “Qual foi, de fato, o resultado da análise?” Este é o ponto mais importante, e é por isso que colar logs em um modelo de uso geral tem suas limitações. Esse modelo só vê o que alguém conseguiu exportar. Uma análise é limitada por suas entradas, e você deve saber quais foram elas. 

O turno 

A questão relevante sobre IA em testes mudou, assim como a função que lhe é atribuída. O objetivo nunca foi excluir o engenheiro da decisão. Nomear a camada é uma questão de julgamento com consequências reais, e o julgamento é a parte que deve permanecer humana. 

O que não deve permanecer sob responsabilidade humana é a leitura. Abrir os documentos, descobrir quais centenas de linhas são relevantes, reconstruir a sequência — esse é o trabalho que o software deveria absorver, para que a pessoa que toma a decisão comece com as evidências já reunidas, em vez de gastar uma tarde inteira reunindo-as. 

É por isso que uma pontuação que diminui é importante. Um nível de confiança que cai quando uma fonte de log está ausente significa que o sistema está devolvendo a decisão: desta vez, precisamos da sua intervenção. Uma ferramenta que nunca faz isso não está mantendo um humano no processo. Está torcendo para que ninguém verifique. 

Ninguém confia em um modelo apenas porque ele foi descrito como confiável. As pessoas confiam porque lhes foi mostrado o suficiente para que pudessem julgar por si mesmas.  

Onde isso se conecta com o que construímos. Análise de causa raiz com inteligência artificial em Digital.ai O Testing analisa as falhas de teste do Appium em iOS e Android a partir dos artefatos da execução e retorna uma causa provável, uma pontuação de confiança baseada na concordância das evidências e a linha de log ou etapa específica responsável pela falha. O nível de confiança diminui quando os dados são escassos. Isso é intencional. 

Fontes e referências 

1StackOverflow, Pesquisa de desenvolvedores de 2025 — seção de IA — 84% usam ou planejam usar ferramentas de IA, um aumento em relação aos 76% anteriores; 46% desconfiam da precisão dos resultados da IA, contra 33% que confiam; a desconfiança é maior entre os desenvolvedores mais experientes (20.7% "desconfiam muito"). 

2Google Cloud / DORA, Estado do Desenvolvimento de Software Assistido por IA em 2025 — Mais de 80% relatam que a IA aumentou sua produtividade; 30% relatam pouca ou nenhuma confiança no código gerado por IA.