Sviluppo con agenti IA (ADLC): dove si colloca GUI Test Studio
Gli agenti di programmazione IA pianificano, scrivono, testano, correggono e rilasciano, con le persone al timone: il ciclo di vita dello sviluppo agentico, o ADLC.Dove si colloca il test end-to-end in quel ciclo, e come GUI Test Studio dà a un agente un test che può creare da un prompt, modificare sul posto, eseguire senza finestra e in parallelo in qualsiasi pipeline CI/CD, leggere come un esito in parole semplici e aprire in Jira, finché il ciclo si chiude.
9 min di letturaDal team di GUI Test Studio
Che cos'è il ciclo di vita dello sviluppo agentico (ADLC)
Per decenni il software è stato costruito lungo il ciclo di vita dello sviluppo software, l'SDLC: un team pianifica, uno sviluppatore programma, un tester testa, qualcuno corregge, qualcuno rilascia, e il ciclo ricomincia.Gli agenti di programmazione IA non hanno sostituito quel ciclo.Ne hanno preso in mano il ciclo interno.
In un ciclo di vita dello sviluppo agentico, l'ADLC, un agente come Claude Code, Codex, Claude Desktop o Copilot in modalità agente legge l'attività, pianifica la modifica, scrive il codice, esegue i test che può, corregge ciò che non passa e apre una pull request, spesso più volte in un'ora.Le persone fissano l'obiettivo, rivedono ciò che ne esce e decidono cosa rilasciare.Il ciclo gira molto più in fretta di prima, e la qualità di ciò che viene rilasciato dipende dalla qualità di ciò che l'agente riesce a controllare da solo.
Gli agenti sono bravi nei controlli che vivono nel codice: test unitari, controlli dei tipi, linter.Sono ciechi all'unica cosa che un utente vede: l'applicazione in esecuzione, su uno schermo reale, attraverso la sua interfaccia reale.È lì che si colloca il test end-to-end, ed è lì che la maggior parte dei cicli agentici ha ancora un buco.
Dove si colloca il test end-to-end
Un test end-to-end guida l'applicazione come farebbe un utente: la apre, fa clic e digita lungo un intero flusso, e verifica cosa mostra lo schermo.Per un agente è la verità di fatto che il codice non può dare: il pulsante è sopravvissuto al nuovo stile, il modulo si invia ancora, il totale è ancora giusto.
Tre cose hanno tenuto i test end-to-end fuori dai cicli agentici.Erano lenti da scrivere, quindi nessuno ne scriveva uno per una modifica fatta in dieci minuti.Erano a loro volta codice, quindi si rompevano a ogni elemento rinominato.E i loro risultati erano un muro di log da cui un agente doveva tirare a indovinare.
GUI Test Studio le elimina tutte e tre.Un test viene registrato o descritto, mai programmato.Trova gli elementi con il GTS Engine + AI, tramite ciò che l'applicazione dice di loro, le sue informazioni di accessibilità, e a vista quando non dice nulla, quindi un nome di classe cambiato non rompe nulla.E ogni esecuzione termina con un report di affidabilità scritto in parole semplici, che un agente legge con la stessa facilità di una persona.Il resto di questo articolo segue il ciclo, fase per fase.
| Fase | Cosa fa l'agente | Con GUI Test Studio |
|---|---|---|
| Pianifica | Legge l'attività e decide cosa controllare | Descrive in un prompt il flusso da testare, oppure parte da un design Figma |
| Codifica | Scrive la modifica | Nulla da fare: nessun codice di test da scrivere o aggiornare |
| Testa | Esegue i test che ha | Registra un vero test end-to-end attraverso il connettore, poi lo esegue con gtr-cli |
| Verifica | Legge i risultati | Legge il report di affidabilità: trovato o no, cambiato o uguale, in parole semplici |
| Correggi | Modifica di nuovo il codice | Prende in carico il ticket Jira aperto dall'esecuzione non superata, con i suoi passaggi e le sue immagini |
| Rilascia | Apre la pull request | La pipeline esegue ogni test a ogni build, senza finestra e in parallelo |
Creare: un test end-to-end da un prompt
Installate GUI Test Studio e connettete il vostro assistente una volta: in GUI Test Runner-Recorder, Crea test da prompt mostra Claude Desktop, Claude Code e VS Code, ciascuno con un pulsante Connetti.Qualsiasi altro assistente che parli il protocollo del connettore è a un comando di distanza.
Poi descrivete il test.L'agente lo registra come farebbe un tester: apre l'applicazione o la pagina web, fa clic sui pulsanti reali, digita nei campi reali e verifica man mano ciò che vede, attraverso il connettore.Ogni controllo viene valutato sul momento, sullo schermo reale, e rifiutato quando non passerebbe adesso, così l'agente non salva mai un controllo sbagliato fin dal primo giorno.
Il vostro assistente
Registro il test sullo schermo
- •Negozio aperto e accesso effettuato
- •Lampada da scrivania aggiunta, carrello aperto
- •Totale verificato: $49.00 è sullo schermo
- •Checkout.GTS salvato ed eseguito: PASSED
Ciò che ne esce è un normale test di GUI Test Studio, con la stessa registrazione, gli stessi passaggi e gli stessi controlli che avrebbe fatto una persona, salvato dove scegliete voi.Strada facendo l'agente può fermarsi a pensare, annullare un passaggio andato male, raggruppare i passaggi in scenari, aggiungere un'attesa o una nota, ed eseguire il test alla fine per dimostrare che passa.
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.L'agente testa ciò che gli indicate: tutto lo schermo, un'applicazione, un'area di essa, una pagina web nel browser che scegliete, o un telefono collegato.Non esplora nulla senza che gli venga chiesto.Come connettere ciascun assistente e cosa chiedere è in Creare un test da un prompt.
Modificare: cambiare un test da prompt, o come un video
I test invecchiano con l'applicazione.Quando l'agente rinomina un pulsante o aggiunge un campo, dovrebbe aggiornare anche il test, non registrarne uno nuovo.
Attraverso il connettore l'agente elenca i passaggi di un test per numero e li modifica sul posto: rinominare un passaggio, cambiare il testo che un controllo si aspetta, dare più tempo a un controllo, rimuovere un passaggio o ignorarlo, aggiungere un'attesa, dire cosa succede se un controllo non passa.Nulla viene scritto prima che l'agente mostri le modifiche e voi le confermiate, e il test conserva tutto il resto esattamente com'era.
Una persona fa lo stesso in GUI Test Studio, su una timeline: i passaggi sono blocchi che spostate, accorciate, rinominate e raggruppate, con l'annullamento per tutto, e il fotogramma della registrazione sotto ciascuno.Il test dell'agente e il test del tester sono lo stesso file, come mostra Aggiornare un test.
Eseguire: senza finestra, in parallelo, in qualsiasi pipeline CI/CD
gtr-cli esegue qualsiasi test di GUI Test Studio senza finestra, da uno script o da una pipeline, e risponde come si aspetta una pipeline: un codice di uscita, un file JUnit per lo strumento di CI, un file JSON per uno script, un riepilogo Markdown per la 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-failureUn test web registrato una volta può essere generato per altri browser e dispositivi: Chrome, Edge e Firefox, telefoni, tablet e dimensioni dello schermo, un'altra lingua, una rete lenta, un livello di zoom.I browser e i dispositivi che non hanno bisogno di una finestra vengono eseguiti affiancati, ciascuno in un processo proprio, e un test desktop viene eseguito nella sua finestra dopo di loro.Vedete Browser e dispositivi.
Il log parla il protocollo proprio di ogni strumento: --format teamcity, azure, github o testo semplice.Lo stesso comando funziona in TeamCity, Jenkins, GitHub Actions, GitLab, Azure DevOps o in uno script vostro, come mostra passo dopo passo Eseguite i vostri test end-to-end a ogni build.
| Opzione | Cosa dà all'agente |
|---|---|
| --json | Un solo file con ogni test, passaggio ed esito, il motivo di ogni errore e le conclusioni dell'IA: ciò che uno script o un agente legge per primo |
| --junit | I test come test in TeamCity, Jenkins, GitHub Actions, GitLab o Azure DevOps |
| --summary | Un riepilogo da incollare nella pull request |
| --artifacts | Il video, le immagini e la segnalazione di bug di ogni errore, in una sola cartella |
| --retries | Esegue di nuovo un test non superato prima di dichiararlo tale |
| --branch all | Ogni browser e dispositivo per cui il test è stato generato, in una sola build |
Leggere: un esito che un agente e una persona capiscono entrambi
Ogni esecuzione termina con un report di affidabilità.Per ogni controllo dice, in parole semplici, se l'elemento è stato trovato, se ciò che è stato trovato corrisponde alla registrazione, e quanto margine c'era: un controllo passato di misura è un avvertimento prima che diventi un errore.
L'Analisi intelligente con IA, il lato IA del GTS Engine + AI, guarda un controllo non superato sui pixel e distingue una vera regressione dal rumore: una parola cambiata, un badge mancante o un altro colore sono una regressione; una sfumatura o uno spostamento di un pixel non lo sono.La sua risposta è l'esito finale, e arriva con una frase su cui un agente può agire: cosa è cambiato, dove e di quanto.
Un agente legge il file JSON e il riepilogo Markdown che l'esecuzione scrive; una persona apre il report, con le immagini affiancate, il video dell'esecuzione e la cronologia del test.Entrambi dicono la stessa cosa.Il report è descritto in Leggere il report di affidabilità.
Correggere: un bug Jira che l'agente può prendere in carico
Con --jira on-failure, un test non superato diventa da solo un ticket Jira: un titolo, i passaggi numerati per riprodurre, l'immagine che il test si aspettava, l'immagine che ha trovato e di nuovo quell'immagine con ogni modifica evidenziata, più un PDF e le prove.Lo stesso difetto visto di nuovo, in un'altra build, su un altro browser o dispositivo, aggiunge un commento al suo ticket aperto, mai un duplicato.
Quel ticket è scritto per uno sviluppatore, e si rivela esattamente ciò di cui un agente di programmazione ha bisogno: un percorso riproducibile, un'aspettativa precisa e un'immagine della differenza.Indicate il ticket all'agente e avrà tutto per proporre una correzione.Come si connette Jira, dal report di affidabilità o da una pipeline, è in ogni test end-to-end non superato diventa un bug Jira.
Il ciclo, chiuso: un negozio demo
Abbiamo costruito una piccola demo per guardare girare l'intero ciclo: un negozio online, il suo test end-to-end, un server TeamCity, un progetto Jira e un agente di programmazione IA.Jean è lo sviluppatore, Pierre ha scritto il test, James si occupa del backlog, John gestisce TeamCity.
Jean fa il push di una modifica
Un nuovo stile per il checkout
TeamCity esegue il test
Con gtr-cli
Il checkout non passa
Un ticket Jira, con le immagini
L'agente lo corregge
Su un proprio branch
Il test passa
Una persona rivede e fa il merge
- 1
Una modifica rompe il checkout
Jean fa il push di un nuovo stile per i pulsanti del checkout.TeamCity esegue il test end-to-end del negozio con gtr-cli, senza finestra, su ogni browser e dispositivo per cui il test è stato generato.
- 2
L'esecuzione dice cosa si è rotto, e dove
Il report di affidabilità trova il pulsante del checkout, ma non com'era stato registrato.L'Analisi intelligente con IA conferma una vera regressione: il pulsante ha perso la sua etichetta. gtr-cli apre un ticket Jira con i passaggi, le immagini attesa e trovata e la modifica evidenziata, e il log di build di TeamCity indica il ticket.
- 3
L'agente lo corregge
L'agente prende in carico il ticket, legge i passaggi e le immagini, trova la regola di stile che ha nascosto l'etichetta e propone una correzione su un proprio branch.
- 4
Il test dimostra la correzione
TeamCity esegue lo stesso test sul branch.Passa.L'esecuzione superata viene aggiunta al ticket Jira, e James lo chiude una volta che una persona ha rivisto la modifica e ne ha fatto il merge.Nessuno ha scritto a mano un test, una segnalazione di bug o una riproduzione.
Il lato umano
Un ADLC non è fatto di soli agenti.Le persone che lo guidano devono potersi fidare di ciò che gli agenti controllano, e controllarlo di persona quando conta.GUI Test Studio è stato costruito per questo: lo stesso test serve all'agente e alla persona.
| Per | Cosa ottengono |
|---|---|
| Tester | Un test che leggono come un video: una timeline di passaggi con il fotogramma sotto ciascuno, niente codice.Registrano un flusso in due minuti, e l'agente dello sviluppatore lo esegue a ogni build |
| Sviluppatori | Un errore che dice cosa è cambiato, dove, con le immagini affiancate, e un ticket Jira su cui il loro agente può agire |
| Product owner | Un esito in parole semplici: trovato o no, cambiato o uguale, e una cronologia di ogni esecuzione |
| Sicurezza e IT | Test, registrazioni e risultati che restano sulle vostre macchine Windows; il GTS Engine + AI funziona lì, e l'IA funziona sul vostro computer o nel cloud con la vostra chiave |
On-premise o nel cloud è una scelta vostra, controllo per controllo.Un agente che crea i test, un tester che li legge e una pipeline che li esegue guardano lo stesso file, con le stesse parole.
Da dove cominciare
Pronti a registrare il vostro primo test?
Tutte le funzionalità, per 15 giorni.
Preferite vederlo sul tipo di app che testate?Prenotate una chiamata gratuita di 30 minuti con il nostro team.