Quando il bug si vede al primo click: audit UX automatizzato con Playwright
Ho usato Playwright in modalità headless per simulare un agente che apre la nostra PWA su tablet e clicca tutto: in trenta minuti sono usciti tredici bug oggettivi che gli utenti veri avrebbero visto al primo uso.
Volevo un primo filtro di test sulla PWA che stiamo per dare in mano agli agenti commerciali. Non avevo voglia di chiamare due colleghi e farli testare a freddo: volevo capire prima quanti bug oggettivi ci fossero — quelli che chiunque vede al primo click.
Il setup è stato veloce. La PWA usa un cookie JWT per l'auth (non-HttpOnly per design, perché va settato lato client al login). Ho scaricato il segreto dall'ambiente di produzione con vercel env pull, scritto un piccolo script Node che firma un token "agente puro" — senza bypass admin, perché volevo simulare un agente reale, non un superuser. Cookie iniettato via document.cookie dentro Playwright, viewport a 1024×1366 (tablet portrait), login Microsoft saltato a piè pari.
Lo scenario era una giornata tipica: home → cliente a rischio → catalogo → carrello → checkout (solo preventivi, mai ordini reali) → proposta confronto → giro pianificato → wizard verbale visita → statistiche → export CSV → budget → promozioni → logout.
Tredici bug oggettivi in una sessione. Tre meritano di essere raccontati.
"Ultimo ordine -119 giorni fa". La lista clienti mostrava giorni negativi per molti record. La query calcolava CURRENT_DATE - MAX(MAKE_DATE(anno, mese, 1)) su tutti i movimenti, inclusi gli ordini con consegna futura — perché in azienda si inseriscono ordini con consegna anche mesi avanti. Risultato: data futura → sottrazione negativa → "ultimo ordine fra 119 giorni". Fix di una riga: AND MAKE_DATE(...) <= CURRENT_DATE.
Add-to-cart silenzioso a 0 €. Articoli senza listino popolato finivano nel carrello a 0,00 €, l'API rispondeva 200, niente warning. L'agente avrebbe potuto inviare un preventivo con righe a zero senza accorgersene. Fix: badge "Prezzo da verificare" sulle righe interessate nello step di riepilogo del checkout.
185 clienti su 185 con badge "Rischio". Il classico null vs zero. Il campo health_score NULL veniva castato a 0, soglia < 35 → tutti high-risk. Il fix è un confronto in più: distinguere null da 0, mostrare il badge solo quando il punteggio è effettivamente calcolato e basso.
Una lezione metodologica che mi tengo: prima di fixare codice emerso da un audit UX, far girare il sync dei dati. Su cinque bug iniziali, uno si è auto-risolto col solo sync notturno — i dati erano vecchi, non il codice. Avrei sprecato tempo a investigare logica per qualcosa che non era un problema.
Questo metodo non sostituisce un agente vero che usa la PWA otto ore al giorno. Coglie i bug oggettivi — segno meno hardcoded, calcoli rotti, label fuorvianti, dead-end di navigazione. Non coglie quelli soggettivi: "questa lista è ordinata male per il mio workflow", "questa parola in questo contesto suona ambigua", "qui mi aspettavo un'azione e invece ne è partita un'altra".
Però come filtro pre-rilascio è sproporzionatamente efficace rispetto al costo. Trenta minuti di Playwright per il primo passaggio, più qualche ora per i fix, fanno una giornata in meno di feedback raccolto via messaggi dopo il rilascio.