A IA vai substituir profissionais de QA?5 insights do TDC Floripa 2026

1. A IA pode rodar milhares de testes. Mas alguém precisa definir o que é “certo”

Na palestra sobre testes visuais de ponta a ponta (E2E) com YOLO, OpenCV e EasyOCR, vimos uma aplicação prática de IA rodando mais de 2 mil cenários de teste. É muita escala e, sem dúvida, um ganho enorme para quem trabalha com produtos complexos.

Mas o ponto mais interessante não foi apenas a quantidade de testes. Foi entender que testar visualmente é diferente de verificar se um elemento existe no código.

Um botão pode estar presente no HTML, ser encontrado pelo Playwright e, ainda assim, estar invisível para quem usa o produto. Um texto pode ter sido renderizado, mas aparecer desalinhado, cortado ou impossível de ler. Um comprovante pode estar tecnicamente correto e exibir uma marca errada, o que é um problema enorme para a confiança de quem recebe aquela informação.

É aí que a IA faz diferença: ela ajuda a enxergar mais. Comparar imagens, detectar objetos, identificar falhas de layout e ampliar a cobertura visual são usos muito valiosos.

Só que ela não decide sozinha se aquela diferença importa. Não é a IA que entende o impacto de um botão invisível em uma jornada de compra, de uma informação truncada em um dashboard ou de uma identidade visual errada em um documento bancário.

A ferramenta acelera a validação. O QA continua sendo responsável por definir o que precisa ser validado, qual é o comportamento esperado e quando um desvio realmente representa um risco.

2. Documentação com IA não deveria ser lembrada só quando vira problema

Quem nunca descobriu tarde demais que uma documentação estava desatualizada?

Esse foi o ponto de partida da palestra sobre governança automatizada de documentação com IA. E é uma dor bem real. Muitas vezes, a documentação existe, mas ninguém sabe se ela ainda acompanha o produto. Ela fica parada em uma ferramenta, em uma página ou em uma planilha, até que uma mudança de requisito, um retrabalho ou uma falha no teste revela que algo ficou para trás.

A proposta apresentada foi transformar documentação em sinal de qualidade.

Em vez de esperar alguém abrir cada card, cada página e cada histórico manualmente, a IA pode ajudar a identificar pendências, priorizar documentos que merecem atenção e avisar quando um risco começa a aparecer na sprint. Isso muda bastante a conversa porque tira a documentação do lugar de obrigação burocrática e a transforma em parte da operação.

Mas existe um cuidado importante: governança não pode virar fiscalização vazia.

Não adianta criar uma régua rígida e igual para todos os times se cada produto tem um ritmo, uma complexidade e uma necessidade diferente. O valor está justamente em adaptar os sinais ao contexto e usar as informações para apoiar decisões, não para criar mais uma camada de pressão.

Para qualidade, esse é um aprendizado valioso. Um requisito mal descrito, um card sem responsável ou uma documentação desatualizada não são detalhes pequenos. Eles podem virar bugs, atrasos, retrabalho e ruído entre as pessoas do time.

3. BDD e SDD: a IA é muito boa em executar, mas não deveria precisar adivinhar

A palestra sobre desenvolvimento orientado por especificação (SDD) e desenvolvimento orientado por comportamento (BDD) trouxe uma ideia que parece simples, mas fica ainda mais importante quando colocamos IA no processo: quanto mais ambíguo é o pedido, maior é a chance de o resultado fugir do que realmente era esperado.

Pedir para uma IA criar uma funcionalidade sem explicar contexto, regras e limites é parecido com entregar uma tarefa de duas linhas para uma pessoa e esperar que ela adivinhe todas as decisões de negócio envolvidas.

“Criar uma tela de faturas” parece uma demanda objetiva. Até surgir a pergunta: uma fatura parcelada pode ser excluída inteira ou apenas em parte? O valor informado é total ou mensal? O que acontece com as parcelas já pagas? Quem define isso?

É aqui que BDD e SDD ajudam.

BDD não é simplesmente escrever “dado, quando, então” ou criar um teste automatizado. É conversar sobre comportamento antes de construir. É deixar claro o que precisa acontecer, em quais situações e qual resultado faz sentido para o negócio.

O SDD amplia esse olhar ao reunir regras de negócio, contexto técnico, contratos e cenários em uma especificação mais completa. Assim, quem for desenvolver, testar ou usar uma ferramenta de IA parte da mesma base.

No fim, não se trata de documentar mais por documentar. Trata-se de evitar que pessoas e máquinas trabalhem em cima de suposições diferentes.

A IA pode ser uma ótima parceira para transformar conversas em cenários, organizar informações e sugerir casos que o time talvez não tenha considerado. Mas ela funciona melhor quando recebe contexto. E contexto bom continua vindo de quem entende do produto, das pessoas usuárias e do problema que precisa ser resolvido.

