Testare între browsere de mare impact și efort minim

Testarea între browsere necesită timp și este laborioasă. Cu toate acestea, dezvoltatorii sunt leneși din fire: aderând la principiul DRY, scriind scripturi pentru a automatiza lucrurile pe care altfel ar trebui să le facem manual, utilizând biblioteci terțe; a fi leneși este ceea ce ne face dezvoltatori buni .

Abordarea tradițională a testării „corecte” între browsere este să testați în toate browserele majore utilizate de publicul dvs., trecând treptat la browserele mai vechi sau mai obscure pentru a spune că le-ați testat. Sau, dacă timpul și resursele sunt scurte, testați un mic subset de browsere ad-hoc și sperând că absența unui bug vă oferă încredere în integritatea aplicației. Prima abordare întruchipează o dezvoltare „bună”, dar este ineficientă, în timp ce a doua întruchipează lenea, dar nu este de încredere.

Citiți suplimentare despre SmashingMag:

• Tranziția lui Noah la testarea de utilizare mobilă
• Elementele de bază ale automatizării testelor pentru aplicații, jocuri și web mobil
• Cum să vă creați propriul plan de testare a site-ului web front-end
• Unde sunt cele mai bune laboratoare de dispozitive deschise din lume?

În următoarele cincisprezece minute, sper să vă economisesc ore de efort pierdut prin descrierea unei strategii de testare care nu numai că necesită mai puțină muncă , dar și mai eficientă în prinderea erorilor. Vreau să documentez o strategie de testare realistă mai relevantă și mai valoroasă decât pur și simplu „testați TOATE lucrurile!”, bazându-mă pe experiența mea ca Dezvoltator în Test în BBC Visual Journalism.

Context

În afară de aceasta, merită subliniat că în echipa noastră facem mai mult decât teste manuale. Testarea între browsere nu înlocuiește testele unitare (Jasmine/QUnit), testele funcționale (Cucumber) și, acolo unde este cazul, testele automate de regresie vizuală (Wraith). Într-adevăr, testele automate sunt mai ieftine pe termen lung și sunt esențiale atunci când aplicația ta atinge o anumită dimensiune.

Cu toate acestea, unele erori se manifestă doar în anumite browsere, iar automatizarea testelor nu a intrat încă în mod sigur în domeniul testării între browsere. Cum poate un computer să știe că evenimentul tău automat de defilare tocmai a ascuns jumătate din titlu atunci când este vizualizat pe un iPhone 4? De unde să știe că este o problemă? Până când inteligența artificială crește până la un punct în care computerele înțeleg ceea ce ați construit și au o apreciere pentru narațiunea și talentul artistic pe care încercați să le demonstrați, va fi întotdeauna nevoie de testare manuală. Ca ceva care trebuie efectuat manual, ne datorăm să facem ca procesul de testare între browsere să fie cât mai eficient posibil.

Care este obiectivul tău?

Înainte de a vă scufunda orbește în testarea între browsere, decideți ce sperați să obțineți din asta. Testarea cross-browser poate fi rezumată ca având două obiective principale:

1. Descoperirea erorilor Aceasta implică încercarea de a sparge aplicația pentru a găsi erori de remediat.
2. Verificarea sanității Aceasta implică verificarea faptului că majoritatea publicului dvs. primește experiența așteptată.

Primul lucru pe care vreau să-l luați din acest articol este că aceste două scopuri sunt în conflict unul cu celălalt .

Pe de o parte, știu că pot verifica experiența a aproape 50% din publicul nostru din Marea Britanie doar testând în Chrome (Desktop), Chrome (Android) și Safari (iOS 9). Pe de altă parte, dacă obiectivul meu este să găsesc erori, atunci voi dori să-mi arunc aplicația web către cele mai problematice browsere pe care trebuie să le susținem activ: în cazul nostru, IE8 și browserul nativ Android 2.

Utilizatorii acestor două browsere reprezintă un procent în scădere din audiența noastră (în prezent în jur de 1,5%), ceea ce face ca testarea în aceste browsere să fie o utilizare proastă a timpului nostru, dacă obiectivul nostru este să verificăm sănătatea. Dar acestea sunt browsere grozave pe care trebuie să le testați dacă doriți să vedeți cât de deteriorată poate deveni aplicația dvs. bine concepută atunci când este aruncată într-un motor de randare obscur.

