Rilasciate l’UI che avete progettato — non quella sfuggita alla CI

I test funzionali rispondono bene a una domanda: «il bottone fa la cosa giusta quando viene cliccato?». Su tutto ciò che succede prima del click restano muti — se il bottone ha il colore giusto, la dimensione giusta, la posizione giusta, se resta leggibile su uno schermo da 360 pixel o se è persino visibile dopo l’ultimo refactoring CSS. È in questo spazio che vivono la maggior parte degli incidenti del giorno di rilascio.

Le regressioni reali che vediamo, e per intercettare le quali ScanU è stato costruito, si raggruppano attorno a una manciata di cause ricorrenti:

• Un refactoring CSS collassa il gap di un container flex su un singolo breakpoint. Su desktop il layout sembra identico; su un tablet da 768 pixel due card ora si sovrappongono.
• Un bump dei design token sposta ogni valore di spaziatura di due pixel. Nulla fallisce; una dozzina di composizioni ben bilanciate smette in silenzio di esserlo.
• Un widget di terze parti — un cookie banner, una live chat, uno slot pubblicitario — rilascia un aggiornamento silenzioso che sposta il first paint. I Core Web Vitals regrediscono dall’oggi al domani, senza alcun cambio di codice dalla vostra parte.
• Un upgrade del framework cambia lo stack di font-feature di default. La copy si riflueisce di mezza riga sulle pagine long-form. I CTA dell’hero finiscono improvvisamente sotto la fold.
• Il rollout di un feature flag riordina il DOM. Su Safari lo stacking context di una modale cambia e il bottone di chiusura diventa non cliccabile. Su Chrome tutto sembra normale.

Nessuna di queste modifiche fa fallire un’assertion. Tutte rompono l’esperienza di un utente. Il compito di ScanU è rendere questa seconda classe di rotture tanto facile da vedere, revisionare e bloccare quanto un test unitario rosso. Quando il diff compare sulla pull request, una designer può intervenire come un reviewer interviene sulla firma di una funzione — prima del merge, non dopo la produzione.

Questo passaggio — da «speriamo che qualcuno lo noti in staging» a «revisioniamo un cambiamento visivo come revisioniamo codice» — è il valore centrale di uno strumento di test di regressione visiva in una pipeline di rilascio moderna.

Ogni esecuzione è una pipeline in tre passi. Prima ScanU naviga in ciascun motore fino alla pagina o al componente in test, attende un insieme configurato di segnali di readiness — font caricati, immagini decodificate, rete silenziosa, un attributo data-ready o una probe JavaScript personalizzata — e fissa tutte le animazioni CSS al loro frame finale. Poi cattura la pagina su ogni viewport configurato nella stessa esecuzione, con scroll-stitching sulle pagine lunghe così da ottenere l’artefatto completo e non solo la porzione visibile. Infine confronta la cattura con la baseline accettata e produce un risultato per ciascuna coppia (browser, viewport): identica, entro tolleranza, o significativamente diversa.

Il confronto stesso non è un diff di pixel ingenuo. ScanU applica un modello percettivo che comprende anti-aliasing, rendering sub-pixel e variazioni di spazio colore, così una peculiarità di kerning su WebKit non passa per bug. Supporta inoltre maschere esplicite per le zone che cambiano a ogni caricamento — dati in tempo reale, timestamp relativi, contenuti randomizzati, carousel — in modo che quelle aree contribuiscano zero rumore al diff.

Quando compare un vero cambiamento, la piattaforma mostra tre pannelli sincronizzati: la baseline, la cattura corrente e un overlay di diff che evidenzia esattamente ciò che si è spostato. Per ogni modifica viene registrata una decisione revisionabile — accettare, rifiutare o aggiornare la baseline — e questa decisione entra nella storia del progetto. Nessuna deriva silenziosa e nessuna accettazione automatica: la baseline si muove solo quando una persona autorizzata lo dichiara.

La stessa pipeline può essere guidata da tre punti di ingresso: contro URL in produzione (production, staging, preview di PR), contro un sito statico o un bundle di asset buildato, o contro preview di componenti in una sandbox in stile Storybook. La maggior parte dei team usa la prima via per i release gate, la seconda per gli artefatti di deployment e la terza per il lavoro sul design system — tutte e tre alimentano lo stesso store di baseline.

Qualunque sia la forma del team, ScanU viene tipicamente adottato per una di cinque ragioni: un recente incidente in produzione che una regressione visiva avrebbe intercettato; una migrazione di design system il cui blast radius è impossibile da revisionare a mano; un workflow CI/CD che ha bisogno di un release gate più ricco di «test passati»; un deliverable orientato al cliente che richiede prove prima/dopo; o una postura di compliance che predilige strumenti di test hosted in UE. Una integrazione CI/CD condivisa sta dietro a tutte e cinque — la stessa pipeline fa il lavoro sia che venga attivata da una PR, da un merge o da una pianificazione notturna.

