Test di regressione visiva nel workflow CI: così il layout entra nella pipeline

I team di sviluppo moderni si affidano alla loro pipeline di continuous integration: ogni push avvia una build, gli unit test girano, il linter controlla lo stile e solo quando tutto è verde il codice passa nel ramo principale. Questa rete di sicurezza ha però un punto cieco. Se il sito web, dopo la modifica, abbia ancora l'aspetto che dovrebbe avere, la pipeline classica non lo verifica. Un refactoring CSS può superare tutti i test e spingere comunque il modulo di contatto dietro il footer.

La ragione sta nella natura dei tipi di test abituali. Gli unit test verificano le funzioni rispetto ai valori di ritorno attesi, i test di integrazione l'interazione tra i componenti, i test end-to-end percorrono i flussi cliccando e controllano che gli elementi definiti siano presenti. Nessuno di questi approcci vede la pagina come la vede un essere umano: come immagine renderizzata. Un pulsante può essere tecnicamente presente, cliccabile e correttamente etichettato — e restare comunque invisibile, bianco su bianco.

Come nascono rotture del genere lo mostra uno sguardo alla quotidianità: un aggiornamento delle dipendenze porta con sé una nuova versione del framework CSS che imposta diversamente alcune spaziature predefinite. Un refactoring rinomina una classe utility ancora usata in un punto dimenticato. Un file di font viene sostituito e risulta leggermente più largo, al che una barra di navigazione va a capo. Niente di tutto questo genera un errore, niente fa fallire la build — e ognuna di queste modifiche, vista nel codice, sembra del tutto innocua.

I test di regressione visiva colmano questa lacuna con un principio semplice. Di pagine definite viene fissato uno stato di riferimento, la cosiddetta baseline. Dopo ogni modifica nascono nuovi screenshot, che uno strumento confronta con questa baseline. Se l'immagine attuale si discosta, la verifica scatta e un essere umano decide: modifica voluta o regressione?

La domanda interessante per la pratica non è tanto il se quanto il dove: in quale punto del workflow CI trovano posto verifiche di questo tipo? A differenza degli unit test, che lavorano direttamente sul codice sorgente, i test visivi hanno bisogno di una pagina renderizzata e raggiungibile in rete. Questo li sposta alla fine della catena — là dove esiste già una versione funzionante dell'applicazione.

Servizi come ScanU lavorano perciò su base URL: si consegna l'indirizzo di una pagina raggiungibile e il servizio crea in circa 30 secondi screenshot su più browser e classi di dispositivi — Chrome, Firefox e Safari, ciascuno in vista mobile, tablet e desktop. Come ScanU costruisce passo dopo passo un simile ciclo di verifica lo descrive il fornitore stesso; lo schema di fondo vale però per ogni strumento basato su URL: senza un ambiente che serva la nuova versione, non c'è nulla da fotografare.

Nel modo più elegante tutto questo si inserisce nei workflow con le cosiddette deploy preview. Molte piattaforme di hosting costruiscono automaticamente, per ogni pull request, un ambiente di anteprima dedicato con un proprio indirizzo. Proprio questo indirizzo è il punto di aggancio naturale per il confronto visivo: l'anteprima mostra lo stato dopo la modifica, la baseline lo stato approvato precedente. Se il confronto segnala uno scostamento, tutte le persone coinvolte vedono il problema prima che il codice raggiunga il ramo principale — e la discussione avviene dove deve avvenire: nella review.

In concreto, in una pipeline del genere la sequenza è questa: prima la CI costruisce la nuova versione, poi la piattaforma di hosting pubblica l'ambiente di anteprima e ne restituisce l'indirizzo, e solo dopo può partire il passaggio di verifica visiva. È esattamente in questo punto che nella pratica qualcosa va storto più spesso. Chi avvia il ciclo di screenshot prima che l'anteprima sia completamente pubblicata fotografa una pagina caricata a metà o un messaggio di errore — e poi la confronta, con la massima serietà, con la baseline. Un rapido controllo di raggiungibilità dell'indirizzo di anteprima prima dell'esecuzione vera e propria risparmia questo genere di confusione. Quando il report è pronto, il suo link va allegato alla pull request, come commento o nel testo descrittivo, perché la valutazione avvenga dove comunque si discute della modifica. I report condivisibili, come quelli generati da ScanU, sono pensati esattamente per questo gesto: il report è la base di discussione comune, non la finestra di uno strumento che una sola persona ha aperto.