Strategiile tradiționale de testare pun, în mod înțeles, mai mult accent pe testarea în browserele populare. Cu toate acestea, un număr disproporționat de bug-uri există doar în browserele mai obscure, care conform modelului tradițional de testare nu vor ieși la lumină decât spre finalul testării. Atunci te confrunți cu o dilemă...

Ce faci când găsești o eroare târziu în faza de testare cu coadă lungă?

1. Ignora bug-ul.
2. Remediați eroarea și sperați că nu ați spart nimic.
3. Remediați eroarea și re-testați în toate browserele testate anterior.

Într-o lume ideală, ultima opțiune este cea mai bună, deoarece este singura modalitate de a fi cu adevărat încrezători că toate browserele încă funcționează conform așteptărilor. Cu toate acestea, este, de asemenea, monstruos de ineficient - și este ceva pe care probabil ar trebui să-l faceți de mai multe ori. Este echivalentul testării manuale a unui sortare cu bule.

Prin urmare, ne aflăm într-o situație Catch-22: pentru o eficiență maximă, dorim să remediam toate erorile înainte de a începe testarea între browsere, dar nu putem ști ce erori există până când nu începem testarea.

Răspunsul este să fim deștepți în ceea ce privește modul în care testăm: îndeplinirea obiectivelor noastre de găsire a erorilor și verificarea logicii prin testarea progresivă, în ceea ce îmi place să numesc atacul în trei faze .

Atac în trei faze

Imaginează-ți că ești într-o zonă de război. Știi că băieții răi sunt așezați în sediul central din partea cealaltă a orașului. Aveți la dispoziție un agent special, o echipă crack de gherile întărite în luptă și un grup mare de miliție locală ușor înarmată. Lansați un atac în trei faze pentru a recupera orașul:

1. Recunoaștere Trimite-ți spionul în cartierul general al inamicului pentru a-ți da seama unde s-ar putea ascunde băieții răi, câți dintre ei sunt și starea generală a câmpului de luptă.
2. Raid Trimite-ți echipa de crack direct în inima inamicului, eliminând majoritatea băieților răi într-un atac surpriză feroce.
3. Autorizație Trimiteți miliția locală pentru a-i elimina pe cei răi rămași și a securiza zona.

Puteți aduce aceeași strategie și disciplină militară la testarea pe mai multe browsere:

1. Recunoaștere Efectuați teste exploratorii într-un browser popular pe o mașină de dezvoltare. Faceți o idee unde s-ar putea ascunde insectele. Remediați orice erori întâlnite.
2. Raid Testare manuală pe o mână mică de browsere problematice care ar putea demonstra cele mai multe erori. Remediați orice erori întâlnite.
3. Clearance Sanity verificând că cele mai populare browsere în rândul publicului dvs. sunt șterse pentru a obține experiența așteptată.

Indiferent dacă vă aflați pe câmpul de luptă sau testați dispozitivele, fazele încep cu un timp minim petrecut și cresc pe măsură ce operațiunea devine mai stabilă. Există doar atâtea recunoașteri pe care le puteți face – ar trebui să puteți observa unele bug-uri în foarte puțin timp. Raidul este mai intens și mai consumator de timp, dar oferă rezultate foarte valoroase și stabilizează semnificativ câmpul de luptă. Faza de eliminare este cea mai laborioasă dintre toate și trebuie totuși să vă păstrați inteligența în cazul în care un răufăcător nepătat iese de nicăieri și vă provoacă un rău – dar este un pas necesar pentru a putea susține cu încredere că câmpul de luptă este acum în siguranță.

Primii doi pași din atacul nostru în trei faze îndeplinesc primul nostru obiectiv: descoperirea erorilor . Când sunteți încrezător că aplicația dvs. este robustă, veți dori să treceți la faza a treia a atacului, testând numărul minim de browsere care se potrivesc cu majoritatea comportamentelor de navigare ale publicului dvs., îndeplinind obiectivul numărul doi: verificarea sanității. Apoi, puteți spune cu încredere susținută cantitativ că aplicația dvs. funcționează pentru X% din publicul dvs.

Configurare: Cunoaște-ți inamicul

