Checklist QA visiva: cosa verificare prima di ogni release

Rilasciare una release senza QA visiva è un azzardo. I test funzionali confermano che le funzionalità operano, ma non confermano che l'interfaccia appaia corretta. Un bottone può superare ogni test di integrazione e comunque sovrapporsi a un campo del form su Safari mobile. Un titolo può renderizzarsi perfettamente in inglese e far esplodere il suo contenitore quando tradotto in tedesco.

Questa checklist copre le verifiche visive che ogni team web dovrebbe eseguire prima che una release raggiunga la produzione. Usala così com'è o adattala al tuo stack tecnologico e al tuo pubblico specifico.

Perché una checklist visiva è importante

I bug visivi sono particolarmente dannosi perché sono immediatamente visibili agli utenti. Un elemento disallineato o un layout rotto erode la fiducia in modi che una risposta API lenta non può. Eppure, la QA visiva è spesso la parte più improvvisata del processo di release — eseguita in modo incoerente, da persone diverse, senza criteri condivisi.

Una checklist scritta risolve questo problema rendendo la QA visiva ripetibile e misurabile. Tutti nel team sanno cosa significa «verificato visivamente», e nessuna categoria di verifiche viene saltata perché qualcuno l'ha dimenticata.

Layout e spaziatura

I problemi di layout sono le regressioni visive più comuni. Verificali sistematicamente:

La struttura della pagina è intatta — header, contenuto principale, sidebar (se presente) e footer si renderizzano nell'ordine corretto con la spaziatura prevista.
I layout grid e flexbox si redistribuiscono correttamente — verifica alle larghezze desktop, tablet e mobile. Cerca il wrapping inaspettato delle colonne o elementi che debordano dai contenitori.
La spaziatura tra le sezioni è coerente — margini e padding corrispondono alle specifiche di design. Fai attenzione a sezioni troppo vicine o troppo distanti.
Nessun elemento sovrapposto — verifica che gli elementi posizionati in modo assoluto (tooltip, dropdown, modal) non sovrappongano il contenuto o si estendano oltre il viewport.
Gli elementi sticky e fixed si comportano correttamente — gli header sticky e i footer fixed devono rimanere in posizione durante lo scroll senza coprire il contenuto dietro di loro.

Per la verifica automatizzata del layout su tutti i breakpoint, consulta la nostra guida sui workflow di test cross-browser.

Tipografia e contenuto

I problemi di rendering del testo sono sottili ma influenzano la leggibilità e la professionalità:

I titoli seguono la gerarchia corretta — le dimensioni e i pesi di H1, H2, H3 corrispondono al design system.
Il testo del corpo è leggibile — dimensione del font, altezza della riga e contrasto soddisfano gli standard di accessibilità. Testa con contenuto reale, non con testo segnaposto.
Nessun troncamento o overflow del testo — titoli lunghi, stringhe tradotte e contenuto dinamico rientrano nei loro contenitori. Verifica specialmente con lingue più lunghe come il tedesco.
I link sono visivamente distinguibili — sottolineatura, colore o altro stile rende i link identificabili senza affidarsi solo al colore.
I blocchi di codice e il testo preformattato si renderizzano correttamente — i font monospace si caricano, la colorazione sintattica funziona e lo scroll orizzontale appare per le righe lunghe.
Le liste si renderizzano con i marker corretti — le liste ordinate mostrano numeri, le non ordinate mostrano punti elenco, e la nidificazione è visivamente chiara.

Comportamento responsive

I bug responsive rappresentano una quota sproporzionata dei problemi visivi segnalati dagli utenti:

Layout mobile (larghezza 375px) — verifica l'intera pagina alla larghezza mobile tipica. La navigazione si comprime nel menu hamburger, le immagini si ridimensionano e il contenuto si impila verticalmente.
Layout tablet (larghezza 768px) — qui si nascondono la maggior parte dei bug responsive. I layout a due colonne dovrebbero transitare in modo pulito, e i target touch dovrebbero avere dimensioni adeguate.
Layout desktop (larghezza 1440px) — l'esperienza desktop principale. I layout multicolonna si visualizzano correttamente e le larghezze massime del contenuto sono rispettate.
Desktop largo (larghezza 1920px+) — il contenuto non dovrebbe allargarsi per riempire schermi ultra-wide. Verifica che le larghezze massime e il centraggio funzionino correttamente.
Cambi di orientamento — su mobile e tablet, il passaggio tra ritratto e paesaggio non dovrebbe rompere il layout.
Comportamento dello zoom — lo zoom del browser al 150% e 200% non dovrebbe causare sovrapposizioni o contenuto nascosto.

Rendering cross-browser

I diversi motori di browser interpretano il CSS in modo diverso. Verifica almeno queste combinazioni:

Chrome desktop — il tuo rendering di riferimento. La maggior parte degli utenti vedrà questa versione.
Firefox desktop — individua problemi specifici di Gecko con gap flexbox, metriche dei font e proprietà personalizzate.
Safari desktop — WebKit ha un comportamento unico per backdrop-filter, position-sticky e flex-wrap.
Safari mobile (iOS) — tutti i browser iOS usano WebKit. La gestione del viewport, i safe-area inset e il comportamento dello scroll differiscono dal desktop.
Chrome mobile (Android) — verifica i target touch, il comportamento del meta viewport e lo styling specifico per mobile.