I team senza ambienti di anteprima ripiegano sull'ambiente di staging e verificano dopo il merge, ma prima del deployment in produzione. È la seconda scelta migliore: le regressioni emergono più tardi, quando più modifiche si sono già mescolate, e la ricerca del responsabile diventa più faticosa. Un ulteriore ciclo regolare contro il sito in produzione intercetta inoltre cambiamenti che non provengono affatto dal proprio codice — per esempio quando uno script incorporato dall'esterno o un aggiornamento del CMS sposta l'aspetto della pagina.

L'integrazione tecnica è la parte minore del lavoro. Quella maggiore è una questione di processo: la cura della baseline. Una baseline non è un artefatto tecnico, ma un accordo — così deve apparire la pagina. Chi distribuisce una modifica di design voluta deve poi aggiornare consapevolmente la baseline, altrimenti ogni esecuzione successiva segnalerà lo stesso scostamento atteso. Chi invece la aggiorna per riflesso dopo ogni allarme, prima o poi dichiara stato di riferimento un errore vero.

Si è dimostrato utile trattare gli aggiornamenti della baseline come modifiche al codice: qualcuno li guarda, qualcuno li approva e l'approvazione è tracciabile. ScanU a questo scopo affianca baseline e stato attuale e genera report condivisibili. Suona poco spettacolare, ma cambia la collaborazione: anche le colleghe e i colleghi del design o del product management possono giudicare uno scostamento senza avviare un ambiente di sviluppo — e la decisione «voluto o rotto» spesso non è puramente tecnica.

Un team dovrebbe inoltre chiarire a chi appartiene la verifica. I test visivi che non sono assegnati a nessuno finiscono immancabilmente abbandonati: i report si accumulano, nessuno si sente responsabile, dopo un mese li ignorano tutti. Si è affermata la stessa regola delle build rotte — chi ha causato la modifica si occupa dello scostamento segnalato, e un turno a rotazione tiene d'occhio le esecuzioni regolari.

Della pianificazione fa parte anche la domanda su quanto spesso verificare. Non ogni commit ha bisogno del passaggio completo su tutte le pagine e combinazioni di dispositivi. Modelli di fatturazione come il sistema a crediti di ScanU rendono concreta questa riflessione: il livello gratuito comprende 500 crediti al mese per un progetto, i livelli a pagamento vanno da 3000 crediti per 19 euro fino a 50000 crediti per 49 euro al mese. Chi fa passare ogni esecuzione della pipeline per tutti i profili di dispositivo esaurisce in fretta il proprio contingente — e produce, per inciso, più report di quanti il team riesca davvero a guardare.

Più sensata è una gradazione. Le pull request con modifiche a stili o template ricevono il confronto sulle pagine più importanti; un'esecuzione giornaliera o settimanale copre il set più ampio su tutti i browser; prima di una release gira tutto una volta. Così il rapporto segnale-rumore resta sano e ogni allarme ha una possibilità reale di essere preso sul serio. Un test visivo le cui segnalazioni il team liquida per abitudine con un clic vale meno di nessun test.

Nella scelta delle pagine vale: template invece di istanze. Un negozio online non deve fotografare 2000 pagine prodotto, ma una pagina rappresentativa per tipo di layout. Home page, una pagina prodotto o articolo per modello, carrello, moduli e la pagina di errore coprono, nella maggior parte dei progetti, il grosso del rischio. Le pagine ad alto valore di business — per esempio il processo di pagamento — meritano più combinazioni di dispositivi dell'Impressum, le note legali obbligatorie sui siti tedeschi.