Nu intra ușor în război. Înainte de a începe testarea, veți dori să aflați cum accesează utilizatorii conținutul dvs.

Aflați statisticile de audiență (de la Google Analytics sau orice instrument pe care îl utilizați) și obțineți datele într-o foaie de calcul într-un format pe care îl puteți citi și înțelege. Veți dori să puteți vedea fiecare combinație de browser și sistem de operare cu un procent asociat din cota totală de piață.

Statisticile de utilizare a browserului sunt utile doar dacă pot fi consumate cu ușurință: nu doriți să vi se prezinte o listă lungă și descurajantă de combinații de browser/OS/dispozitiv de testat. În plus, testarea fiecărei combinații posibile este un efort irosit. Ne putem folosi cunoștințele de dezvoltatori web pentru a ne consolida statisticile euristic.

Simplificați-vă statisticile de utilizare a browserului

În calitate de dezvoltatori web, nu ne interesează în mod special pe ce sistem de operare rulează browserul desktop – este foarte rar ca o eroare a browserului să se aplice unui sistem de operare și nu celuilalt – așa că îmbinăm statisticile pentru browserele desktop pe toate sistemele de operare.

De asemenea, nu ne interesează în mod special dacă cineva folosește Firefox 40 sau Firefox 39: diferențele dintre versiuni sunt neglijabile, iar actualizarea versiunilor este gratuită și adesea automată. Pentru a ne ușura înțelegerea statisticilor browserului, îmbinăm versiunile tuturor browserelor desktop – cu excepția IE. Știm că versiunile mai vechi de IE sunt atât problematice, cât și răspândite, așa că trebuie să urmărim cifrele de utilizare ale acestora.

Un argument similar se aplică browserelor portabile cu sistem de operare. Nu ne pasă în mod special de versiunea de Chrome sau Firefox pentru mobil, deoarece acestea sunt actualizate în mod regulat și ușor – așa că îmbinăm versiunile. Dar din nou, ne pasă de diferitele versiuni de IE, așa că înregistrăm versiunile lor separat.

Versiunea sistemului de operare a unui dispozitiv este irelevantă dacă vorbim despre Android; ceea ce este important este versiunea browserului nativ Android folosit, deoarece acesta este un browser notoriu problematic. Pe de altă parte, ce versiune de iOS rulează un dispozitiv este foarte relevantă, deoarece versiunile Safari sunt legate intrinsec de sistemul de operare. Apoi, există o serie întreagă de browsere native pentru alte dispozitive: acestea reprezintă un procent atât de mic din publicul nostru general încât și ele au combinate numerele de versiune.

În cele din urmă, avem un nou val de browsere în creștere rapidă în popularitate: browsere în aplicație, implementate în principal pe platformele de social media. Acesta este încă un teren nou pentru noi, așa că suntem dornici să listăm toate platformele de browser în aplicație și sistemul de operare respectiv.

După ce ne-am folosit cunoștințele experților în domeniu pentru a îmbina statisticile aferente, restrângem și mai mult lista eliminând fiecare browser care reprezintă mai puțin de 0,05% din audiența noastră (nu ezitați să ajustați acest prag în funcție de propriile cerințe).

Browsere desktop

Browsere portabile

Browsere în aplicație

Când ați terminat, foaia dvs. de calcul ar trebui să arate puțin astfel (ignorați coloana „Prioritate” pentru moment - vom ajunge la asta mai târziu):

Așa că acum aveți foaia de calcul simplificată, care arată browserele cheie din perspectiva dezvoltatorului web, fiecare asociat cu un procent total de cotă de piață. Vă rugăm să rețineți că ar trebui să păstrați această foaie de calcul actualizată; actualizarea o dată pe lună ar trebui să fie suficientă.

Acum sunteți gata să începeți atacul în trei faze.

1. Recunoaștere: Găsiți erori independente de browser

Cu mult înainte să vă gândiți să scoateți un dispozitiv pe care să îl testați, faceți cel mai ușor lucru pe care îl puteți: deschide aplicația web în browserul tău preferat. Cu excepția cazului în care sunteți un masochist complet, este probabil să fie Chrome sau Firefox, ambele sunt stabile și acceptă funcții moderne. Scopul acestei prime etape este de a găsi erori independente de browser .

