I prodotti semplici sono facili da testare, e ormai quasi nessuno sviluppa più prodotti semplici. Le piattaforme SaaS B2B con cui lavoriamo su QA.tech condividono alcune caratteristiche: molteplici ruoli utente con autorizzazioni diverse, schermate la cui struttura dipende interamente dai dati sottostanti, flussi di lavoro che si sviluppano in una dozzina di passaggi e diverse dipendenze e, sempre più spesso, funzionalità che si estendono tra web, API e dispositivi mobili all'interno di un unico percorso utente.
È esattamente questo l'ambito in cui l'automazione dei test basata su script costa di più e offre la copertura minore. Ogni ruolo moltiplica i percorsi. Ogni stato dei dati li moltiplica di nuovo. Una suite di test che coprisse davvero tutte le combinazioni sarebbe più grande del prodotto stesso; perciò, nella pratica, i team scrivono script per i percorsi principali, verificano manualmente a campione il resto e accettano il divario.
Questo articolo analizza come gli agenti di QA.tech gestiscono in modo diverso ciascuna di queste dimensioni della complessità, sulla base dell'esperienza con i team di inserimento nel settore fintech, delle tecnologie HR, delle infrastrutture per l'e-commerce e dell'assistenza sanitaria: prodotti per i quali "registrare semplicemente il flusso" non avrebbe mai funzionato.
Il modello mentale corretto: stai inserendo un nuovo collega
La prospettiva che permette di comprendere tutto ciò che segue è nata proprio da un cliente. Un responsabile QA che osservava l'agente esplorare la sua piattaforma per la prima volta ha chiesto: "Quindi si comporta come una persona appena entrata in azienda?" Esattamente. L'agente entra a far parte del team proprio come farebbe un nuovo e brillante professionista QA: esplora il prodotto, costruisce un modello mentale, pone domande quando incontra qualcosa di ambiguo e, nelle prime settimane, viene corretto occasionalmente. La differenza sta in ciò che accade dopo: la comprensione che sviluppa è un grafo della conoscenza persistente, non dimentica mai una correzione e applica ogni elemento di contesto a tutti i test futuri.
Questo modello mentale è importante perché i prodotti complessi sono proprio quelli in cui il periodo da "nuovo arrivato" dà i suoi frutti. Uno script conosce un percorso attraverso il tuo prodotto. Un agente addestrato conosce il tuo prodotto.
Ruoli e autorizzazioni: insegnagli l'intera mappa, poi dagli qualsiasi chiave
I sistemi di autorizzazione sono il punto in cui le suite basate su script si arrendono silenziosamente. Se la tua piattaforma dispone dei ruoli di amministratore, responsabile e membro, oppure di cinquanta configurazioni di ruolo specifiche per i clienti, un approccio basato sugli script richiede una copertura scritta separatamente per ogni ruolo e diventa obsoleto non appena cambiano le autorizzazioni.
L'approccio basato sugli agenti inverte questa logica. Innanzitutto, l'agente esplora il tuo prodotto con un account amministratore, così il suo grafo della conoscenza copre l'intera superficie: ogni schermata, ogni azione, ogni flusso esistente. Poi gli fornisci account con accesso limitato. Accedendo come membro, l'agente vede meno opzioni e, poiché conosce la mappa completa, comprende cosa manca e perché, invece di rimanere confuso da un'interfaccia più ridotta.
Da quel momento, verifica delle autorizzazioni diventa una conversazione. Di' all'agente "in quanto appartenente a questa categoria di utenti, dovresti vedere solo X, Y e Z" e l'agente verificherà il confine. Ecco il dettaglio che i team apprezzano maggiormente: quando un utente con accesso limitato non può realmente raggiungere una schermata, l'agente registra un superamento del test, dimostrando che il sistema di autorizzazioni sta svolgendo il proprio compito. Confermi questa aspettativa una volta, l'agente la codifica e un'intera categoria di verifiche rilevanti per la sicurezza viene eseguita continuamente senza che nessuno debba scrivere script.
Flussi basati sui dati: stesso obiettivo, dati diversi, nessuna nuova scrittura
Nei SaaS ricchi di dati, raramente è il flusso a essere la parte difficile: lo sono le permutazioni. Creare un record è un test; crearlo con cinquanta profili di dati diversi, alcuni dei quali dovrebbero avere esito positivo e altri essere rifiutati, è il punto in cui i test manuali vengono sommersi e gli script si trasformano in matrici di parametri impossibili da manutenere.
Poiché l'agente opera a partire dagli obiettivi anziché dai passaggi registrati, la variazione dei dati richiede una sola istruzione: "Esegui nuovamente questo caso di test con questi dati". La conoscenza del flusso rimane invariata; cambiano solo gli input. I casi negativi funzionano allo stesso modo: descrivi ciò che dovrebbe essere rifiutato e l'agente verifica che il prodotto risponda negativamente quando previsto. Per i campi di testo libero, presenti in abbondanza in ogni prodotto complesso, l'agente attinge al contesto del prodotto che gli hai fornito per inserire valori sensati e, quando sbaglia, correggi la sua comprensione una sola volta invece di modificare uno script.
Flussi di lavoro lunghi: l'agente conosce già i prerequisiti
I flussi di lavoro dei SaaS aziendali presentano catene di dipendenze: non puoi modificare un'opportunità finché non ne esiste una, non puoi approvare una richiesta finché qualcuno non ne invia una, e non puoi testare il decimo passaggio senza aver completato i primi nove. Nelle suite basate su script, questo si traduce in codice di configurazione: dispositivi di test, dati iniziali e script di supporto che comportano a loro volta un onere di manutenzione.
L’agente gestisce le catene proprio come una persona: ricordando. Una volta completato un flusso, tutto ciò che viene dopo si basa su quella conoscenza. Chiedigli di testare le sotto-allocazioni di un accordo e saprà che prima deve essere creato l’accordo, perché lo ha già fatto e il percorso è presente nel suo grafo della conoscenza. I flussi prerequisiti, come l’accesso, vengono configurati una volta e riutilizzati ovunque. Più i tuoi flussi di lavoro sono profondi, più questo effetto cumulativo è importante, perché ogni passaggio che l’agente già conosce è un passaggio che nessuno deve riscrivere.
Percorsi tra più superfici: web, API e dispositivi mobili in un unico test
I percorsi reali degli utenti nei moderni prodotti SaaS non rispettano i confini degli strumenti di test. Un utente configura qualcosa sul web, si attiva un webhook, un record viene aggiornato tramite API e una notifica arriva nell’app mobile. La maggior parte dei team testa ogni superficie con uno strumento separato, usando script separati, e spera che i punti di collegamento funzionino.
QA.tech esegue questi percorsi come singoli test dall’inizio alla fine: un flusso può iniziare nel prodotto web, includere passaggi di test delle API nella parte centrale e terminare nell’app nativa iOS o Android, verificando il percorso nel modo in cui lo vive realmente il tuo cliente. Per le piattaforme in cui i punti di collegamento tra le superfici sono proprio il luogo in cui si nascondono i bug – pagamenti, notifiche, sincronizzazione – questo elimina il divario che gli strumenti specifici per superficie non possono colmare per loro stessa struttura.
Il risultato complessivo
Il modello osservato nei team che lavorano su prodotti complessi è coerente. Le prime settimane sono collaborative: l’agente esplora, fa domande e viene corretto, mentre il team impara a fornirgli istruzioni. Poi le domande diminuiscono gradualmente e lo sforzo di test si svincola dalla complessità del prodotto: nuovi ruoli, nuovi stati dei dati e nuovi passaggi dei flussi di lavoro vengono assorbiti nel grafo della conoscenza invece di generare nuovo lavoro di scrittura degli script.
Il risultato si misura in ore. Pricer, un’azienda di tecnologia per il commercio al dettaglio, la cui piattaforma è esattamente questo tipo di prodotto complesso e ricco di dati, ha misurato un risparmio di 390 ore QA per trimestre dopo aver trasferito la verifica agli agenti QA: capacità che è tornata a essere impiegata nella distribuzione di nuove funzionalità anziché nella manutenzione dell’infrastruttura di test.
E c’è un vantaggio più discreto che i responsabili dell’ingegneria citano: l’esplorazione dell’agente porta alla luce le combinazioni che nessuno aveva pensato di testare. Quando la tua copertura deriva da un sistema che ha mappato l’intero prodotto, anziché da un arretrato di ticket di test, la domanda “ci avevi pensato?” diventa qualcosa che la piattaforma pone a te.
Domande frequenti
Gli agenti di QA.tech possono testare il controllo degli accessi basato sui ruoli in un SaaS B2B?
Sì. L’agente mappa l’intera applicazione da un account amministratore, quindi esegue i test come qualsiasi utente con accesso limitato, verificando che ogni ruolo veda esattamente ciò che dovrebbe vedere. I blocchi previsti relativi alle autorizzazioni vengono codificati come risultati superati.
In che modo gli agenti di QA.tech gestiscono gli scenari di test basati sui dati?
Lo stesso caso di test viene eseguito con dati diversi su istruzione – “esegui di nuovo con questi dati” – senza doverlo riscrivere. Sia i casi positivi sia quelli negativi derivano dall’obiettivo descritto.
QA.tech supporta i test su web, API e dispositivi mobili in un unico flusso?
Sì. Un singolo test QA.tech può combinare passaggi web, passaggi di test delle API e passaggi nativi iOS o Android, verificando i percorsi tra più superfici dall’inizio alla fine.
Quanto tempo impiega QA.tech per imparare un prodotto SaaS complesso?
La scansione iniziale richiede pochi minuti; per sviluppare una comprensione completa di ruoli, dati e flussi di lavoro servono in genere alcune settimane di utilizzo normale. Le domande dell’agente diminuiscono gradualmente man mano che il suo grafo della conoscenza si completa.
Hai un prodotto che manda in crisi gli strumenti di test? indirizza gli agenti di QA.tech al tuo ambiente di pre-produzione: sono stati creati proprio per gestire la complessità.