La stessa ponderazione vale per i profili di dispositivo. I livelli di prezzo di ScanU si differenziano anche nel numero di dispositivi disponibili — da dieci nel livello gratuito fino a 98 nel più grande. La cosa invita alla completezza, ma più profili significano più immagini, più crediti e più lavoro di revisione. Più praticabile è orientarsi sui propri numeri di accesso: le tre, quattro combinazioni di dispositivi da cui arriva effettivamente la maggior parte delle visitatrici e dei visitatori, più un rappresentante per ciascuna delle misure estreme — molto stretto, molto largo.

Un ostacolo merita particolare attenzione: i contenuti dinamici. Teaser a rotazione, raccomandazioni personalizzate, banner dei cookie, orari visualizzati o pubblicità cambiano l'immagine a ogni caricamento — senza alcuna regressione. Questi falsi allarmi sono il motivo più frequente per cui i team spengono di nuovo i test visivi dopo poche settimane. Gli antidoti sono noti: ambienti di test con dati di esempio fissi, animazioni disattivate, stati di partenza coerenti. I falsi allarmi non spariscono mai del tutto, ma si possono comprimere a un livello sopportabile.

Fa parte dell'onestà anche nominare i limiti. Un confronto di screenshot superato non dice nulla sul fatto che il modulo invii davvero i dati, che la ricerca restituisca risultati o che il processo di pagamento vada in porto. I test visivi verificano la presentazione, non la funzione — integrano gli unit test e i test end-to-end, non li sostituiscono. Chi riduce la propria copertura di test funzionali a favore degli screenshot scambia un rischio con un altro.

Anche il valore informativo dipende dall'ambiente. Le verifiche basate su URL fotografano ciò che l'indirizzo indicato serve. Se l'ambiente di staging si discosta nettamente dalla produzione — dati diversi, feature flag diversi, script di terze parti assenti — si sta verificando un'immagine distorta. E le aree dietro un login richiedono considerazioni a parte, prima ancora che un servizio esterno possa catturarle.

Perché la verifica resti radicata nel team, aiuta un rapporto sobrio con i suoi risultati. Vale la pena tirare le somme di tanto in tanto: quanti scostamenti segnalati erano regressioni vere, quanti falsi allarmi, quante modifiche volute? Se il rapporto pende verso i falsi allarmi, non è un motivo per spegnere tutto, ma un mandato di lavoro sull'ambiente di verifica. E se il confronto per mesi semplicemente non trova nulla, un team può anche abbassare la frequenza delle verifiche — disciplina nei test non significa espansione massima, ma adeguatezza.

Un aspetto sottovalutato è lo storico. Se una regressione emerge solo dopo giorni, aiuta lo sguardo all'indietro: quando la pagina aveva l'ultima volta un aspetto corretto, quale intervallo di tempo entra in considerazione come causa? ScanU conserva le cronologie, a seconda del livello di prezzo, tra tre e 90 giorni. Anche questo rientra nella pianificazione — uno storico di tre giorni si esaurisce in fretta durante un fine settimana lungo, mentre 90 giorni rispondono anche alla domanda se un problema esistesse già prima dell'ultima release trimestrale.

Per cominciare, molto parla a favore dell'inizio in piccolo: un progetto, una manciata di pagine, un'esecuzione settimanale più una per release. Se la fiducia negli allarmi cresce, segue l'integrazione più stretta con la pipeline. I dettagli sul modo di lavorare stanno nella documentazione di ScanU; una panoramica in italiano la offre la pagina del prodotto in italiano.

Resta la domanda di fondo: lo sforzo vale la pena? La risposta dipende meno dalla dimensione del team che dalla frequenza delle modifiche. Chi fa deploy ogni settimana produce ogni settimana occasioni per rotture silenziose del layout — e senza una verifica sistematica le scopre solo quando le utenti e gli utenti le hanno viste da un pezzo. La pipeline CI ha insegnato alla quotidianità dello sviluppo a catturare gli errori di logica prima della pubblicazione. Ci sono pochi motivi per negare la stessa protezione al livello più visibile di un sito web.