Erorile independente de browser sunt erori de implementare care nu au nimic de-a face cu browserul sau hardware-ul folosit pentru a accesa aplicația dvs. De exemplu, să presupunem că pagina dvs. web este activă și începeți să primiți rapoarte obscure de erori de la oameni care se plâng că pagina dvs. arată o mizerie pe HTC One în modul peisaj. Pierzi mult timp determinând ce versiune a browserului a fost folosită, folosind modul de depanare USB al Android și căutând ajutor în StackOverflow, întrebându-te cum naiba vei remedia acest lucru. Fără să știți, această eroare nu are nimic de-a face cu dispozitivul: mai degrabă, pagina dvs. pare greșită la o anumită lățime a ferestrei de vizualizare, care se întâmplă să fie lățimea ecranului dispozitivului în cauză.

Acesta este un exemplu de eroare independentă de browser care s-a manifestat în mod fals ca o eroare specifică browserului sau dispozitivului. Ați fost condus pe o cale lungă și irosită, cu rapoartele de erori acționând ca zgomot, ofucând cauza principală a problemei. Fă-ți o favoare și prinde acest tip de bug chiar de la început, cu mult mai puțin efort și puțin mai multă previziune.

Prin remedierea erorilor independente de browser chiar înainte de a începe testarea între browsere, ar trebui să ne confruntăm cu mai puține erori în general. Îmi place să numesc asta efectul de topire a aisbergului . Topim insectele care sunt ascunse sub suprafață, ferindu-ne de a ne prăbuși și de a ne înec în ocean - și nici măcar nu ne dăm seama că o facem.

Mai jos este o listă scurtă de lucruri pe care le puteți face în browserul dvs. de dezvoltare pentru a descoperi erori independente de browser:

• Încercați să redimensionați pentru a vedea capacitatea de răspuns. A existat undeva un punct de întrerupere funky?
• Măriți și micșorați. Pozițiile de fundal ale sprite-ului dvs. de imagine au fost înclinate?
• Vedeți cum se comportă aplicația cu JavaScript dezactivat. Mai primești conținutul de bază?
• Vedeți cum arată aplicația cu CSS dezactivat. Mai are sens semantica marcajului?
• Încercați să dezactivați atât JavaScript, cât și CSS. Primești o experiență acceptabilă?
• Încercați să interacționați cu aplicația folosind doar tastatura. Este posibil să navighezi și să vezi tot conținutul?
• Încercați să vă limitați conexiunea și vedeți cât de repede se încarcă aplicația. Cât de grea este încărcarea paginii?

Înainte de a trece la faza 2, trebuie să remediați erorile pe care le-ați întâlnit. Dacă nu remediam erorile independente de browser, vom ajunge să raportăm mai târziu o mulțime de erori false specifice browserului.

Fi lenes. Remediați erorile independente de browser. Apoi putem trece la a doua fază a atacului.

2. Raid: Testați mai întâi în browsere cu risc ridicat

Când remediam erori, trebuie să avem grijă ca remedierea noastră să nu introducă mai multe erori. Modificarea CSS-ului nostru pentru a remedia umplutura în Safari ar putea rupe umplutura în Firefox. Optimizarea acelui fragment de JavaScript pentru a rula mai bine în Chrome l-ar putea rupe complet în IE. Fiecare schimbare pe care o facem presupune riscuri.

Pentru a fi cu adevărat încrezători că noile modificări nu au rupt experiența în niciunul dintre browserele în care am testat deja, trebuie să ne întoarcem și să testăm din nou în aceleași browsere. Prin urmare, pentru a minimiza dublarea efortului, trebuie să fim inteligenți în ceea ce privește modul în care testăm.

Analiza statistică a distribuției erorilor

Luați în considerare următorul tabel, unde pictograma cruce înseamnă că browserul are eroarea.

Să presupunem că trebuie să ne testăm conținutul în ordinea crescătoare a riscului: browser cu risc scăzut, browser cu risc mediu, browser cu risc ridicat. Dacă vă ajută să vizualizați acest lucru, aceste browsere s-ar putea mapa la Google Chrome, IE 9 și, respectiv, IE 6.