ScanU è costruito e ospitato nell’Unione Europea, con storage ed elaborazione su infrastruttura operata in UE. Per i team con impegni di residenza dei dati — settori regolati, acquirenti pubblici, clienti B2B sensibili alla privacy — spesso è un requisito di procurement, non una preferenza. ScanU è progettato per soddisfarlo senza compromessi sulle capacità di prodotto.

Da questa postura discendono alcune scelte di design deliberate:

• Minimizzazione dei dati. La piattaforma archivia gli screenshot e i metadati necessari al diff; non assorbe sorgente di pagina, cookie o body di richieste che non contribuiscono al diff.
• Mascheramento di default nei contesti sensibili. I campi noti per contenere dati personali — header di account, indirizzi email, numeri d’ordine — possono essere dichiarati come regioni mascherate, così l’immagine catturata è già redatta al momento della scrittura su storage.
• Controllo degli accessi. Chi può vedere un diff è un permesso di prima classe. Revisori, contributor e auditor esterni ricevono ruoli espliciti, e ogni aggiornamento di baseline è tracciato con l’utente che lo ha autorizzato.
• Trasparenza sui sub-processor. L’elenco dei sub-processor è pubblicato e versionato. Nessuna pipeline di analytics nascosta vede i vostri screenshot.
• Retention sotto il vostro controllo. Baseline e artefatti di diff vengono conservati per l’orizzonte che configurate; le esecuzioni vecchie scadono automaticamente invece di accumularsi in silenzio.

Per la postura privacy completa — sub-processor, hosting regionale, DPA, finestre di retention — consultate la documentazione GDPR e trattamento dati. Per la maggior parte dei team conta la versione sintetica: i vostri screenshot restano in UE, e la piattaforma è ingegnerizzata per tenerli lì.

I bug visivi si raccolgono attorno a una manciata di pattern ricorrenti. Ciascuno sembra banale in isolamento; ciascuno può finire in produzione senza un solo test rosso. Tutti emergono come diff alla prossima esecuzione di ScanU, prima che la PR venga mergiata.

• Spostamenti di spaziatura. Un’utility di gap passa da 16 a 20 pixel; una griglia di card che respirava ordinatamente appare improvvisamente stretta su mobile. L’HTML è invariato; il layout no.
• Layout rotti dopo il deployment. Un upgrade della pipeline di build elimina un plugin PostCSS che era responsabile dell’autoprefisso di backdrop-filter. Su Safari una barra di navigazione si rende all’improvviso opaca, dove prima sfumava.
• Regressioni CSS da shift di specificità. Un cambio di ordine tra classi Tailwind, un nuovo utility layer o una cascata refactorata modificano sottilmente quale regola vince — un titolo perde il suo colore d’accento su qualche pagina.
• Breakpoint responsive che falliscono. Una nuova voce di nav trabocca sul breakpoint tablet e va a capo su una seconda riga, spingendo l’hero sotto la fold su iPad e sui grandi Android.
• Differenze di rendering tra browser. Un design che si affida a text-wrap: balance è pulito su Chrome ma resta non bilanciato su motori che non lo hanno ancora rilasciato. Senza un controllo cross-browser è invisibile sulla macchina dello sviluppatore.
• Deriva di font e tipografia. Un provider di font cambia un subset, i pesi si spostano di cento grammi, e ogni paragrafo di un sito marketing riflueisce di un quarto di riga. La densità del testo cambia; nessun diff nel repository lo spiega.
• Regressioni di widget di terze parti. Un vendor di consent banner rilascia un update che rende invisibile il pulsante di accept sui temi scuri. Il tasso di conversione crolla; i vostri test passano.
• Deriva del design system. Un componente bottone cambia l’offset del suo focus ring. Venti consumatori dipendono da quel componente. Venti pagine ora appaiono sottilmente diverse. Nessuno revisiona venti pagine a mano.
• Bug visivi che sfuggono in produzione. Qualunque dei precedenti, moltiplicato per le route e i breakpoint che in una settimana data nessuno apre, sui browser che nessuno del team usa quotidianamente.

La panoramica delle funzionalità approfondisce le primitive di rilevamento — tolleranze percettive, regioni mascherate, cattura con scroll, branching delle baseline — e mostra come ciascuna si mappi a una delle categorie sopra. Per la maggior parte dei team la versione breve suona così: se cambia qualcosa visivamente, ScanU lo nota; se è atteso, lo accettate con un clic; se non lo è, lo avete intercettato prima di chiunque altro.