4. Sim, uma IA pode testar outra IA. Mas isso ainda não exclui a supervisão humana.

Um dos assuntos mais legais da trilha foi justamente o uso de IA para testar produtos que também usam IA.

A palestra sobre Robot Framework e Gemini mostrou um cenário cada vez mais comum: como validar dashboards, chats e conteúdos gerados por modelos que não entregam exatamente a mesma resposta toda vez?

Em produtos tradicionais, muitas vezes conseguimos definir uma entrada e esperar uma saída específica. Em produtos com IA, isso nem sempre funciona. Uma resposta pode mudar de formato, um gráfico pode ser apresentado de outra forma e um chatbot pode se comportar de maneira diferente conforme o contexto da conversa.

Nesses casos, usar uma segunda IA como avaliadora pode fazer sentido. Ela pode analisar se uma resposta está coerente, se um gráfico foi renderizado de forma legível ou se uma conversa manteve o contexto esperado.

Mas isso não significa pedir para a IA decidir sozinha se algo está bom ou ruim.

Para que esse tipo de avaliação funcione, é preciso definir critérios claros. Quem a IA deve representar? Um QA? Uma pessoa de negócio? Qual resposta é aceitável? O que deve ser tratado como falha? Qual formato de saída facilita a análise? Quais dados podem ou não entrar no teste?

Essa discussão também apareceu no painel “LLM as a Judge”, no qual um grande modelo de linguagem (LLM) atua como avaliador. A IA pode ser uma camada extra de validação, ajudar a revisar grandes volumes de informação e apoiar decisões. Só que ela precisa de uma régua bem construída.

A IA não cria qualidade do nada. Ela trabalha em cima do contexto, dos critérios e das restrições que alguém definiu.

Por isso, o papel do QA não diminui. Ele muda. Em vez de só executar validações, o profissional passa a desenhar como essas validações devem funcionar, quais riscos precisam ser observados e em quais momentos a decisão precisa continuar humana.

5. Testes de performance e engenharia do caos: um sistema não é confiável só porque funciona em um dia tranquilo

A palestra sobre caos e performance trouxe uma metáfora muito boa: testar uma aplicação apenas em condições ideais é como testar um carro só em uma estrada lisa e reta.

Tudo parece ótimo até aparecer uma falha de rede, um pico de acessos, um serviço indisponível ou uma dependência mais lenta do que deveria.

Testes de performance ajudam a entender como a aplicação se comporta sob carga. Já a engenharia do caos cria falhas controladas para observar se o sistema consegue se recuperar. Quando essas duas práticas se encontram, o time passa a enxergar problemas que talvez não apareceriam em testes isolados.

No estudo de caso apresentado, a combinação de performance e caos revelou falhas em processos de recuperação, configurações de limite de requisição e pontos que poderiam gerar uma cascata de problemas em um cenário adverso.

Esse tipo de teste não é sobre “derrubar ambiente por diversão”. É sobre criar situações seguras para aprender antes que o cliente seja impactado.

Também é uma forma de conversar sobre qualidade com uma linguagem que o negócio entende. Não basta dizer que encontramos dez bugs ou que uma API demorou alguns segundos a mais. É preciso mostrar quanto custa um incidente, quanto tempo de retrabalho ele gera, qual impacto pode causar para quem usa o produto e quanto uma ação preventiva pode economizar.

Qualidade tem valor técnico, claro. Mas também tem valor financeiro, operacional e reputacional.

Então, a IA vai acabar com o QA?

Provavelmente não. Mas o modelo de QA que só entra no final para “dar ok” em uma entrega já não responde a tudo o que os produtos precisam hoje.

A área está ficando mais ampla. Estamos falando mais sobre arquitetura, comportamento, dados, observabilidade, segurança, performance, experiência e negócio. A IA entra nessa equação para ajudar a ganhar escala, reduzir tarefas repetitivas e abrir espaço para discussões mais estratégicas.

O que não muda é a necessidade de ter pessoas capazes de fazer boas perguntas.

Alguém precisa entender se uma resposta faz sentido. Alguém precisa perceber quando uma automação está validando a coisa errada. Alguém precisa ligar um problema técnico ao impacto que ele pode causar para o negócio e para quem usa o produto.

Na Wisedot, a gente acredita que aprender QA não é decorar ferramenta ou correr atrás da próxima tendência. É construir repertório para entender problemas, usar tecnologia com critério e participar de decisões que realmente melhoram produtos.

A IA pode acelerar muita coisa. Mas é a qualidade que ajuda a garantir que estamos acelerando na direção certa.