Testând mai întâi browserul cu risc scăzut (Chrome), vom găsi și remediam bug-ul nr. 2. Când trecem la browserul cu risc mediu, bug-ul #2 este deja remediat, dar descoperim o nouă eroare: #4. Ne schimbăm codul pentru a remedia eroarea – dar cum putem fi siguri că acum nu am spart ceva în browserul cu risc scăzut? Nu putem fi complet siguri, așa că trebuie să revenim și să testăm din nou în acel browser pentru a verifica că totul funcționează în continuare conform așteptărilor.

Acum trecem la browserul cu risc ridicat și găsim erorile #1, #3 și #5, care necesită o reelaborare semnificativă pentru a le remedia. Odată ce acestea au fost reparate, ce trebuie să facem? Reveniți și testați din nou browserele cu risc mediu și scăzut. Aceasta este multă dublare a efortului. A trebuit să ne testăm cele trei browsere în total de șase ori.

Acum să luăm în considerare ce s-ar fi întâmplat dacă ne-am fi testat conținutul în ordinea descrescătoare a riscului.

Imediat, am găsi bug-urile #1, #3, #4 și #5 în browserul cu risc ridicat. După ce am remediat aceste erori, am trece direct la browserul cu risc mediu și am descoperi bug-ul nr. 2. Ca și înainte, este posibil ca această remediere să fi rupt ceva indirect, așa că este necesar să reveniți la browserul cu risc ridicat și să retestați. În cele din urmă, testăm în browserul cu risc scăzut și nu descoperim erori noi. În acest caz, ne-am testat cele trei browsere cu un total de patru ocazii diferite, ceea ce reprezintă o reducere mare a timpului necesar pentru a descoperi și a remedia efectiv același număr de erori și a valida comportamentul aceluiași număr de browsere. .

Poate exista o presiune asupra dezvoltatorilor să testeze mai întâi în cele mai populare browsere, mergând până la browserele mai puțin utilizate spre sfârșitul testării noastre. Cu toate acestea, este posibil ca browserele populare să fie browsere cu risc scăzut.

Știți că trebuie să acceptați un anumit browser cu risc ridicat, așa că îndepărtați-l din drum chiar de la început. Nu pierdeți eforturi pentru a testa browsere care au mai puține șanse să producă erori, deoarece atunci când treceți la browsere care produc mai multe erori, va trebui doar să vă întoarceți și să vă uitați din nou la acele browsere cu risc scăzut.

Remedierea erorilor din browserele proaste face ca codul dvs. să fie mai rezistent în browserele bune

Adesea, veți descoperi că erorile care apar în aceste browsere problematice sunt rezultatul neașteptat al codului slab din partea dvs. Este posibil să fi creat stângaci un div să arate ca un buton sau să fi piratat un setTimeout înainte de a declanșa un comportament arbitrar; există soluții mai bune pentru ambele probleme. Prin remedierea erorilor care sunt simptomele codului defectuos, este posibil să remediați erorile din alte browsere chiar înainte de a le vedea. Există din nou acel efect de topire a aisbergului .

Verificând suportul pentru funcții, în loc să presupunem că un browser acceptă ceva, remediați acea eroare dureroasă în IE8, dar vă faceți și codul mai robust pentru alte medii dure. Oferind această alternativă de imagine pentru Opera Mini, încurajați utilizarea îmbunătățirii progresive și, ca produs secundar, vă îmbunătățiți produsul chiar și pentru utilizatorii de browsere care reduc muștarul. De exemplu, un dispozitiv mobil ar putea să-și piardă conexiunea 3G cu doar jumătate din activele aplicației dvs. descărcate: utilizatorul beneficiază acum de o experiență semnificativă acolo unde nu ar avea înainte.

Ai grijă totuși: dacă nu ești atent, remedierea erorilor din browserele obscure poate înrăutăți codul. Rezistați tentației de a adulmeca șirul user-agent pentru a livra condiționat conținut anumitor browsere, de exemplu. Acest lucru ar putea rezolva eroarea, dar este o practică complet nesustenabilă. Nu compromite integritatea unui cod bun pentru a accepta browsere incomode.

Identificarea browserelor cu probleme

