Test cross-browser ad alto impatto e minimo sforzo

I test cross-browser richiedono molto tempo e sono laboriosi. Tuttavia, gli sviluppatori sono pigri per natura: aderire al principio DRY, scrivere script per automatizzare cose che altrimenti dovremmo fare a mano, fare uso di librerie di terze parti; essere pigri è ciò che ci rende dei buoni sviluppatori .

L'approccio tradizionale al test cross-browser "correttamente" consiste nel testare tutti i principali browser utilizzati dal tuo pubblico, passando gradualmente ai browser più vecchi o più oscuri per dire che li hai testati. Oppure, se il tempo e le risorse sono brevi, testare un piccolo sottoinsieme di browser ad hoc e sperare che l'assenza di un bug ti dia fiducia nell'integrità dell'applicazione. Il primo approccio incarna lo sviluppo "buono" ma è inefficiente, mentre il secondo incarna la pigrizia ma è inaffidabile.

Ulteriori letture su SmashingMag:

• La transizione di Noè ai test di usabilità mobile
• Le basi dell'automazione dei test per app, giochi e Web mobile
• Come creare il tuo piano di test del sito Web front-end
• Dove sono i migliori laboratori di dispositivi aperti al mondo?

Nei prossimi quindici minuti, spero di risparmiarvi ore di fatica sprecata descrivendo una strategia di test che non solo sia meno laboriosa , ma più efficace nel catturare i bug. Voglio documentare una strategia di test realistica più pertinente e preziosa del semplice "testare TUTTE le cose!", attingendo alla mia esperienza come sviluppatore in test in BBC Visual Journalism.

Contesto

Per inciso, vale la pena sottolineare che facciamo molto di più che semplici test manuali nel nostro team. Il test cross-browser non sostituisce i test unitari (Jasmine/QUnit), i test funzionali (Cucumber) e, se del caso, i test di regressione visiva automatizzati (Wraith). In effetti, i test automatizzati sono più economici a lungo termine e sono essenziali quando l'applicazione raggiunge una certa dimensione.

Tuttavia, alcuni bug si manifestano solo in alcuni browser e l'automazione dei test non è ancora entrata in modo affidabile nel dominio dei test cross-browser. Come può un computer sapere che il tuo evento di scorrimento automatico ha appena oscurato metà del titolo quando viene visualizzato su un iPhone 4? Come fa a sapere che è un problema? Fino a quando l'intelligenza artificiale non raggiungerà un punto in cui i computer capiranno cosa hai costruito e apprezzeranno la narrativa e l'arte che stai tentando di dimostrare, ci sarà sempre bisogno di test manuali. Essendo qualcosa che deve essere eseguito manualmente, è nostro dovere rendere il processo di test cross-browser il più efficiente possibile.

Qual è il tuo obiettivo?

Prima di immergerti alla cieca nei test cross-browser, decidi cosa speri di ottenere da esso. I test cross-browser possono essere riassunti in due obiettivi principali:

1. Individuazione dei bug Ciò comporta il tentativo di interrompere l'applicazione per trovare i bug da correggere.
2. Sanity-checking Ciò implica la verifica che la maggior parte del tuo pubblico riceva l'esperienza prevista.

La prima cosa che voglio che tu tolga da questo articolo è che questi due obiettivi sono in conflitto l'uno con l'altro .

Da un lato, so di poter verificare l'esperienza di quasi il 50% del nostro pubblico nel Regno Unito semplicemente testando in Chrome (Desktop), Chrome (Android) e Safari (iOS 9). D'altra parte, se il mio obiettivo è trovare bug, allora vorrò lanciare la mia app web sui browser più problematici che dobbiamo supportare attivamente: nel nostro caso, IE8 e Android Browser 2 nativo.

