Desenvolvimento com agentes de IA (ADLC): onde o GUI Test Studio se encaixa
Agentes de programação com IA planejam, escrevem, testam, corrigem e entregam, com pessoas no comando: o ciclo de vida do desenvolvimento agêntico, ou ADLC.Onde os testes end-to-end entram nesse ciclo, e como o GUI Test Studio dá a um agente um teste que ele pode criar a partir de um prompt, alterar no lugar, executar sem janela e em paralelo em qualquer pipeline de CI/CD, ler como um veredito em palavras simples e registrar no Jira, até o ciclo se fechar.
9 min de leituraPela equipe do GUI Test Studio
O que é o ciclo de vida de desenvolvimento com agentes (ADLC)
Durante décadas, o software foi construído segundo o ciclo de vida de desenvolvimento de software, o SDLC: uma equipe planeja, um desenvolvedor programa, um testador testa, alguém corrige, alguém entrega, e o ciclo recomeça.Os agentes de programação com IA não substituíram esse ciclo.Eles assumiram o seu ciclo interno.
Definição
Em um ciclo de vida de desenvolvimento com agentes, o ADLC, um agente como Claude Code, Codex, Claude Desktop ou o Copilot no modo agente lê a tarefa, planeja a alteração, escreve o código, executa os testes que pode, corrige o que falha e abre um pull request, muitas vezes várias vezes por hora.
- As pessoas definem o objetivo, revisam o que sai e decidem o que é entregue.
O ciclo gira muito mais rápido do que antes, e a qualidade do que é entregue depende da qualidade do que o agente consegue verificar sozinho.
Onde entram os testes de ponta a ponta
Definição
Um teste de ponta a ponta comanda o aplicativo do jeito que um usuário faz: ele o abre, clica e digita ao longo de um fluxo de trabalho inteiro e verifica o que a tela mostra.
- Para um agente, essa é a verdade de campo que o código não pode dar: o botão sobreviveu à mudança de estilo, o formulário ainda é enviado, o total ainda está certo.
Três coisas mantiveram os testes de ponta a ponta fora dos ciclos com agentes.
- Eles eram lentos de escrever, então ninguém escrevia um para uma alteração feita em dez minutos.
- Eles próprios eram código, então quebravam a cada elemento renomeado.
- E os seus resultados eram uma parede de logs a partir da qual um agente precisava adivinhar.
O GUI Test Studio elimina as três.
- Um teste é gravado ou descrito, nunca programado.
- Ele encontra os elementos com o GTS Engine + AI, por meio do que o aplicativo diz sobre eles, as suas informações de acessibilidade, e pela visão quando ele não diz nada, então um nome de classe alterado não quebra nada.
- E toda execução termina em um Relatório de confiança escrito com palavras simples, que um agente lê com a mesma facilidade que uma pessoa.
O restante deste artigo acompanha o ciclo, estágio por estágio.
| Estágio | O que o agente faz | Com o GUI Test Studio |
|---|---|---|
| Planejar | Lê a tarefa e decide o que verificar | Descreve em um prompt o fluxo de trabalho a testar, ou parte de um design do Figma |
| Programar | Escreve a alteração | Nada a fazer: nenhum código de teste para escrever ou atualizar |
| Testar | Executa os testes que tem | Grava um teste de ponta a ponta real por meio do conector, e depois o executa com o gtr-cli |
| Verificar | Lê os resultados | Lê o Relatório de confiança: encontrado ou não, alterado ou igual, com palavras simples |
| Corrigir | Altera o código de novo | Assume a issue do Jira que a execução reprovada registrou, com as suas etapas e imagens |
| Entregar | Abre o pull request | O pipeline executa todos os testes a cada build, sem janela e em paralelo |
Criar: um teste de ponta a ponta a partir de um prompt
Instale o GUI Test Studio e conecte o seu assistente uma única vez: no GUI Test Runner-Recorder, Criar teste a partir de um prompt mostra o Claude Desktop, o Claude Code e o VS Code, cada um com um botão Conectar.Qualquer outro assistente que fale o protocolo do conector está a um comando de distância.
Depois descreva o teste.O agente o grava como um testador faria: ele abre o aplicativo ou a página web, clica nos botões reais, digita nos campos reais e verifica o que vê à medida que avança, por meio do conector.Cada asserção é avaliada na hora, na tela real, e recusada quando não seria aprovada naquele momento, então o agente nunca salva uma asserção que está errada no primeiro dia.
O seu assistente
Gravando o teste na sua tela
- •Abri a loja e entrei
- •Adicionei a luminária de mesa e abri o carrinho
- •Verifiquei o total: $49.00 está na tela
- •Salvei Checkout.GTS e o executei: PASSED
O resultado é um teste comum do GUI Test Studio, com a mesma gravação, as mesmas etapas e as mesmas asserções que uma pessoa teria feito, salvo onde você escolher.No caminho, o agente pode pausar para pensar, desfazer uma etapa que deu errado, agrupar etapas em cenários, adicionar uma espera ou uma nota, e executar o teste no fim para provar que ele é aprovado.
With GUI Test Studio, create an end-to-end test of the shop at http://localhost:8080:
sign in as [email protected], add the "Desk lamp" to the cart, open the cart,
and verify that the total reads "$49.00" and that the "Checkout" button is shown.O agente testa o que você indica: a tela inteira, um aplicativo, uma área dele, uma página web no navegador da sua escolha ou um celular conectado.Ele não explora nada sem que peçam.Como conectar cada assistente e o que pedir está em Criar um teste a partir de um prompt.
Editar: alterar um teste por prompt, ou como um vídeo
Pelo conector, o agente lista as etapas de um teste por número e as altera no próprio arquivo: renomear uma etapa, alterar o texto que uma asserção espera, dar mais tempo a uma asserção, remover uma etapa ou ignorá-la, adicionar uma espera, dizer o que acontece se uma asserção falhar.Nada é escrito antes que o agente mostre as alterações e você as confirme, e o teste mantém todo o resto exatamente como estava.
Uma pessoa faz o mesmo no GUI Test Studio, em uma linha do tempo: as etapas são blocos que você move, apara, renomeia e agrupa, com desfazer para tudo, e o quadro da gravação sob cada um.O teste do agente e o teste do testador são o mesmo arquivo, como mostra Atualizar um teste.
Executar: headless, em paralelo, em qualquer pipeline de CI/CD
O gtr-cli executa qualquer teste do GUI Test Studio sem janela, a partir de um script ou de um pipeline, e responde do jeito que um pipeline espera: um código de saída, um arquivo JUnit para a ferramenta de CI, um arquivo JSON para um script, um resumo em Markdown para o pull request.
gtr-cli run tests --countdown 0 --format github --junit results\junit.xml ^
--json results\run.json --summary results\summary.md --artifacts results\artifacts ^
--jira on-failureUm teste web gravado uma vez pode ser gerado para outros navegadores e dispositivos: Chrome, Edge e Firefox, celulares, tablets e tamanhos de tela, outro idioma, uma rede lenta, um nível de zoom.Os navegadores e dispositivos que não precisam de janela rodam lado a lado, cada um em um processo próprio, e um teste de desktop roda na sua janela depois deles.Veja Navegadores e dispositivos.
O log fala o protocolo de cada ferramenta: --format teamcity, azure, github ou texto simples.O mesmo comando funciona no TeamCity, no Jenkins, no GitHub Actions, no GitLab, no Azure DevOps ou em um script seu, como mostra passo a passo Executar os seus testes de ponta a ponta a cada build.
| Opção | O que ela dá ao agente |
|---|---|
| --json | Um único arquivo com cada teste, etapa e veredito, o motivo de cada falha e as conclusões da IA: o que um script ou um agente lê primeiro |
| --junit | Os testes como testes no TeamCity, no Jenkins, no GitHub Actions, no GitLab ou no Azure DevOps |
| --summary | Um resumo para colar no pull request |
| --artifacts | O vídeo, as imagens e o relatório de bug de cada falha, em uma única pasta |
| --retries | Executar de novo um teste reprovado antes de considerá-lo reprovado |
| --branch all | Todos os navegadores e dispositivos para os quais o teste foi gerado, em um único build |
Ler: um veredito que um agente e uma pessoa entendem
Toda execução termina em um Relatório de confiança.Para cada asserção, ele diz com palavras simples se o elemento foi encontrado, se o que foi encontrado corresponde à gravação e quanta margem havia: uma asserção aprovada por pouco é um aviso antes de virar uma falha.
A Análise inteligente com IA, o lado de IA do GTS Engine + AI, olha uma asserção que falhou nos pixels e distingue uma regressão real de um ruído: uma palavra alterada, um selo ausente ou outra cor é uma regressão; um tom ou um deslocamento de um pixel não é.A resposta dela é o veredito final, e vem com uma frase com a qual um agente pode agir: o que mudou, onde e quanto.
Uma regressão real
Reprova a asserçãoRuído
É aprovadaUm agente lê o arquivo JSON e o resumo em Markdown que a execução escreve; uma pessoa abre o relatório, com as imagens lado a lado, o vídeo da execução e o histórico do teste.Os dois dizem a mesma coisa.O relatório é descrito em Ler o Relatório de confiança.
Corrigir: um bug no Jira que o agente pode assumir
Com --jira on-failure, um teste reprovado vira uma issue do Jira sozinho: um título, as etapas numeradas para reproduzir, a imagem que o teste esperava, a imagem que ele encontrou e essa imagem de novo com cada alteração contornada, além de um PDF e das evidências.O mesmo defeito visto de novo, em outro build, navegador ou dispositivo, adiciona um comentário à sua issue aberta, nunca uma duplicata.
O ciclo fechado: uma loja de demonstração
Criamos uma pequena demonstração para ver o ciclo inteiro girar: uma loja online, o seu teste de ponta a ponta, um servidor TeamCity, um projeto do Jira e um agente de programação com IA.Jean é o desenvolvedor, Pierre escreveu o teste, James cuida do backlog, John administra o TeamCity.
Jean faz o push de uma alteração
Uma mudança de estilo do checkout
O TeamCity executa o teste
Com o gtr-cli
O checkout falha
Uma issue do Jira, com imagens
O agente a corrige
Em um branch próprio
O teste é aprovado
Uma pessoa revisa e faz o merge
- 1
Uma alteração quebra o checkout
Jean faz o push de uma mudança de estilo dos botões do checkout.O TeamCity executa o teste de ponta a ponta da loja com o gtr-cli, sem janela, em todos os navegadores e dispositivos para os quais o teste foi gerado.
- 2
A execução diz o que quebrou, e onde
O Relatório de confiança encontra o botão do checkout, mas não como foi gravado.A Análise inteligente com IA confirma uma regressão real: o botão perdeu o rótulo.O gtr-cli registra uma issue do Jira com as etapas, as imagens esperada e encontrada e a alteração contornada, e o log do build do TeamCity cita a issue.
- 3
O agente a corrige
O agente assume a issue, lê as etapas e as imagens, encontra a regra de estilo que escondeu o rótulo e propõe uma correção em um branch próprio.
- 4
O teste comprova a correção
O TeamCity executa o mesmo teste no branch.Ele é aprovado.A execução aprovada é adicionada à issue do Jira, e James a fecha depois que uma pessoa revisa a alteração e faz o merge.Ninguém escreveu à mão um teste, um relatório de bug ou uma reprodução.
O lado humano
| Para | O que recebem |
|---|---|
| Testadores | Um teste que leem como um vídeo: uma linha do tempo de etapas com o quadro sob cada uma, sem código.Eles gravam um fluxo de trabalho em dois minutos, e o agente do desenvolvedor o executa a cada build |
| Desenvolvedores | Uma falha que diz o que mudou e onde, com as imagens lado a lado, e uma issue do Jira com a qual o agente deles pode agir |
| Product owners | Um veredito com palavras simples: encontrado ou não, alterado ou igual, e um histórico de todas as execuções |
| Segurança e TI | Testes, gravações e resultados que ficam nas suas máquinas Windows; o GTS Engine + AI roda ali, e a IA roda no seu próprio computador ou na nuvem com a sua própria chave |
On-premise ou na nuvem é escolha sua, asserção por asserção.Um agente que cria testes, um testador que os lê e um pipeline que os executa estão olhando para o mesmo arquivo, com as mesmas palavras.
Por onde começar
Pronto para gravar o seu primeiro teste?
Todos os recursos, por 15 dias.
Prefere ver no tipo de aplicativo que você testa?Agende uma chamada gratuita de 30 minutos com a nossa equipe.