Deci, ce este un browser cu risc ridicat? Răspunsul este puțin lânos și depinde de caracteristicile browserului pe care le folosește aplicația ta. Dacă JavaScript folosește indexOf , se poate rupe în IE 8. Dacă aplicația dvs. folosește position: fixed , veți dori să o verificați în Safari pe iOS 7.

Can I Use este o resursă de neprețuit și un bun loc pentru a începe, dar acesta este unul dintre acele domenii care vine din nou din experiență și din intuiția dezvoltatorului. Dacă lansați aplicații web în mod regulat, veți ști ce browsere semnalează probleme din nou și din nou și vă puteți perfecționa strategia de testare pentru a se adapta la aceasta.

Lucrul util despre erorile pe care le găsiți în browserele problematice este că acestea se vor propaga adesea. Dacă există o eroare în IE9, sunt șanse ca bug-ul să existe și în IE8. Dacă ceva arată ciudat pe Safari pe iOS 7, probabil că va arăta și mai pronunțat pe iOS 6. Observați un model aici? Browserele mai vechi tind să fie cele problematice. Acest lucru ar trebui să vă ajute să veniți cu o listă destul de bună de browsere problematice.

Acestea fiind spuse, faceți o copie de rezervă a acestora cu statistici de utilizare. De exemplu, IE 6 este un browser foarte problematic, dar nu ne obosim să-l testăm pentru că cota sa totală de piață este prea mică. Timpul petrecut pentru remedierea erorilor specifice IE6 nu ar merita efortul pentru numărul mic de utilizatori a căror experiență ar fi îmbunătățită.

Nu întotdeauna veți dori să testați browserele mai vechi în faza de raid. De exemplu, dacă aveți un proiect experimental de pânză WebGL 3D cu imagine de rezervă, browserele mai vechi vor primi doar imaginea de rezervă, așa că este puțin probabil să găsim multe erori. Ceea ce am dori să facem în schimb este să ne schimbăm alegerea browserului problematic în funcție de aplicația disponibilă. În acest caz, IE9 ar putea fi un browser bun de testat, deoarece este prima versiune de IE care acceptă canvas.

Browserele proxy moderne (cum ar fi Opera Mini) pot fi, de asemenea, o alegere bună pentru un test de raid, dacă aplicația dvs. folosește caracteristici CSS3, cum ar fi gradienții sau raza de frontieră. O eroare comună este redarea textului alb pe un gradient neacceptat, rezultând text ilizibil alb-pe-alb.

Atunci când alegeți browserele problematice, folosiți-vă intuiția și încercați să anticipați unde s-ar putea ascunde erorile.

Diversifică-ți browserele problematice

Browserele și versiunile de browser sunt doar o parte a ecuației: hardware-ul este de asemenea o considerație importantă. Veți dori să vă testați aplicația pe o varietate de dimensiuni de ecran și cu diferite densități de pixeli și să încercați să comutați între modul portret și peisaj.

Poate fi tentant să grupați browserele conexe, deoarece există o reducere percepută la costul efortului. Dacă aveți deja VirtualBox deschis pentru a testa IE8, acum ar putea părea un moment bun pentru a testa și în IE9, IE10 și IE11. Cu toate acestea, dacă vă aflați în primele etape ale testării aplicației dvs. web, veți dori să luptați împotriva acestei tentații și să alegeți în schimb trei sau patru combinații browser-hardware care sunt semnificativ diferite una de cealaltă, pentru a obține o acoperire cât mai mare asupra totalului spațiu pentru erori după cum puteți.

Deși acestea pot varia de la proiect la proiect, iată browserele mele actuale problematice alese:

• IE 8 pe o VM Windows XP;
• Browser Android 2 nativ pe o tabletă Android de gamă medie;
• Safari pe un iPhone 4 care rulează iOS 6;
• Opera mini (numai că merită testat cu conținut care ar trebui să funcționeze fără JavaScript, cum ar fi datapics).

Fi lenes. Găsiți cât mai multe erori posibil, aruncând aplicația la cele mai problematice browsere și dispozitive acceptate. Cu aceste erori remediate, puteți trece la faza finală a atacului.

3. Clearance: verificarea sanității

Acum ți-ai testat aplicația în cele mai dure browsere pe care trebuie să le suporti, sperăm că prind majoritatea erorilor. Dar aplicația dvs. nu este complet lipsită de erori încă. Sunt în mod constant surprins de cât de diferite chiar și cele mai recente versiuni de Chrome și Firefox vor reda același conținut. Mai trebuie să faci niște teste.

