Screenshot diff nella pratica: baseline, soglie e falsi allarmi

Sulla carta un test visivo è il tipo di test più semplice del mondo: due immagini, un confronto, fatto. Chi lo prova si accorge in fretta che tra «confrontare due immagini» e «sapere in modo affidabile se il sito è rotto» sta un intero mestiere. Questo mestiere ha tre concetti chiave — baseline, soglia, falso allarme — e chi li capisce capisce anche perché i test visivi in alcuni team siano irrinunciabili e in altri vengano rispenti dopo tre settimane.

All'inizio sta la baseline: un insieme di screenshot che fissa lo stato voluto della pagina. Importante è che cosa la baseline significhi — e che cosa no. Non è una misura oggettiva di correttezza, ma un'istantanea che qualcuno ha dichiarato stato di riferimento. Un diff contro la baseline non dice perciò mai «la pagina è rotta», ma solo «la pagina è diversa dallo stato approvato». Se diverso significhi anche peggiore, nessun algoritmo può deciderlo.

Il confronto in sé lavora, nel principio di base, pixel per pixel: per ogni posizione dell'immagine viene rilevata la deviazione di colore tra baseline e screenshot attuale, e la somma delle deviazioni dà una misura del cambiamento. Questo principio di base è robusto e veloce — e ha una debolezza incorporata: tratta ogni deviazione allo stesso modo, che sia sparito il pulsante del carrello o che un carattere sia stato levigato in modo minimamente diverso.

Proprio da qui nasce il più grande problema pratico dei test visivi: il rumore. La levigatura dei caratteri varia a seconda del sistema e della passata di rendering. I bordi vengono disegnati ora un subpixel prima, ora dopo. Le immagini passano per compressioni che generano deviazioni minime di colore. Niente di tutto questo è una regressione — ma tutto questo genera differenze di pixel. Un confronto ingenuo, che dà l'allarme a ogni pixel divergente, segnala perciò praticamente sempre qualcosa.

La seconda fonte di rumore sono i contenuti stessi. Un orario visualizzato cambia a ogni caricamento. Un carosello non sta mai due volte sulla stessa immagine. Gli spazi pubblicitari servono soggetti che cambiano, le barre delle raccomandazioni prodotti che cambiano, un banner dei cookie compare ora prima, ora dopo lo screenshot. Chi fotografa un sito di notizie di mattina e a mezzogiorno ottiene due immagini completamente diverse — ed entrambe sono corrette.

Lo strumento contro il rumore si chiama soglia: solo quando la deviazione supera una misura definita, il confronto vale come anomalo. Con questo comincia un bilanciamento che non si può ottimizzare via. Una soglia severa segnala ogni piccolezza e genera stanchezza da allarmi; una generosa si lascia sfuggire errori veri — un prezzo scivolato fuori posto può restare sotto la soglia, se riguarda solo pochi pixel. Il valore giusto in assoluto non esiste; esiste solo il valore adatto a una determinata pagina e a un determinato team.

Per la definizione c'è comunque un procedimento concreto: misurare il proprio rumore. Si fotografa la stessa pagina due volte, una immediatamente dopo l'altra, senza cambiare nulla, e si confrontano le due riprese tra loro. Ogni differenza che questo confronto segnala è per definizione rumore — levigatura dei caratteri, compressione, tempistica. Chi ripete questa misurazione per le pagine e le combinazioni di dispositivi più importanti conosce il livello di fondo del proprio ambiente di verifica e può fissare la soglia appena sopra, invece di tirarla a indovinare. Il procedimento fornisce, per inciso, un segnale d'allerta precoce: se il livello di fondo così misurato sale in seguito in modo percepibile, l'ambiente è diventato più inquieto — e conviene andare a fondo della causa, prima che gli allarmi perdano la loro credibilità.

La stanchezza da allarmi non è, in tutto ciò, un tema secondario e morbido, ma il colpo mortale più frequente per i test visivi. Un sistema di verifica che scatta tre volte al giorno senza motivo, dopo due settimane non lo prenderà più sul serio nessuno — e allora l'allarme che segnala davvero una pagina di pagamento rotta è solo uno dei tanti che si liquidano per abitudine con un clic. Un test visivo di cui il team non si fida è peggio di nessun test, perché simula una sicurezza che non fornisce.

Perciò conviene lavorare sulle condizioni di contorno, prima di girare la manopola della soglia. Si sono affermati i dati di esempio fissi al posto dei dati live negli ambienti di verifica, le animazioni disattivate, gli stati di partenza coerenti — per esempio un dialogo dei cookie già risposto —, tempi di attesa sufficienti fino al caricamento completo e dimensioni di finestra identiche per ogni esecuzione. Le indicazioni specifiche dello strumento al riguardo appartengono a ogni introduzione; per il servizio qui considerato le raccoglie la documentazione di ScanU sul sito del fornitore. Ognuna di queste misure rimuove una fonte di rumore — e rende la soglia meno importante, perché allarmi veri e falsi si separano più nettamente.

Per le fonti di rumore ostinate — lo spazio pubblicitario, la data in tempo reale, l'area con i commenti degli utenti — alcuni strumenti offrono inoltre la possibilità di escludere aree dell'immagine dal confronto. È efficace, ma ha un prezzo che bisogna conoscere: un'area esclusa è un punto cieco. Proprio lì, in futuro, può succedere di tutto senza che nessuno lo segnali. Il bilanciamento non è quindi «escludere o sopportare falsi allarmi», ma: quest'area è abbastanza importante da voler sapere dei suoi cambiamenti? Per un banner pubblicitario a rotazione la risposta è di solito no, per una colonna dei prezzi sempre sì. Le aree di esclusione definite vanno inoltre documentate e riviste di tanto in tanto — altrimenti si accumulano macchie silenziose, e la verifica copre meno di quanto tutte le persone coinvolte credano.

