Come eseguire agenti di controllo qualità su ogni richiesta di integrazione con QA.tech (senza scrivere un solo script di test)
Questo è un contenuto sponsorizzato da QA.tech. Scopri qui il nostro approccio editoriale trasparente.
Se il tuo team ha adottato strumenti di programmazione basati sull'IA, conosci già i numeri scomodi. I team di ingegneria che prima consegnavano una manciata di richieste pull a settimana ora ne consegnano cinquanta, cento, a volte anche di più: gran parte del codice viene scritto da agenti di programmazione, revisionato da agenti di revisione del codice e integrato a una velocità per la quale nessun processo di controllo qualità manuale era stato progettato. Un team con cui abbiamo parlato di recente aveva appena completato le prime cinquanta richieste pull scritte interamente dagli agenti e ci ha posto la domanda più ovvia: chi verifica tutto questo?
La risposta tradizionale, ovvero scrivere più script di test, non regge di fronte a un simile volume di richieste pull. Gli script richiedono più tempo per essere creati e mantenuti di quanto ne impieghi un agente per produrre il codice, quindi la suite rimane indietro già dal primo giorno e non riesce mai a recuperare.
Questa guida illustra l'alternativa che abbiamo realizzato in QA.tech: collegare i nostri agenti di controllo qualità al tuo repository, in modo che ogni richiesta pull attivi test basati sugli obiettivi, derivati automaticamente da ciò che è cambiato. Nessun codice di test, nessun selettore, nessuna coda di manutenzione. Ecco come configurare il sistema e cosa aspettarsi a ogni passaggio.
Passaggio 1: lascia prima che l'agente impari a conoscere la tua applicazione
Prima che l'integrazione con le richieste pull possa fare qualcosa di utile, l'agente deve conoscere il tuo prodotto. Quando colleghi QA.tech al tuo ambiente di staging o sandbox, esegue una scansione iniziale: esplora l'applicazione come farebbe un nuovo assunto meticoloso, seguendo ogni percorso e azione che riesce a trovare, e organizza tutto in un grafo della conoscenza che descrive la struttura del tuo prodotto.
Due note pratiche emerse da centinaia di configurazioni. Primo, se la tua applicazione richiede un accesso, configura il flusso di accesso come caso di test prerequisito: l'agente lo completa per primo e poi esegue la scansione di tutto ciò che si trova al suo interno. Secondo, sei tu a controllare la profondità della scansione. Una scansione superficiale, di uno o due passaggi all'interno di ogni percorso utente, è rapida e di solito sufficiente per iniziare; puoi approfondirla per i flussi più importanti invece di mappare tutto in modo esaustivo fin dall'inizio.
Questo passaggio è il motivo per cui l'integrazione con le richieste pull funziona. Poiché l'agente conosce ogni angolo dell'applicazione, può ragionare su ciò che una determinata modifica potrebbe influenzare: è esattamente il giudizio che un buon ingegnere del controllo qualità applica quando decide cosa verificare prima di una distribuzione.
Passaggio 2: collega il repository
L'integrazione con GitHub richiede pochi minuti: autorizza l'app, seleziona i repository e scegli quando devono essere eseguiti i test, in genere alla creazione o all'aggiornamento di una richiesta pull. Le richieste di unione di GitLab seguono lo stesso schema. Da questo momento, il testing fa parte della tua pipeline invece di essere una fase che si verifica dopo.
Passaggio 3: apri una richiesta pull e osserva cosa succede
Quando si apre una richiesta pull, l'agente legge ciò che è stato aggiunto e modificato, confronta queste informazioni con il proprio grafo della conoscenza e genera i casi di test giustificati dalla modifica: in genere quattro o cinque per una richiesta pull ordinaria, di più per le modifiche che interessano flussi condivisi. Poi li esegue immediatamente in un browser reale, interagendo visivamente con la build aggiornata, esattamente come farebbe un utente.
Questa è la parte che sorprende i team abituati alle suite di script attivate dalla CI: nessuno ha scritto quei casi di test. Sono stati ricavati dalla modifica stessa, nel contesto di tutto ciò che l'agente già sa del tuo prodotto. Pubblica un nuovo filtro nella dashboard e l'agente verifica il filtro e i flussi della dashboard in cui è inserito. Nessuno ha dovuto ricordarsi di aggiungere la copertura.
Passaggio 4: leggi i risultati nel luogo in cui i tuoi ingegneri lavorano già
Il risultato, positivo o negativo, viene registrato direttamente nella richiesta pull. Per ogni esecuzione, l'agente produce un rapporto di valutazione: l'obiettivo, il risultato atteso, ciò che è realmente accaduto, un video dell'esecuzione, schermate passo dopo passo e i registri della console e della rete sottostanti. Un errore non è una X rossa da analizzare a ritroso: è una spiegazione scritta di ciò che l'agente si aspettava di vedere e di ciò che invece ha rilevato.
Poiché l'agente esegue i test attraverso l'interfaccia, segnala gli errori a livello di prodotto: ti dirà che il codice sconto non viene più applicato al momento del pagamento, allegando le relative prove. Questo contesto a livello di prodotto è esattamente ciò di cui i tuoi ingegneri, o i tuoi agenti di programmazione, hanno bisogno per individuare e correggere la causa. I team che utilizzano cicli di sviluppo agentici reinviano i nostri rapporti di valutazione direttamente ai propri agenti di programmazione, come contesto dell'errore da usare per la correzione; inoltre, grazie all'integrazione MCP, questi agenti di programmazione possono attivare autonomamente le esecuzioni dei test mentre lavorano.
Passaggio 5: aggiungi la regressione ai test delle PR
I test attivati dalle PR verificano la modifica. I piani di regressione verificano tutto il resto. In QA.tech raggruppi i casi di test in piani: una suite di verifica essenziale per ogni distribuzione, una regressione completa prima dei rilasci principali, ed esegui i test con la cadenza più adatta al tuo processo di rilascio.
Poiché i test vengono eseguiti in parallelo, il tempo effettivo è una frazione di quello richiesto dalla stessa copertura eseguita manualmente. Un recente piano di regressione completo che abbiamo eseguito comprendeva un volume di test che avrebbe impegnato un tester manuale per uno o due giorni; è stato completato in circa venti minuti. È questa differenza a rendere "eseguire la regressione completa a ogni rilascio" una vera regola anziché un'aspirazione.
Passaggio 6: chiedi all'agente dove la tua copertura è insufficiente
Poiché il grafo della conoscenza mappa ogni flusso individuato durante la scansione, la piattaforma conosce la differenza tra ciò che contiene il tuo prodotto e ciò che verificano i tuoi test. Puoi chiederlo direttamente nella chat: "Quali sono i flussi di maggior valore per i quali al momento non abbiamo copertura?" L'agente risponde basandosi sulla mappa del tuo prodotto e può generare immediatamente i test mancanti.
Questo capovolge la dinamica abituale della copertura. Invece di essere il risultato di ciò che si è accumulato in anni di scrittura di test guidata dai ticket, la copertura diventa una domanda che puoi porre e a cui puoi dare seguito nello stesso pomeriggio.
Come appare tutto questo dopo un mese
Il modello che osserviamo nei vari team è coerente. La prima settimana prevede un certo scambio di informazioni: l'agente pone domande, occasionalmente ha bisogno di contesto sulle peculiarità del tuo prodotto e tu ne correggi la comprensione. Nella seconda settimana le domande sono rare. Nella terza si sono per lo più fermate, perché il grafo della conoscenza ha assimilato il funzionamento del tuo prodotto. Da quel momento, i test procedono al ritmo delle tue richieste di integrazione e le persone coinvolte esaminano i risultati invece di gestire gli script. Se vuoi la sequenza completa di implementazione, dalla prova di fattibilità fino alla dismissione delle suite di test obsolete, l'abbiamo pubblicata come guida pratica, {{deeplink:260096:[Adottare i test agentici: il progetto.:ebook}}
Per i team che sono passati al codice scritto dagli agenti, questo completa il ciclo che mancava: generazione del codice, revisione del codice e verifica, tutto eseguito alla velocità delle macchine, con i tuoi ingegneri che dirigono il sistema invece di alimentarlo.
Domande frequenti
Quanti casi di test genera QA.tech per ogni richiesta di integrazione?
Una PR ordinaria produce in genere da quattro a cinque casi di test, derivati da ciò che è cambiato. Le modifiche più ampie che interessano flussi condivisi ne generano di più.
I test delle PR richiedono casi di test esistenti?
No. L’agente genera i casi di test a partire dalla modifica e dalla conoscenza della tua applicazione. I team che partono da zero come copertura dei test possono iniziare a livello di PR e creare piani di regressione nel tempo.
Cosa succede quando l'interfaccia utente cambia in una richiesta di integrazione?
L’agente lavora a partire dagli obiettivi e dalla comprensione visiva anziché dai selettori, quindi completa il test sulla nuova interfaccia e segnala un errore solo quando il comportamento è effettivamente errato.
Quali configurazioni CI/CD supporta l'integrazione delle PR di QA.tech?
Le richieste di integrazione di GitHub e le richieste di unione di GitLab sono i principali punti di integrazione, con i risultati riportati nella PR come controllo.
Scopri cosa generano gli agenti QA per la tua prossima richiesta di integrazione: collega un repository a QA.tech ed esegui il primo test in pochi minuti.