Non è necessario verificare ogni browser per ogni pagina. Dai priorità in base ai dati di traffico: copri le combinazioni che rappresentano il 90% del tuo pubblico. Consulta la nostra guida ai test di regressione visiva per saperne di più sulla costruzione di una matrice browser.

Stati interattivi

Gli elementi interattivi hanno molteplici stati visivi. Ognuno necessita di verifica:

Bottoni — gli stati default, hover, focus, attivo, disabilitato e di caricamento si renderizzano tutti correttamente e sono visivamente distinti.
Campi del form — stati vuoto, con focus, compilato, errore e disabilitato. Verifica che i messaggi di errore appaiano nella posizione corretta e non spostino il layout.
Navigazione — indicatore della pagina attiva, effetti hover sui link, menu dropdown che si aprono e chiudono nella posizione corretta.
Modal e dialog — si aprono fluidamente, si centrano correttamente su tutte le dimensioni dello schermo e mostrano uno sfondo visibile. Il pulsante di chiusura è accessibile.
Tooltip e popover — appaiono nella posizione corretta rispetto al loro trigger. Non vengono tagliati da contenitori overflow-hidden o dal bordo del viewport.
Stati di caricamento — gli skeleton screen, spinner e barre di avanzamento si visualizzano correttamente durante il caricamento dei dati.

Immagini e media

I media visivi richiedono il proprio set di verifiche:

Le immagini si caricano e si visualizzano — nessuna icona di immagine rotta. Tutte le immagini hanno un testo alt appropriato per l'accessibilità.
Le immagini sono dimensionate correttamente — nessuna distorsione o ritaglio inaspettato. Le proporzioni sono mantenute.
Le immagini responsive servono le dimensioni appropriate — i dispositivi mobile non scaricano immagini di dimensione desktop.
Gli embed video funzionano — i pulsanti play si visualizzano, le proporzioni sono corrette e gli embed non debordano dai contenitori.
Le icone si renderizzano correttamente — le icone SVG si visualizzano alla dimensione e colore corretti. I font di icone si caricano senza mostrare caratteri di fallback.

Accessibilità e colore

QA visiva e accessibilità si sovrappongono significativamente:

Il contrasto dei colori soddisfa WCAG AA — testo ed elementi interattivi hanno contrasto sufficiente con i loro sfondi. Verifica sia il tema chiaro che quello scuro se applicabile.
Gli indicatori di focus sono visibili — la navigazione da tastiera dovrebbe mostrare un anello di focus chiaro su tutti gli elementi interattivi.
Il dark mode si renderizza correttamente — se la tua applicazione supporta il dark mode, verifica che tutti i componenti, immagini e testi siano leggibili in entrambi i temi.
Nessuna informazione trasmessa solo tramite colore — gli stati di errore, indicatori di stato e campi obbligatori usano icone o testo in aggiunta al colore.

Verifiche visive legate alle prestazioni

I problemi di prestazioni possono manifestarsi come problemi visivi:

Nessun layout shift durante il caricamento — il contenuto non salta mentre si caricano font, immagini o script. Questo è misurato dal Cumulative Layout Shift (CLS).
I web font si caricano prima del rendering — nessun flash di testo non stilizzato (FOUT) o testo invisibile (FOIT) durante il caricamento della pagina.
Il contenuto above-the-fold si renderizza rapidamente — la parte visibile della pagina dovrebbe apparire entro 1–2 secondi con una buona connessione.

Workflow di verifica pre-release

Usa questo workflow per eseguire la checklist in modo coerente:

Deploy in staging — verifica in un ambiente che rispecchia la produzione il più fedelmente possibile.
Esegui test di screenshot automatizzati — cattura baseline nella tua matrice browser e dispositivi. Consulta la nostra guida all'automazione CI/CD per le istruzioni di configurazione.
Rivedi i diff automatizzati — classifica ogni diff come intenzionale, regressione o rumore.
Esegui verifiche manuali mirate — i test automatizzati coprono il rendering statico. Verifica manualmente gli stati interattivi, le animazioni e i casi limite.
Documenta i risultati — registra quali verifiche sono passate, quali sono fallite e cosa è stato corretto. Questo crea una traccia di audit per i futuri release.
Approva o blocca — se tutte le verifiche passano, approva il release. Se permangono bug visivi critici, blocca fino alla loro risoluzione.

Adattare la checklist al tuo team

Questa checklist è volutamente esaustiva. Per il tuo team, personalizzala in base a:

Il tuo stack tecnologico — se non supporti il dark mode, rimuovi quelle verifiche. Se usi un design system, aggiungi verifiche a livello di componenti.
Il tuo pubblico — se il 95% del tuo traffico viene da Chrome, riduci l'ambito cross-browser e aumenta i test mobile.
La tua tolleranza al rischio — le applicazioni critiche per il fatturato necessitano di verifiche più rigorose. Gli strumenti interni possono usare un processo più leggero.

La chiave è la coerenza. Una checklist più breve eseguita a ogni release ha più valore di una esaustiva che viene saltata sotto pressione delle scadenze.

Continua con ScanU

I test di screenshot automatizzati gestiscono le parti più dispendiose in termini di tempo di questa checklist: verifica del layout, rendering cross-browser e controlli ai breakpoint responsive. ScanU cattura screenshot su tutti i browser e dispositivi così il tuo team può concentrarsi sugli stati interattivi e i casi limite. Esplora le opzioni di piano su Pricing, scopri la piattaforma su Features e consulta le risposte alle domande frequenti nelle FAQ.