Este acea veche regulă 80:20. În mod figurat, ați remediat 80% dintre erori după ce ați testat 20% dintre browsere. Acum ceea ce vrei să faci este să verifici experiența a 80% din publicul tău prin testarea a 20% din browsere diferite.

Prioritizarea browserelor

Abordarea simplă și evidentă acum este de a reveni la testarea „tradițională” între browsere, abordând fiecare browser în ordinea descrescătoare a cotei de piață. Dacă desktopul Chrome se întâmplă să fie cea mai mare proporție din cota de browser a publicului tău, urmat de Safari pe iOS 8, urmat de IE11, atunci este logic să testezi în această ordine, nu?

Acesta este un sistem în mare măsură corect și nu vreau să complic prea mult acest pas dacă resursele dvs. sunt deja întinse. Cu toate acestea, adevărul este că nu toate browserele sunt create la fel. În echipa mea, grupăm browserele în funcție de un arbore de decizie care ia în considerare utilizarea browserului, ușurința de actualizare și dacă browserul este sau nu implicit al sistemului de operare.

Până acum, foaia de calcul ar trebui să aibă o coloană pentru browser și o coloană pentru cota de piață; acum aveți nevoie de o a treia coloană, care să desemneze prioritatea în care se încadrează browserul. Adevărul să fie spus, această lucrare de prioritizare ar fi trebuit făcută înainte de lansarea atacului în trei faze, dar în sensul acestui articol a fost mai logic să o descriem aici, deoarece prioritățile nu sunt cu adevărat necesare până în faza de eliminare.

Iată arborele nostru de decizie:

Ne-am proiectat arborele de decizie astfel încât browserele P1 să acopere aproximativ 70% din audiența noastră. Browserele P1 și P2 combinate acoperă aproximativ 90% din audiența noastră. În cele din urmă, browserele P1, P2 și P3 ne oferă o acoperire aproape completă a publicului. Ne propunem să testăm în toate browserele P1, urmat de P2, urmat de P3, în ordinea descrescătoare a cotei de piață.

După cum puteți vedea în foaia de calcul de mai devreme în acest articol, avem doar câteva browsere P1. Faptul că putem verifica atât de repede experiența a peste 70% din audiența noastră înseamnă că nu avem scuze pentru a nu re-testa în acele browsere dacă baza de cod se schimbă. Pe măsură ce trecem la browserele P2 și P3, trebuie să depunem un efort din ce în ce mai mare pentru a verifica experiența unei dimensiuni de public în continuă scădere, așa că trebuie să stabilim idealuri de testare mai realiste pentru browserele cu prioritate inferioară. Ca orientare:

• P1 . Trebuie să verificăm starea de spirit în aceste browsere înainte de a ne deconecta de la aplicație. Dacă facem mici modificări codului nostru, atunci ar trebui să verificăm din nou aceste browsere.
• P2 . Ar trebui să verificăm starea de spirit în aceste browsere înainte de a deconecta aplicația. Dacă facem modificări majore codului nostru, atunci ar trebui să verificăm din nou aceste browsere.
• P3 . Ar trebui să verificăm o singură dată aceste browsere, dar numai dacă avem timp.

Nu uita de nevoia de a-ți diversifica hardware-ul. Dacă puteți testa pe o multitudine de dimensiuni diferite de ecran și pe dispozitive cu capacități hardware diferite în timp ce urmați această listă, atunci faceți acest lucru.

Rezumat: atacul în trei faze

Odată ce ai depus efortul de a -ți cunoaște inamicul ( simplificarea statisticilor de audiență și gruparea browserelor în priorități ), poți ataca în trei pași:

1. Recunoaștere : testare exploratorie pe browserul dvs. preferat, pentru a găsi erori independente de browser .
2. Raid : testarea celor mai problematice browsere acceptate pe o varietate de hardware, pentru a găsi majoritatea erorilor .
3. Autorizare : verificarea experienței aplicației dvs. pe cele mai utilizate browsere și cele mai importante din punct de vedere strategic, pentru a spune cu încredere susținută cantitativ că aplicația dvs. funcționează .