Cos'è il cross browser testing? Tre motori, non venti browser

Il cross browser testing consiste nel verificare che il tuo sito funzioni nei browser che i tuoi visitatori usano davvero, e non in quello che hai sulla scrivania. È una definizione poco spettacolare e completa, e quasi ogni articolo sull’argomento ti passa subito dopo una tabella con trenta combinazioni di browser e versione, ed è lì che la pratica comincia ad andare storta.

Parti invece dai motori. Quelli che contano sono tre: Blink, cioè Chrome, Edge, Opera, Brave e gran parte del resto; WebKit, cioè Safari ovunque e qualsiasi browser su iOS quale che sia il nome che porta; e Gecko, cioè Firefox. Che Chrome ed Edge non vadano d’accordo sul tuo layout è raro, perché sono lo stesso motore di rendering con una scocca diversa intorno. Che non vadano d’accordo Chrome e Safari è normale.

Testare trenta browser è per lo più testare Blink trenta volte.

Che cosa cambia davvero oggi

L’epoca dei prefissi dei produttori è finita, e le differenze rimaste sono di altro genere. Quattro categorie le coprono quasi tutte.

• Codec e media. La categoria più costosa, perché fallisce del tutto invece che sul piano estetico. Un video che il browser non sa decodificare non è un video peggiore; è un messaggio di errore.
• API che un motore non ha rilasciato. La feature detection è la risposta, e il modo in cui si rompe è una funzione che silenziosamente non fa nulla, invece di una pagina che si vede male.
• Casi limite di layout. Meno di una volta, ma quelli rimasti stanno di solito nelle parti più nuove della specifica, esattamente dove si va a prendere la novità.
• Cadenza dei rilasci. Il motore di Safari si aggiorna insieme al sistema operativo, quindi “l’ultimo Safari” è un’affermazione su quanto di recente qualcuno ha aggiornato il proprio Mac o il proprio telefono.

Vale la pena dare un nome alle categorie perché richiedono risposte diverse. I codec richiedono un ripiego servito nella pagina. Le API mancanti richiedono la detection. Il layout richiede che tu lo guardi. La cadenza richiede le tue analytics.

Un esempio concreto, ed era il nostro

La nostra estensione registra video in VP9 dentro un contenitore WebM. Safari non ha un decoder VP9. La pagina di condivisione passava al browser un’unica sorgente costruita a partire dal tipo del file salvato, e un elemento video HTML a cui dai una sola sorgente che non sa riprodurre non si degrada: fallisce.

Così per un po’, un link mandato a qualcuno su Mac gli mostrava la parola Error. L’intera promessa del prodotto è un link che un’altra persona possa aprire, e per un motore quella promessa era rotta.

Tre cose sul modo in cui la cosa è passata inosservata sono tipiche della categoria, ed è per questo che vale la pena scriverla invece di correggerla in silenzio.

Quello che avevamo

Test automatici, tutti verdi, tutti eseguiti in Chrome. Niente ha registrato un errore, perché dal punto di vista del server non era fallito nulla: un file è stato servito, e il browser non ha potuto usarlo

Quello che l'avrebbe intercettato

Aprire una registrazione condivisa in Safari, una volta. Nessuno strumento necessario, e nessuna suite avrebbe dovuto esistere

A scoprirlo è stato il destinatario. Chi aveva mandato il link non l’ha mai saputo, perché niente ti dice che la pagina che hai condiviso non ha funzionato per la persona con cui l’hai condivisa. È la proprietà che definisce i guasti tra motori diversi: da dove sei tu sono invisibili.

La soluzione è stata codificare una copia H.264 accanto a ogni caricamento e offrire entrambe le sorgenti, e poi registrare direttamente in MP4 dove il browser lo consente.

Da dove partire, che non è una matrice

Due dati decidono il tuo elenco, e nessuno dei due è un’ipotesi.

Le tue analytics. Non la quota di mercato mondiale. I browser che usano i tuoi visitatori, nei tuoi paesi, sulle tue pagine. Uno strumento B2B in Germania e un sito consumer in Brasile danno risposte diverse, ed entrambe differiscono dai numeri mondiali che cita ogni articolo di confronto.

Il tuo error tracking. Gli errori raggruppati per browser ti diranno dove qualcosa si sta già rompendo, il che è una priorità migliore di qualsiasi ipotesi su dove potrebbe rompersi.

Da lì una forma che funziona: uno smoke test su tutti e tre i motori, e test approfonditi sui tuoi due principali. Lo smoke test è la stessa idea che altrove - la pagina si carica, si riesce ad accedere, si riesce a completare l’unico flusso che conta - e farlo su Safari e Firefox intercetta in pochi minuti tutta la categoria dei codec e delle API mancanti.

Dichiara la matrice ad alta voce nel tuo piano di test, compreso ciò che è fuori ambito. “Non testiamo Firefox su Android” è una decisione quando è scritto e un incidente quando non lo è.

Cosa coprono gli strumenti e cosa no

I servizi commerciali ti affittano macchine con i browser installati, il che risolve il problema vero: non puoi far girare Safari su Linux né tenere ogni versione di iOS sulla scrivania. Vale la spesa quando serve.

Quello che non risolvono è sapere cosa guardare. Uno screenshot della tua pagina in dodici browser sono dodici screenshot che qualcuno deve confrontare, ed è il problema che i test di regressione visiva esistono per automatizzare - e quella suite ha lo stesso punto cieco, perché controlla solo i browser di cui le hai parlato.

L’automazione di qualunque tipo se la cava male anche con il guasto che qui conta di più. Un video che non parte, un font che non si carica, un campo data che su un motore viene reso come una casella di testo: tutto questo supera ogni asserzione sul DOM, perché il DOM sta bene. È il rendering che non va.

Le segnalazioni sono l’altra metà

Per quanto buona sia la matrice, qualche motore, qualche versione, qualche dispositivo che non hai testato produrrà un bug per una persona vera. La domanda è se lo vieni a sapere.

È l’argomento per rendere facile segnalare da dove ci si trova, e per far sì che la segnalazione porti con sé browser e versione senza chiedere a chi segnala di conoscerli. “Sul mio telefono non funziona” costa un giorno. “Safari 26.1 su iOS, nella registrazione l’area video è vuota, la console dice che la sorgente non è supportata” costa un pomeriggio, e la differenza sta interamente in quello che la segnalazione portava, non in quello che sapeva chi l’ha scritta.

Che è il limite onesto di questo articolo: il cross browser testing restringe il divario, e le segnalazioni che arrivano dai browser che non hai coperto sono il modo in cui scopri dove il divario resta. Nessuno dei due sostituisce l’altro, e una squadra che ne fa solo uno ha metà del quadro.