Una decisione affine riguarda l'inquadratura. Una ripresa dell'area visibile della finestra verifica ciò che visitatrici e visitatori vedono senza scorrere — veloce e parsimoniosa, ma cieca per tutto ciò che sta sotto. Una ripresa dell'intera lunghezza della pagina cattura tutto, ma in compenso reagisce in modo più sensibile: se un elemento nella parte alta cresce di venti pixel, tutto il resto della pagina slitta verso il basso e il confronto marca superfici che nel contenuto non sono cambiate affatto. Per pagine compatte e stabili l'intera lunghezza è di solito la scelta giusta; per pagine molto lunghe e vivaci può essere più saggio verificare in modo mirato le sezioni critiche. Anche questa non è una minuzia tecnica, ma una decisione su quali errori si vogliono vedere — e quali si mettono in conto consapevolmente.

Il secondo grande tema di metodo è la cura della baseline nel tempo. I siti web cambiano intenzionalmente: redesign, nuovi contenuti, campagne stagionali. Dopo ogni modifica voluta la baseline va aggiornata, altrimenti ogni esecuzione futura segnalerà la stessa differenza attesa. Il pericolo sta nella routine: chi concepisce gli aggiornamenti della baseline come un clic fastidioso prima o poi aggiorna per riflesso — e così, presto o tardi, dichiara nuovo stato di riferimento un errore vero. Da quel momento ogni esecuzione verde conferma la versione rotta.

Contro questo aiuta un principio semplice: gli aggiornamenti della baseline sono approvazioni e meritano la stessa cura di una code review. Qualcuno guarda la differenza, qualcuno decide consapevolmente, qualcuno può ricostruire la decisione in seguito. Gli strumenti supportano tutto ciò con qualità diverse; ScanU, per esempio, affianca baseline e stato attuale e genera report condivisibili, così che anche i non tecnici possano giudicare uno scostamento — quali funzioni di confronto siano disponibili nel dettaglio lo mostra la pagina delle funzioni del servizio. Il principio è però indipendente dallo strumento: l'approvazione di una baseline è una decisione di contenuto, non tecnica.

Una dimensione viene volentieri taciuta nei testi introduttivi: il tempo. Le regressioni non saltano sempre all'occhio subito. Allora comincia la ricerca: da quando è così? Quale modifica entra in considerazione? Qui paga lo storico — la possibilità di consultare stati più vecchi e circoscrivere il momento del cambiamento. Con ScanU la conservazione dipende dal livello di prezzo, dai tre giorni del livello gratuito ai 90 del più grande. Per il metodo questo significa: chi verifica solo di rado ha bisogno di cronologie che risalgono più indietro; chi verifica ogni giorno circoscrive bene gli intervalli anche con uno storico corto.

Resta il limite più fondamentale del procedimento: la lacuna semantica. Un confronto di pixel non sa che cosa confronta. Due pixel di spostamento su un pulsante di pagamento possono essere il sintomo di una griglia di layout rotta; venti pixel di spostamento in un piè di pagina sono per lo più irrilevanti. Il diff non conosce la differenza — misura superficie, non significato. L'ultima parola spetta perciò sempre a un essere umano che conosce la pagina e sa valutare quale scostamento abbia rilevanza per il business.

E infine ciò che uno screenshot diff per principio non può vedere: tutto ciò che non si deposita nell'immagine. Una pagina può apparire impeccabile e mostrare comunque dati sbagliati, un modulo può essere renderizzato alla perfezione e fallire all'invio, un server può servire correttamente contenuti superati. I test visivi sono uno strato nel tessuto dei test — accanto ai test funzionali, al monitoraggio e all'occasionale curiosità umana —, non il suo sostituto.

Come i singoli mattoni si compongano lo mostra un esempio giocato fino in fondo — non un caso di studio, ma una sequenza tipica. Settimana uno: un team crea le baseline per dieci pagine e la mattina dopo si trova davanti dozzine di scostamenti segnalati. La revisione mostra che quasi tutti risalgono a un carosello e al dialogo dei cookie. Settimana due: calmare l'ambiente di verifica — dati di esempio fissi, stato di partenza definito, animazioni spente; le esecuzioni diventano silenziose. Settimana tre: un aggiornamento delle dipendenze sposta in uno dei tre motori le spaziature della navigazione — il primo ritrovamento vero, che prima nessuno avrebbe notato, perché nella quotidianità nessuno apre per routine tutti i motori. Settimana quattro: un redesign della home page genera differenze attese su tutte le viste; dopo la revisione la baseline viene aggiornata consapevolmente. Niente in questa sequenza è spettacolare — ed è esattamente questo il punto. Il valore non nasce da ritrovamenti drammatici, ma dal passaggio da «probabilmente sta tutto bene» a un verificato «dall'ultimo stato approvato non è cambiato nulla di indesiderato». Come si svolga tecnicamente un singolo ciclo di verifica lo mostra la presentazione passo dopo passo di ScanU.

Chi vuole cominciare va sul sicuro con una sequenza sobria: prima definire un piccolo set di pagine importanti, poi calmare l'ambiente di verifica, poi generare le baseline e concordare nel team chi giudica e approva gli scostamenti — e solo dopo negoziare soglie e frequenza di verifica. Un ingresso nel tema in italiano lo offre la panoramica di ScanU in italiano; il metodo che ci sta dietro vale per ogni strumento di questa categoria. Perché questa è, alla fine, l'intuizione centrale: il valore dei test visivi non nasce nell'algoritmo che confronta pixel, ma nel procedimento intorno — riferimenti puliti, soglie oneste e persone che giudicano le differenze invece di liquidarle con un clic.