Gli utenti di questi due browser costituiscono una percentuale in diminuzione del nostro pubblico (attualmente circa l'1,5%), il che rende i test in questi browser un cattivo uso del nostro tempo se il nostro obiettivo è il controllo di integrità. Ma sono ottimi browser da testare se vuoi vedere quanto può diventare maciullata la tua applicazione ben progettata quando viene lanciata su un motore di rendering oscuro.

Le strategie di test tradizionali comprensibilmente pongono maggiore enfasi sui test nei browser più diffusi. Tuttavia, un numero sproporzionato di bug esiste solo nei browser più oscuri, che con il modello di test tradizionale non verranno alla luce fino alla fine del test. Ti trovi quindi di fronte a un dilemma...

Cosa fai quando trovi un bug alla fine della fase di test della coda lunga?

1. Ignora il bug.
2. Risolvi il bug e spera di non aver rotto nulla.
3. Correggi il bug ed esegui nuovamente il test in tutti i browser precedentemente testati.

In un mondo ideale, l'ultima opzione è la migliore in quanto è l'unico modo per essere veramente sicuri che tutti i browser funzionino ancora come previsto. Tuttavia, è anche mostruosamente inefficiente ed è qualcosa che probabilmente dovresti fare più volte. È l'equivalente del test manuale di una sorta di bolla.

Ci troviamo quindi in una situazione Catch-22: per la massima efficienza, vogliamo correggere tutti i bug prima di iniziare i test cross-browser, ma non possiamo sapere quali bug esistono fino a quando non inizieremo i test.

La risposta è essere intelligenti su come testiamo: soddisfare i nostri obiettivi di ricerca dei bug e controllo di integrità testando in modo incrementale, in quello che mi piace chiamare l' attacco a tre fasi .

Attacco in tre fasi

Immagina di essere in una zona di guerra. Sai che i cattivi sono accovacciati nel quartier generale dall'altra parte della città. A tua disposizione hai un agente speciale, una squadra di guerriglie temprati dalla battaglia e un folto gruppo di milizie locali leggermente armate. Lanci un attacco in tre fasi per riconquistare la città:

1. Ricognizione Invia la tua spia nel quartier generale nemico per avere un'idea di dove potrebbero nascondersi i cattivi, quanti di loro ce ne sono e lo stato generale del campo di battaglia.
2. Raid Invia la tua squadra di crack proprio nel cuore del nemico, eliminando la maggior parte dei cattivi con un feroce attacco a sorpresa.
3. Liquidazione Invia la milizia locale per eliminare i cattivi rimasti e mettere in sicurezza l'area.

Puoi portare la stessa strategia e disciplina militare nei tuoi test cross-browser:

1. Ricognizione Condurre test esplorativi in ​​un browser popolare su una macchina di sviluppo. Fatti un'idea di dove potrebbero nascondersi gli insetti. Risolvi eventuali bug riscontrati.
2. Raid Test manuali su una piccola manciata di browser problematici che potrebbero mostrare la maggior parte dei bug. Risolvi eventuali bug riscontrati.
3. Clearance Sanity controlla che i browser più popolari tra il tuo pubblico siano autorizzati a ottenere l'esperienza prevista.

Che tu sia sul campo di battaglia o stia testando il dispositivo, le fasi iniziano con un tempo minimo impiegato e crescono man mano che l'operazione diventa più stabile. C'è solo così tanta ricognizione che puoi fare: dovresti essere in grado di individuare alcuni bug in pochissimo tempo. Il raid è più intenso e richiede tempo, ma fornisce risultati molto utili e stabilizza significativamente il campo di battaglia. La fase di eliminazione è la più laboriosa di tutte, e devi comunque mantenere il tuo ingegno su di te nel caso in cui un cattivo immacolato esca dal nulla e ti faccia del male, ma è un passo necessario per poter affermare con sicurezza che il campo di battaglia è ora al sicuro.

I primi due passaggi del nostro attacco in tre fasi soddisfano il nostro primo obiettivo: la scoperta dei bug . Quando sei sicuro che la tua applicazione sia robusta, ti consigliamo di passare alla fase tre dell'attacco, testando il numero minimo di browser che corrispondono alla maggior parte dei comportamenti di navigazione del tuo pubblico, soddisfacendo l'obiettivo numero due: il controllo dell'integrità. Puoi quindi affermare con certezza quantitativamente che la tua applicazione funziona per l'X% del tuo pubblico.

Configurazione: conosci il tuo nemico

Non entrare in guerra alla leggera. Prima di iniziare il test, ti consigliamo di scoprire in che modo gli utenti accedono ai tuoi contenuti.

Scopri le statistiche del tuo pubblico (da Google Analytics o qualsiasi strumento tu utilizzi) e ottieni i dati in un foglio di calcolo in un formato che puoi leggere e comprendere. Ti consigliamo di essere in grado di vedere ogni combinazione di browser e sistema operativo con una percentuale associata della quota di mercato totale.

Le statistiche sull'utilizzo del browser sono utili solo se possono essere consumate facilmente: non vuoi che ti venga presentato un lungo e scoraggiante elenco di combinazioni browser/sistema operativo/dispositivo da testare. Inoltre, testare ogni possibile combinazione è uno sforzo sprecato. Possiamo utilizzare la nostra conoscenza degli sviluppatori web per consolidare euristicamente le nostre statistiche.

Semplifica le statistiche sull'utilizzo del browser

Come sviluppatori web, non ci interessa particolarmente il sistema operativo su cui è in esecuzione il browser desktop – è molto raro che un bug del browser si applichi a un sistema operativo e non all'altro – quindi uniamo le statistiche per i browser desktop su tutti i sistemi operativi.

Inoltre non ci interessa particolarmente se qualcuno sta usando Firefox 40 o Firefox 39: le differenze tra le versioni sono trascurabili e l'aggiornamento delle versioni è gratuito e spesso automatico. Per facilitare la nostra comprensione delle statistiche del browser, uniamo le versioni di tutti i browser desktop, tranne IE. Sappiamo che le versioni precedenti di IE sono problematiche e diffuse, quindi dobbiamo tenere traccia dei loro dati di utilizzo.

Un argomento simile si applica ai browser OS portatili. Non ci interessa particolarmente la versione di Chrome o Firefox mobile, poiché questi vengono aggiornati regolarmente e facilmente, quindi uniamo le versioni. Ma ancora una volta, ci preoccupiamo delle diverse versioni di IE, quindi registriamo le loro versioni separatamente.

La versione del sistema operativo di un dispositivo è irrilevante se parliamo di Android; l'importante è la versione del browser Android nativo utilizzato, poiché si tratta di un browser notoriamente problematico. D'altra parte, quale versione di iOS è in esecuzione su un dispositivo è molto rilevante poiché le versioni di Safari sono intrinsecamente collegate al sistema operativo. Poi ci sono tutta una serie di browser nativi per altri dispositivi: questi costituiscono una percentuale così piccola del nostro pubblico complessivo che anche loro hanno i loro numeri di versione uniti.

Infine, abbiamo una nuova ondata di browser in rapida crescita: i browser in-app, implementati principalmente su piattaforme di social media. Questo è ancora un terreno nuovo per noi, quindi desideriamo elencare tutte le piattaforme browser in-app e i rispettivi sistemi operativi.

Dopo aver utilizzato le nostre conoscenze di esperti di dominio per unire le statistiche correlate, restringiamo ulteriormente l'elenco rimuovendo tutti i browser che costituiscono meno dello 0,05% del nostro pubblico (sentiti libero di modificare questa soglia in base alle tue esigenze).

Browser desktop

Browser portatili

Browser in-app

Quando hai finito, il tuo foglio di lavoro dovrebbe assomigliare un po' a questo (ignora la colonna "Priorità" per ora - ci arriveremo più avanti):

Quindi ora hai il tuo foglio di calcolo semplificato, che mostra i browser chiave dal punto di vista dello sviluppatore web, ciascuno associato a una percentuale di quota di mercato totale. Tieni presente che dovresti mantenere aggiornato questo foglio di lavoro; l'aggiornamento una volta al mese dovrebbe essere sufficiente.

Ora sei pronto per intraprendere l'attacco in tre fasi.

1. Ricognizione: trova bug indipendenti dal browser

Molto prima ancora di pensare di tirare fuori un dispositivo su cui testare, fai la cosa più semplice che puoi: apri la tua app web nel tuo browser preferito. A meno che tu non sia un masochista completo, è probabile che si tratti di Chrome o Firefox, entrambi stabili e che supportano funzionalità moderne. Lo scopo di questa prima fase è trovare bug indipendenti dal browser .

I bug indipendenti dal browser sono errori di implementazione che non hanno nulla a che fare con il browser o l'hardware utilizzato per accedere all'applicazione. Ad esempio, supponiamo che la tua pagina Web venga pubblicata e inizi a ricevere segnalazioni di bug oscure da persone che si lamentano del fatto che la tua pagina sembra spazzatura sul proprio HTC One in modalità orizzontale. Perdi un sacco di tempo a determinare quale versione di quale browser è stata utilizzata, utilizzando la modalità di debug USB di Android e cercando aiuto in StackOverflow, chiedendoti come diavolo hai intenzione di risolvere questo problema. A tua insaputa, questo bug non ha nulla a che fare con il dispositivo: piuttosto, la tua pagina sembra buggata a una certa larghezza del viewport, che sembra essere la larghezza dello schermo del dispositivo in questione.

Questo è un esempio di bug indipendente dal browser che si è falsamente manifestato come bug specifico del browser o del dispositivo. Sei stato condotto lungo un percorso lungo e dispendioso, con segnalazioni di bug che agiscono come rumore, offuscando la causa principale del problema. Fatti un favore e individua questo tipo di bug proprio all'inizio, con molto meno sforzo e un po' più di accortezza.

Correggendo i bug indipendenti dal browser prima ancora di iniziare i test cross-browser, dovremmo trovarci di fronte a un minor numero di bug in generale. Mi piace chiamarlo l' effetto dell'iceberg che si scioglie . Stiamo sciogliendo gli insetti che sono nascosti sotto la superficie, salvandoci dallo schianto e dall'annegamento nell'oceano - e non ci rendiamo nemmeno conto che lo stiamo facendo.

Di seguito è riportato un breve elenco di cose che puoi fare nel tuo browser di sviluppo per scoprire bug indipendenti dal browser:

• Prova a ridimensionare per visualizzare la reattività. C'è stato un punto di interruzione funky da qualche parte?
• Ingrandisci e rimpicciolisci. Le posizioni dello sfondo dello sprite dell'immagine sono state spostate di traverso?
• Guarda come si comporta l'applicazione con JavaScript disattivato. Ottieni ancora il contenuto principale?
• Guarda come appare l'applicazione con i CSS disattivati. La semantica del markup ha ancora senso?
• Prova a disattivare sia JavaScript che CSS. Stai vivendo un'esperienza accettabile?
• Prova a interagire con l'applicazione utilizzando solo la tastiera. È possibile navigare e vedere tutti i contenuti?
• Prova a limitare la connessione e guarda quanto velocemente viene caricata l'applicazione. Quanto è pesante il caricamento della pagina?

Prima di passare alla fase 2, devi correggere i bug che hai riscontrato. Se non risolviamo i bug indipendenti dal browser, finiremo per segnalare solo molti bug falsi specifici del browser in seguito.

Essere pigro. Risolvi i bug indipendenti dal browser. Quindi possiamo passare alla seconda fase dell'attacco.

2. Raid: prova prima nei browser ad alto rischio

Quando risolviamo i bug, dobbiamo stare attenti che le nostre correzioni non introducano altri bug. Modificare il nostro CSS per correggere il padding in Safari potrebbe interrompere il padding in Firefox. L'ottimizzazione di quel bit di JavaScript per un'esecuzione più fluida in Chrome potrebbe interromperlo completamente in IE. Ogni cambiamento che facciamo comporta dei rischi.

Per essere veramente sicuri che le nuove modifiche non abbiano interrotto l'esperienza in nessuno dei browser in cui abbiamo già testato, dobbiamo tornare indietro e testare di nuovo in quegli stessi browser. Pertanto, per ridurre al minimo la duplicazione degli sforzi, dobbiamo essere intelligenti su come testiamo.

Analisi statistica della distribuzione dei bug

Considera la tabella seguente, dove l'icona a forma di croce indica che il browser ha il bug.

Diciamo che dobbiamo testare i nostri contenuti in ordine crescente di rischio: browser a basso rischio, browser a rischio medio, browser ad alto rischio. Se ti aiuta a visualizzarlo, questi browser potrebbero mappare rispettivamente su Google Chrome, IE 9 e IE 6.

Testando prima il browser a basso rischio (Chrome), troveremmo e risolveremmo il bug n. 2. Quando passiamo al browser a rischio medio, il bug n. 2 è già stato corretto, ma scopriamo un nuovo bug: n. 4. Cambiamo il nostro codice per correggere il bug, ma come possiamo essere sicuri di non aver rotto qualcosa nel browser a basso rischio? Non possiamo essere completamente sicuri, quindi dobbiamo tornare indietro e testare di nuovo in quel browser per verificare che tutto funzioni ancora come previsto.

Ora passiamo al browser ad alto rischio e troviamo i bug n. 1, n. 3 e n. 5, che richiedono una rielaborazione significativa per essere corretti. Una volta che questi sono stati risolti, cosa dobbiamo fare? Torna indietro e prova di nuovo i browser a rischio medio e basso. Questo è un sacco di duplicazione di sforzi. Abbiamo dovuto testare i nostri tre browser per un totale di sei volte.

Consideriamo ora cosa sarebbe successo se avessimo testato i nostri contenuti in ordine decrescente di rischio.

Immediatamente, troveremmo i bug n. 1, n. 3, n. 4 e n. 5 nel browser ad alto rischio. Dopo aver corretto questi bug, passeremmo direttamente al browser a rischio medio e scopriremmo il bug n. 2. Come prima, questa correzione potrebbe aver danneggiato indirettamente qualcosa, quindi è necessario tornare al browser ad alto rischio e ripetere il test. Infine, testiamo nel browser a basso rischio e non scopriamo nuovi bug. In questo caso, abbiamo testato i nostri tre browser in un totale di quattro diverse occasioni, il che è una notevole riduzione del tempo necessario per scoprire e correggere efficacemente lo stesso numero di bug e convalidare il comportamento dello stesso numero di browser .

Potrebbe esserci una pressione sugli sviluppatori per testare prima nei browser più popolari, passando per i browser meno utilizzati verso la fine del nostro test. Tuttavia, è probabile che i browser più diffusi siano browser a basso rischio.

Sai che devi supportare un determinato browser ad alto rischio, quindi togliti di mezzo quel browser all'inizio. Non sprecare sforzi per testare i browser che hanno meno probabilità di generare bug, perché quando passi a browser che producono più bug, dovrai solo tornare indietro e guardare di nuovo quei browser a basso rischio.

La correzione dei bug nei browser difettosi rende il tuo codice più resiliente nei browser buoni

Spesso scoprirai che i bug che si verificano in questi browser problematici sono il risultato inaspettato di un codice scadente da parte tua. Potresti aver disegnato goffamente un div in modo che assomigli a un pulsante o violato in un setTimeout prima di attivare un comportamento arbitrario; esistono soluzioni migliori per entrambi questi problemi. Correggendo i bug che sono i sintomi di un codice errato, è probabile che tu corregga i bug in altri browser prima ancora di vederli. C'è di nuovo quell'effetto iceberg che si scioglie .

Verificando il supporto delle funzionalità, anziché presumere che un browser supporti qualcosa, stai risolvendo quel bug doloroso in IE8 ma stai anche rendendo il tuo codice più robusto per altri ambienti difficili. Fornendo quell'immagine di riserva per Opera Mini, stai incoraggiando l'uso del miglioramento progressivo e come sottoprodotto stai migliorando il tuo prodotto anche per gli utenti di browser che tagliano la senape. Ad esempio, un dispositivo mobile potrebbe perdere la connessione 3G con solo la metà delle risorse dell'applicazione scaricate: l'utente ora ottiene un'esperienza significativa dove prima non avrebbe avuto.

Fai attenzione però: se non stai attento, correggere i bug in browser oscuri può peggiorare il tuo codice. Resisti alla tentazione di annusare la stringa user-agent per fornire in modo condizionale contenuto a browser specifici, ad esempio. Ciò potrebbe risolvere il bug, ma è una pratica completamente insostenibile. Non compromettere l'integrità di un buon codice per supportare browser scomodi.

Identificazione di browser problematici

Allora , cos'è un browser ad alto rischio? La risposta è un po' vaga e dipende dalle funzionalità del browser utilizzate dall'applicazione. Se il tuo JavaScript utilizza indexOf , potrebbe interrompersi in IE 8. Se la tua app utilizza position: fixed , ti consigliamo di verificarlo in Safari su iOS 7.

Can I Use è una risorsa inestimabile e un buon punto di partenza, ma questa è una di quelle aree che deriva ancora dall'esperienza e dall'intuizione degli sviluppatori. Se distribuisci regolarmente app Web, saprai quali browser segnalano problemi più e più volte e puoi perfezionare la tua strategia di test per soddisfare questo problema.

La cosa utile dei bug che trovi nei browser problematici è che spesso si propagano. Se c'è un bug in IE9, è probabile che il bug esista anche in IE8. Se qualcosa sembra strano su Safari su iOS 7, probabilmente sembrerà ancora più pronunciato su iOS 6. Notare uno schema qui? I browser più vecchi tendono ad essere quelli problematici. Questo dovrebbe aiutarti a trovare un elenco abbastanza buono di browser problematici.

Detto questo, esegui il backup con le statistiche di utilizzo. Ad esempio, IE 6 è un browser molto problematico, ma non ci preoccupiamo di testarlo perché la sua quota di mercato totale è troppo bassa. Il tempo impiegato per correggere i bug specifici di IE6 non varrebbe la pena per il piccolo numero di utenti la cui esperienza sarebbe migliorata.

Non sono sempre i browser più vecchi che vorrai testare nella fase del raid. Ad esempio, se si dispone di un progetto canvas 3D WebGL sperimentale con il fallback dell'immagine, i browser meno recenti otterranno solo l'immagine di fallback, quindi è improbabile che troveremo molti bug. Quello che vorremmo invece fare è cambiare la nostra scelta del browser problematico in base all'applicazione in uso. In questo caso, IE9 potrebbe essere un buon browser da testare perché è la prima versione di IE che supporta canvas.

Anche i moderni browser proxy (come Opera Mini) possono essere una buona scelta per un raid test, se la tua applicazione fa uso di funzionalità CSS3 come gradienti o raggio di confine. Un errore comune consiste nel rendere il testo bianco su una sfumatura non supportata, con conseguente testo bianco su bianco illeggibile.

Quando scegli i tuoi browser problematici, usa il tuo intuito e cerca di anticipare dove potrebbero nascondersi i bug.

Diversifica i tuoi browser problematici

I browser e le versioni dei browser sono solo una parte dell'equazione: anche l'hardware è una considerazione importante. Ti consigliamo di testare la tua applicazione su una varietà di dimensioni dello schermo e diverse densità di pixel e provare a passare dalla modalità verticale a quella orizzontale.

Può essere allettante raggruppare i browser correlati perché c'è uno sconto percepito sul costo dello sforzo. Se hai già VirtualBox aperto per testare IE8, ora potrebbe sembrare un buon momento per testare anche IE9, IE10 e IE11. Tuttavia, se sei nelle prime fasi del test della tua app web, vorrai combattere questa tentazione e scegliere invece tre o quattro combinazioni browser-hardware che sono notevolmente diverse l'una dall'altra, per ottenere la massima copertura sul totale spazio di bug come puoi.

Sebbene questi possano variare da progetto a progetto, ecco i miei attuali browser problematici preferiti:

• IE 8 su una macchina virtuale Windows XP;
• Browser Android 2 nativo su tablet Android di fascia media;
• Safari su iPhone 4 con iOS 6;
• Opera mini (vale davvero la pena testare solo con contenuti che dovrebbero funzionare senza JavaScript, come datapics).

Essere pigro. Trova il maggior numero di bug possibile lanciando la tua app sui browser e sui dispositivi supportati più problematici. Con questi bug corretti, sarai quindi in grado di passare alla fase finale dell'attacco.

3. Liquidazione: controllo della sanità mentale

Ora hai testato la tua app nei browser più difficili che devi supportare, si spera che intercetta la maggior parte dei bug. Ma la tua applicazione non è ancora completamente priva di bug. Sono costantemente sorpreso da quanto diverse anche le ultime versioni di Chrome e Firefox renderanno lo stesso contenuto. Hai ancora bisogno di fare qualche altro test.

È la vecchia regola 80:20. In senso figurato, hai corretto l'80% dei bug dopo aver testato il 20% dei browser. Ora quello che vuoi fare è verificare l'esperienza dell'80% del tuo pubblico testando un diverso 20% di browser.

Dare priorità ai browser

L'approccio semplice e ovvio ora consiste nel tornare ai "tradizionali" test cross-browser, affrontando ciascun browser in ordine decrescente di quota di mercato. Se Chrome desktop è la percentuale più alta della condivisione del browser del tuo pubblico, seguito da Safari su iOS 8, seguito da IE11, allora ha senso testare in quest'ordine, giusto?

Questo è un sistema in gran parte equo e non voglio complicare eccessivamente questo passaggio se le tue risorse sono già esaurite. Tuttavia, il fatto è che non tutti i browser sono uguali. Nel mio team, raggruppiamo i browser in base a un albero decisionale che tiene conto dell'utilizzo del browser, della facilità di aggiornamento e del fatto che il browser sia o meno il sistema operativo predefinito.

Fino ad ora, il tuo foglio di calcolo dovrebbe avere una colonna per il browser e una colonna per la sua quota di mercato; ora hai bisogno di una terza colonna, che designa la priorità in cui rientra il browser. A dire il vero, questo lavoro di definizione delle priorità avrebbe dovuto essere svolto prima di lanciare l'attacco in tre fasi, ma ai fini di questo articolo aveva più senso descriverlo qui poiché le priorità non sono realmente necessarie fino alla fase di eliminazione.

Ecco il nostro albero decisionale:

Abbiamo progettato il nostro albero decisionale in modo che i browser P1 coprano circa il 70% del nostro pubblico. I browser P1 e P2 combinati coprono circa il 90% del nostro pubblico. Infine, i browser P1, P2 e P3 ci offrono una copertura del pubblico quasi completa. Miriamo a testare in tutti i browser P1, seguito da P2, seguito da P3, in ordine decrescente di quota di mercato.

Come puoi vedere nel foglio di calcolo all'inizio di questo articolo, abbiamo solo una manciata di browser P1. Il fatto che possiamo verificare l'esperienza di oltre il 70% del nostro pubblico così rapidamente significa che abbiamo poche scuse per non testare nuovamente in quei browser se la base di codice cambia. Passando ai browser P2 e P3, dobbiamo dedicare sforzi sempre maggiori alla verifica dell'esperienza di un'audience in continua diminuzione, quindi dobbiamo impostare ideali di test più realistici per i browser con priorità più bassa. Come linea guida:

• P1 . È necessario controllare l'integrità di questi browser prima di disconnettersi dall'applicazione. Se apportiamo piccole modifiche al nostro codice, dovremmo controllare di nuovo l'integrità di questi browser.
• P2 . Dovremmo controllare l'integrità di questi browser prima di disconnettere l'applicazione. Se apportiamo modifiche sostanziali al nostro codice, dovremmo controllare di nuovo l'integrità di questi browser.
• P3 . Dovremmo controllare l'integrità di questi browser una volta, ma solo se abbiamo tempo.

Non dimenticare la necessità di diversificare il tuo hardware. Se sei in grado di testare su una moltitudine di dimensioni dello schermo diverse e su dispositivi con diverse capacità hardware mentre segui questo elenco, fallo.

Riassunto: l'attacco in tre fasi

Dopo aver fatto lo sforzo di conoscere il tuo nemico ( semplificando le statistiche del tuo pubblico e raggruppando i browser in priorità ), puoi attaccare in tre passaggi:

1. Ricognizione : test esplorativi sul tuo browser preferito, per trovare bug indipendenti dal browser .
2. Raid : test sui browser supportati più problematici su una varietà di hardware, per trovare la maggior parte dei bug .
3. Liquidazione : verifica dell'esperienza della tua applicazione sui browser più utilizzati e strategicamente importanti, per dire con certezza quantitativamente che la tua applicazione funziona .