Pengujian Lintas-Browser Berdampak Tinggi dan Upaya Minimal

Pengujian lintas-browser memakan waktu dan melelahkan. Namun, pengembang pada dasarnya malas: mengikuti prinsip KERING, menulis skrip untuk mengotomatiskan hal-hal yang seharusnya kita lakukan dengan tangan, memanfaatkan perpustakaan pihak ketiga; menjadi malas adalah apa yang membuat kita pengembang yang baik .

Pendekatan tradisional untuk pengujian lintas-browser 'dengan benar' adalah menguji di semua browser utama yang digunakan oleh audiens Anda, secara bertahap pindah ke browser yang lebih lama atau lebih tidak jelas untuk mengatakan bahwa Anda telah mengujinya. Atau, jika waktu dan sumber daya terbatas, menguji sebagian kecil browser ad hoc dan berharap tidak adanya bug memberi Anda keyakinan akan integritas aplikasi. Pendekatan pertama mewujudkan pembangunan 'baik' tetapi tidak efisien, sedangkan yang kedua mewujudkan kemalasan tetapi tidak dapat diandalkan.

Bacaan Lebih Lanjut tentang SmashingMag:

• Transisi Nuh ke Pengujian Kegunaan Seluler
• Dasar-dasar Otomasi Uji Untuk Aplikasi, Game, dan Web Seluler
• Cara Membuat Rencana Pengujian Situs Web Front-End Anda Sendiri
• Di mana Lab Perangkat Terbuka Terbaik Dunia?

Dalam lima belas menit ke depan, saya berharap dapat menghemat waktu berjam-jam dari upaya yang terbuang dengan menjelaskan strategi pengujian yang tidak hanya kurang padat karya , tetapi lebih efektif dalam menangkap bug. Saya ingin mendokumentasikan strategi pengujian realistis yang lebih relevan dan berharga daripada sekadar "menguji SEMUA hal!", memanfaatkan pengalaman saya sebagai Pengembang dalam Pengujian di Jurnalisme Visual BBC.

Konteks

Selain itu, perlu ditunjukkan bahwa kami melakukan lebih dari sekadar pengujian manual di tim kami. Pengujian lintas-browser bukanlah pengganti untuk pengujian unit (Jasmine/QUnit), pengujian fungsional (Mentimun), dan jika sesuai, pengujian regresi visual otomatis (Wraith). Memang, pengujian otomatis lebih murah dalam jangka panjang dan sangat penting ketika aplikasi Anda mencapai ukuran tertentu.

Namun, beberapa bug hanya muncul di browser tertentu, dan otomatisasi pengujian belum secara andal memasuki domain pengujian lintas-browser. Bagaimana komputer dapat mengetahui bahwa acara gulir otomatis Anda baru saja mengaburkan separuh judul saat dilihat di iPhone 4? Bagaimana ia tahu itu masalah? Sampai kecerdasan buatan tumbuh ke titik di mana komputer memahami apa yang Anda buat dan menghargai narasi dan seni yang Anda coba tunjukkan, akan selalu ada kebutuhan untuk pengujian manual. Sebagai sesuatu yang harus dilakukan secara manual, kami berhutang pada diri kami sendiri untuk membuat proses pengujian lintas-browser seefisien mungkin.

Apa Tujuan Anda?

Sebelum menyelam secara membabi buta ke dalam pengujian lintas-browser, putuskan apa yang Anda harapkan darinya. Pengujian lintas-browser dapat diringkas memiliki dua tujuan utama:

1. Menemukan bug Ini memerlukan upaya untuk memecahkan aplikasi Anda untuk menemukan bug untuk diperbaiki.
2. Pemeriksaan kewarasan Ini melibatkan verifikasi bahwa mayoritas audiens Anda menerima pengalaman yang diharapkan.

Hal pertama yang saya ingin Anda ambil dari artikel ini adalah bahwa kedua tujuan ini bertentangan satu sama lain .

Di satu sisi, saya tahu bahwa saya dapat memverifikasi pengalaman hampir 50% audiens Inggris kami hanya dengan menguji di Chrome (Desktop), Chrome (Android) dan Safari (iOS 9). Di sisi lain, jika tujuan saya adalah untuk menemukan bug maka saya ingin membuang aplikasi web saya di browser paling bermasalah yang harus kami dukung secara aktif: dalam kasus kami, IE8 dan Browser Android asli 2.

Pengguna kedua browser ini membuat persentase audiens kami berkurang (saat ini sekitar 1,5%), yang membuat pengujian di browser ini menggunakan waktu kami dengan buruk jika tujuan kami adalah untuk memeriksa kewarasan. Tapi mereka adalah browser yang bagus untuk diuji jika Anda ingin melihat seberapa hancur aplikasi Anda yang dirancang dengan baik ketika dilemparkan ke mesin rendering yang tidak jelas.

Strategi pengujian tradisional dapat dimengerti lebih menekankan pada pengujian di browser populer. Namun, jumlah bug yang tidak proporsional hanya ada di browser yang lebih tidak jelas, yang di bawah model pengujian tradisional tidak akan terungkap sampai menjelang akhir pengujian. Anda kemudian dihadapkan pada dilema ...

Apa yang Anda lakukan ketika Anda menemukan bug di akhir fase pengujian ekor panjang?

1. Abaikan bugnya.
2. Perbaiki bug dan harap Anda tidak merusak apa pun.
3. Perbaiki bug dan uji ulang di semua browser yang diuji sebelumnya.

Di dunia yang ideal, opsi terakhir adalah yang terbaik karena ini adalah satu-satunya cara untuk benar-benar yakin bahwa semua browser masih berfungsi seperti yang diharapkan. Namun, ini juga sangat tidak efisien - dan mungkin Anda harus melakukannya berkali-kali. Ini adalah pengujian manual yang setara dengan bubble sort.

Oleh karena itu kami menemukan diri kami dalam situasi Catch-22: untuk efisiensi maksimum, kami ingin memperbaiki semua bug sebelum memulai pengujian lintas-browser, tetapi kami tidak dapat mengetahui bug apa yang ada sampai kami memulai pengujian.

Jawabannya adalah menjadi cerdas tentang cara kami menguji: memenuhi tujuan kami untuk menemukan bug dan memeriksa kewarasan dengan menguji secara bertahap, dalam apa yang saya sebut sebagai serangan tiga fase .

Serangan Tiga Fase

Bayangkan Anda berada di zona perang. Anda tahu bahwa orang-orang jahat berjongkok di markas besar di sisi lain kota. Yang Anda inginkan, Anda memiliki agen khusus, tim crack gerilyawan tangguh pertempuran dan sekelompok besar milisi lokal bersenjata ringan. Anda meluncurkan serangan tiga fase untuk merebut kembali kota:

1. Pengintaian Kirim mata-mata Anda ke markas musuh untuk mengetahui di mana orang-orang jahat mungkin bersembunyi, berapa banyak dari mereka dan keadaan umum medan perang.
2. Raid Kirim tim crack Anda tepat ke jantung musuh, singkirkan sebagian besar penjahat dalam satu serangan kejutan yang sengit.
3. Clearance Kirim milisi lokal untuk mengambil penjahat yang tersisa dan mengamankan daerah tersebut.

Anda dapat membawa strategi dan disiplin militer yang sama ke pengujian lintas-browser Anda:

1. Pengintaian Melakukan tes eksplorasi di browser populer di mesin pengembangan. Rasakan di mana bug mungkin bersembunyi. Perbaiki bug yang ditemukan.
2. Raid Pengujian manual pada beberapa browser bermasalah yang kemungkinan besar menunjukkan bug paling banyak. Perbaiki bug yang ditemukan.
3. Clearance Sanity memeriksa bahwa browser paling populer di antara audiens Anda dibersihkan untuk mendapatkan pengalaman yang diharapkan.

Baik Anda berada di medan perang atau sedang menguji perangkat, fase dimulai dengan sedikit waktu yang dihabiskan dan berkembang saat operasi menjadi lebih stabil. Hanya ada begitu banyak pengintaian yang dapat Anda lakukan – Anda seharusnya dapat menemukan beberapa bug dalam waktu yang sangat singkat. Serangan itu lebih intens dan memakan waktu, tetapi memberikan hasil yang sangat berharga dan secara signifikan menstabilkan medan perang. Fase pembersihan adalah yang paling melelahkan dari semuanya, dan Anda masih perlu menjaga akal Anda jika ada penjahat yang tidak terlihat muncul entah dari mana dan menyebabkan Anda terluka – tetapi ini adalah langkah yang diperlukan untuk dapat dengan percaya diri mengklaim bahwa medan perang adalah sekarang aman.

Dua langkah pertama dalam serangan tiga fase kami memenuhi tujuan pertama kami: penemuan bug . Ketika Anda yakin bahwa aplikasi Anda kuat, Anda akan ingin melanjutkan ke fase tiga serangan, menguji dalam jumlah minimum browser yang cocok dengan sebagian besar perilaku penjelajahan audiens Anda, memenuhi tujuan nomor dua: pemeriksaan kewarasan. Anda kemudian dapat mengatakan dengan keyakinan yang didukung secara kuantitatif bahwa aplikasi Anda berfungsi untuk X% audiens Anda.

Pengaturan: Kenali Musuh Anda

Jangan masuk ke dalam perang dengan mudah. Sebelum Anda mulai menguji, Anda pasti ingin mengetahui bagaimana pengguna mengakses konten Anda.

Cari tahu statistik audiens Anda (dari Google Analytics, atau alat apa pun yang Anda gunakan) dan dapatkan data dalam spreadsheet dalam format yang dapat Anda baca dan pahami. Anda pasti ingin dapat melihat setiap kombinasi browser dan sistem operasi dengan persentase terkait dari total pangsa pasar.

Statistik penggunaan browser hanya berguna jika dapat digunakan dengan mudah: Anda tidak ingin dihadapkan pada daftar kombinasi browser/OS/perangkat yang panjang dan menakutkan yang harus diuji. Selain itu, menguji setiap kombinasi yang mungkin adalah upaya yang sia-sia. Kami dapat menggunakan pengetahuan pengembang web kami untuk mengkonsolidasikan statistik kami secara heuristik.

Sederhanakan Statistik Penggunaan Browser Anda

Sebagai pengembang web, kami tidak terlalu peduli OS mana yang menjalankan browser desktop – sangat jarang bug browser akan berlaku untuk satu OS dan bukan yang lain – jadi kami menggabungkan statistik untuk browser desktop di semua sistem operasi.

Kami juga tidak terlalu peduli apakah seseorang menggunakan Firefox 40 atau Firefox 39: perbedaan antar versi dapat diabaikan dan pembaruan versi gratis dan seringkali otomatis. Untuk memudahkan pemahaman kami tentang statistik browser, kami menggabungkan versi semua browser desktop – kecuali IE. Kami tahu bahwa versi IE yang lebih lama bermasalah dan tersebar luas, jadi kami perlu melacak angka penggunaannya.

Argumen serupa berlaku untuk browser OS portabel. Kami tidak terlalu peduli dengan versi Chrome atau Firefox seluler, karena ini diperbarui secara berkala dan mudah – jadi kami menggabungkan versi tersebut. Tetapi sekali lagi, kami peduli dengan versi IE yang berbeda, jadi kami mencatat versinya secara terpisah.

Versi OS perangkat tidak relevan jika kita berbicara tentang Android; yang penting adalah versi browser asli Android yang digunakan, karena ini adalah browser yang terkenal bermasalah. Di sisi lain, versi iOS mana yang dijalankan perangkat sangat relevan karena versi Safari secara intrinsik terkait dengan OS. Lalu ada sejumlah besar browser asli untuk perangkat lain: ini merupakan persentase kecil dari keseluruhan audiens kami sehingga nomor versi mereka juga digabungkan.

Terakhir, kami memiliki gelombang baru browser yang popularitasnya meningkat pesat: browser dalam aplikasi, terutama diimplementasikan pada platform media sosial. Ini masih merupakan hal baru bagi kami, jadi kami ingin mendaftarkan semua platform browser dalam aplikasi dan OS masing-masing.

Setelah kami menggunakan pengetahuan pakar domain kami untuk menggabungkan statistik terkait, kami mempersempit daftar lebih lanjut dengan menghapus setiap browser yang membuat kurang dari 0,05% audiens kami (jangan ragu untuk menyesuaikan ambang ini sesuai dengan kebutuhan Anda sendiri).

Peramban desktop

Browser portabel

Browser dalam aplikasi

Setelah selesai, spreadsheet Anda akan terlihat seperti ini (abaikan kolom “Prioritas” untuk saat ini — kita akan membahasnya nanti):

Jadi sekarang Anda memiliki spreadsheet yang disederhanakan, menampilkan browser utama dari perspektif pengembang web, masing-masing terkait dengan persentase pangsa pasar total. Harap perhatikan bahwa Anda harus selalu memperbarui spreadsheet ini; memperbarui sekali per bulan harus cukup.

Anda sekarang siap untuk memulai serangan tiga fase.

1. Pengintaian: Temukan Bug Browser-Agnostik

Jauh sebelum Anda berpikir untuk mengeluarkan perangkat untuk diuji, lakukan hal termudah yang Anda bisa: buka aplikasi web Anda di browser favorit Anda. Kecuali jika Anda benar-benar masokis, ini mungkin Chrome atau Firefox, keduanya stabil dan mendukung fitur modern. Tujuan dari tahap pertama ini adalah untuk menemukan bug browser-agnostik .

Bug agnostik browser adalah kesalahan implementasi yang tidak ada hubungannya dengan browser atau perangkat keras yang digunakan untuk mengakses aplikasi Anda. Misalnya, katakanlah halaman web Anda ditayangkan dan Anda mulai mendapatkan laporan bug yang tidak jelas dari orang-orang yang mengeluh bahwa halaman Anda terlihat sampah di HTC One mereka dalam mode lanskap. Anda membuang banyak waktu untuk menentukan versi browser mana yang digunakan, menggunakan mode debug USB Android dan mencari bantuan di StackOverflow, bertanya-tanya bagaimana cara Anda memperbaikinya. Tanpa sepengetahuan Anda, bug ini tidak ada hubungannya dengan perangkat: sebaliknya, halaman Anda terlihat buggy pada lebar viewport tertentu, yang kebetulan merupakan lebar layar perangkat yang bersangkutan.

Ini adalah contoh bug browser-agnostik yang salah memanifestasikan dirinya sebagai bug khusus browser atau khusus perangkat. Anda telah dituntun ke jalan yang panjang dan sia-sia, dengan laporan bug bertindak sebagai kebisingan, mengaburkan akar penyebab masalah. Bantulah diri Anda sendiri dan tangkap bug semacam ini tepat di awal, dengan lebih sedikit usaha dan sedikit lebih banyak pandangan ke depan.

Dengan memperbaiki bug browser-agnostik bahkan sebelum kita memulai pengujian lintas-browser, kita harus menghadapi lebih sedikit bug secara keseluruhan. Saya suka menyebutnya efek gunung es yang mencair . Kami mencairkan serangga yang tersembunyi di bawah permukaan, menyelamatkan kami dari kecelakaan dan tenggelam di laut - dan kami bahkan tidak menyadari bahwa kami melakukannya.

Di bawah ini adalah daftar singkat hal-hal yang dapat Anda lakukan di browser pengembangan Anda untuk menemukan bug agnostik browser:

• Coba ubah ukuran untuk melihat responsivitas. Apakah ada breakpoint yang funky di mana saja?
• Perbesar dan perkecil. Apakah posisi latar belakang sprite gambar Anda miring?
• Lihat bagaimana aplikasi berperilaku dengan JavaScript dimatikan. Apakah Anda masih mendapatkan konten inti?
• Lihat tampilan aplikasi dengan CSS dimatikan. Apakah semantik markup masih masuk akal?
• Coba matikan JavaScript DAN CSS. Apakah Anda mendapatkan pengalaman yang dapat diterima?
• Cobalah berinteraksi dengan aplikasi hanya menggunakan keyboard Anda. Apakah mungkin untuk menavigasi dan melihat semua konten?
• Coba batasi koneksi Anda dan lihat seberapa cepat aplikasi dimuat. Seberapa berat pemuatan halaman?

Sebelum melanjutkan ke fase 2, Anda perlu memperbaiki bug yang Anda temui. Jika kami tidak memperbaiki bug browser-agnostik, kami hanya akan melaporkan banyak bug khusus browser palsu nanti.

Jadi malas. Perbaiki bug browser-agnostik. Kemudian kita bisa pindah ke fase kedua serangan.

2. Raid: Uji Di Browser Berisiko Tinggi Terlebih Dahulu

Saat kami memperbaiki bug, kami harus berhati-hati agar perbaikan kami tidak menimbulkan lebih banyak bug. Mengubah CSS kami untuk memperbaiki padding di Safari mungkin merusak padding di Firefox. Mengoptimalkan sedikit JavaScript agar berjalan lebih lancar di Chrome mungkin akan merusaknya sepenuhnya di IE. Setiap perubahan yang kita buat membawa risiko.

Untuk benar-benar yakin bahwa perubahan baru tidak merusak pengalaman di salah satu browser yang telah kami uji, kami harus kembali dan menguji di browser yang sama lagi. Oleh karena itu, untuk meminimalkan duplikasi usaha, kita harus pintar dalam melakukan pengujian.

Analisis statistik distribusi bug

Perhatikan tabel berikut, di mana ikon silang berarti browser memiliki bug.

Katakanlah kita akan menguji konten kita dalam urutan risiko: browser Risiko Rendah, browser Risiko Sedang, browser Risiko Tinggi. Jika membantu Anda untuk memvisualisasikan ini, browser ini mungkin memetakan masing-masing ke Google Chrome, IE 9 dan IE 6.

Menguji browser Risiko Rendah (Chrome) terlebih dahulu, kami akan menemukan dan memperbaiki bug #2. Saat kami pindah ke browser Risiko Sedang, bug #2 sudah diperbaiki, tetapi kami menemukan bug baru: #4. Kami mengubah kode kami untuk memperbaiki bug – tetapi bagaimana kami dapat memastikan bahwa kami tidak merusak sesuatu di browser Risiko Rendah? Kami tidak dapat sepenuhnya yakin, jadi kami harus kembali dan menguji di browser itu lagi untuk memverifikasi semuanya masih berfungsi seperti yang diharapkan.

Sekarang kita beralih ke browser Berisiko Tinggi dan menemukan bug #1, #3 dan #5, yang memerlukan pengerjaan ulang yang signifikan untuk diperbaiki. Setelah ini telah diperbaiki, apa yang harus kita lakukan? Kembali dan uji browser risiko Menengah dan Rendah lagi. Ini adalah banyak duplikasi usaha. Kami harus menguji tiga browser kami sebanyak enam kali.

Sekarang mari kita pertimbangkan apa yang akan terjadi jika kami menguji konten kami dalam urutan risiko yang menurun .

Langsung saja, kami akan menemukan bug #1, #3, #4 dan #5 di browser Risiko Tinggi. Setelah memperbaiki bug tersebut, kami akan langsung beralih ke browser Risiko Sedang dan menemukan bug #2. Seperti sebelumnya, perbaikan ini mungkin secara tidak langsung merusak sesuatu sehingga perlu kembali ke browser Berisiko Tinggi dan menguji ulang. Terakhir, kami menguji di browser Risiko Rendah dan tidak menemukan bug baru. Dalam hal ini, kami telah menguji tiga browser kami pada total empat kesempatan berbeda, yang merupakan pengurangan besar dalam jumlah waktu yang diperlukan untuk menemukan dan memperbaiki jumlah bug yang sama secara efektif dan memvalidasi perilaku dari jumlah browser yang sama. .

Mungkin ada tekanan pada pengembang untuk menguji di browser paling populer terlebih dahulu, bekerja dengan cara kami ke browser yang kurang banyak digunakan menjelang akhir pengujian kami. Namun, browser populer cenderung merupakan browser berisiko rendah.

Anda tahu bahwa Anda harus mendukung browser berisiko tinggi tertentu, jadi singkirkan browser itu sejak awal. Jangan sia-siakan upaya pengujian browser yang cenderung tidak menghasilkan bug, karena ketika Anda beralih ke browser yang menghasilkan lebih banyak bug, Anda hanya perlu kembali dan melihat browser berisiko rendah itu lagi.

Memperbaiki bug di browser yang buruk membuat kode Anda lebih tangguh di browser yang bagus

Seringkali Anda akan menemukan bahwa bug yang muncul di browser bermasalah ini adalah hasil yang tidak diharapkan dari kode yang buruk di pihak Anda. Anda mungkin canggung menata div agar terlihat seperti tombol, atau meretas di setTimeout sebelum memicu beberapa perilaku arbitrer; solusi yang lebih baik ada untuk kedua masalah ini. Dengan memperbaiki bug yang merupakan gejala kode buruk, kemungkinan besar Anda akan memperbaiki bug di browser lain bahkan sebelum Anda melihatnya. Ada efek gunung es yang mencair lagi.

Dengan memeriksa dukungan fitur, daripada menganggap browser mendukung sesuatu, Anda memperbaiki bug yang menyakitkan di IE8 tetapi Anda juga membuat kode Anda lebih kuat untuk lingkungan keras lainnya. Dengan memberikan image fallback untuk Opera Mini, Anda mendorong penggunaan peningkatan progresif dan sebagai produk sampingan, Anda meningkatkan produk Anda bahkan untuk pengguna browser yang tidak terlalu serius. Misalnya, perangkat seluler mungkin kehilangan koneksi 3G-nya dengan hanya setengah dari aset aplikasi Anda yang diunduh: pengguna kini mendapatkan pengalaman yang berarti yang tidak akan mereka dapatkan sebelumnya.

Namun berhati-hatilah: jika Anda tidak hati-hati, memperbaiki bug di browser yang tidak jelas dapat memperburuk kode Anda . Tahan godaan untuk mengendus string agen pengguna untuk mengirimkan konten secara kondisional ke browser tertentu, misalnya. Itu mungkin memperbaiki bug, tetapi merupakan praktik yang sama sekali tidak berkelanjutan. Jangan kompromikan integritas kode yang baik untuk mendukung browser yang canggung.

Mengidentifikasi Browser Bermasalah

Jadi apa itu browser berisiko tinggi? Jawabannya sedikit kaku dan tergantung pada fitur browser yang digunakan aplikasi Anda. Jika JavaScript Anda menggunakan indexOf , itu mungkin rusak di IE 8. Jika aplikasi Anda menggunakan position: fixed , Anda akan ingin memeriksanya di Safari di iOS 7.

Can I Use adalah sumber daya yang tak ternilai dan tempat yang baik untuk memulai, tetapi ini adalah salah satu area yang sekali lagi berasal dari pengalaman dan intuisi pengembang. Jika Anda meluncurkan aplikasi web secara teratur, Anda akan tahu browser mana yang menunjukkan masalah berulang kali, dan Anda dapat menyempurnakan strategi pengujian untuk mengakomodasi hal ini.

Hal bermanfaat tentang bug yang Anda temukan di browser bermasalah adalah bahwa mereka akan sering menyebar. Jika ada bug di IE9, kemungkinan bug itu juga ada di IE8. Jika ada sesuatu yang terlihat funky di Safari di iOS 7, mungkin akan terlihat lebih jelas di iOS 6. Perhatikan sebuah pola di sini? Browser yang lebih tua cenderung yang bermasalah. Itu akan membantu Anda membuat daftar browser bermasalah yang cukup bagus.

Karena itu, lakukan back up ini dengan statistik penggunaan. Sebagai contoh, IE 6 adalah browser yang sangat bermasalah, tetapi kami tidak repot-repot mengujinya karena total pangsa pasarnya terlalu rendah. Waktu yang dihabiskan untuk memperbaiki bug khusus IE6 tidak akan sebanding dengan upaya untuk sejumlah kecil pengguna yang pengalamannya akan ditingkatkan.

Tidak selalu browser lama yang ingin Anda uji dalam fase serangan. Misalnya, jika Anda memiliki proyek kanvas WebGL 3D eksperimental dengan fallback gambar, browser lama hanya akan mendapatkan gambar fallback, jadi kami tidak akan menemukan banyak bug. Yang ingin kami lakukan adalah mengubah pilihan browser bermasalah kami berdasarkan aplikasi yang ada. Dalam hal ini, IE9 mungkin merupakan browser yang baik untuk diuji karena merupakan versi pertama IE yang mendukung kanvas.

Peramban proxy modern (seperti Opera Mini) juga dapat menjadi pilihan yang baik untuk uji serangan, jika aplikasi Anda menggunakan fitur CSS3 seperti gradien atau radius batas. Kesalahan umum adalah merender teks putih pada gradien yang tidak didukung, menghasilkan teks putih-putih yang tidak terbaca.

Saat memilih browser Anda yang bermasalah, gunakan intuisi Anda dan cobalah untuk mendahului di mana bug mungkin bersembunyi.

Diversifikasi Peramban Bermasalah Anda

Peramban dan versi peramban hanyalah satu bagian dari persamaan: perangkat keras juga merupakan pertimbangan yang signifikan. Anda ingin menguji aplikasi Anda pada berbagai ukuran layar dan kepadatan piksel yang berbeda, dan mencoba beralih antara mode potret dan lanskap.

Mungkin tergoda untuk mengelompokkan browser terkait bersama-sama karena ada diskon yang dirasakan pada biaya usaha. Jika Anda sudah memiliki VirtualBox yang terbuka untuk menguji IE8, sekarang mungkin waktu yang tepat untuk menguji di IE9, IE10 dan IE11 juga. Namun, jika Anda berada di tahap awal pengujian aplikasi web, Anda sebaiknya melawan godaan ini dan sebagai gantinya memilih tiga atau empat kombinasi perangkat keras browser yang sangat berbeda satu sama lain, untuk mendapatkan cakupan sebanyak totalnya. ruang bug yang Anda bisa.

Meskipun ini dapat bervariasi dari satu proyek ke proyek lainnya, berikut adalah browser pilihan saya yang bermasalah saat ini:

• IE 8 pada VM Windows XP;
• Browser Android 2 asli pada tablet Android kelas menengah;
• Safari di iPhone 4 yang menjalankan iOS 6;
• Opera mini (hanya benar-benar layak untuk diuji dengan konten yang seharusnya berfungsi tanpa JavaScript, seperti datapics).

Jadi malas. Temukan bug sebanyak mungkin dengan melemparkan aplikasi Anda ke browser dan perangkat yang paling bermasalah yang didukung. Dengan bug ini diperbaiki, Anda kemudian dapat pindah ke fase terakhir serangan.

3. Izin: pemeriksaan kewarasan

Anda sekarang telah menguji aplikasi Anda di browser paling keras yang harus Anda dukung, semoga menangkap sebagian besar bug. Tetapi aplikasi Anda belum sepenuhnya bebas bug. Saya terus-menerus terkejut dengan betapa berbedanya Chrome dan Firefox versi terbaru dalam membuat konten yang sama. Anda masih perlu melakukan beberapa pengujian lagi.

Itu aturan lama 80:20. Secara kiasan, Anda telah memperbaiki 80% bug setelah menguji 20% browser. Sekarang yang ingin Anda lakukan adalah memverifikasi pengalaman 80% audiens Anda melalui pengujian 20% browser yang berbeda.

Memprioritaskan browser

Pendekatan sederhana dan jelas sekarang adalah beralih kembali ke pengujian lintas-browser 'tradisional', dengan menangani setiap browser dalam urutan pangsa pasar yang menurun. Jika desktop Chrome merupakan proporsi tertinggi dari pangsa browser audiens Anda, diikuti oleh Safari di iOS 8, diikuti oleh IE11, maka masuk akal untuk menguji dalam urutan itu, bukan?

Itu adalah sistem yang sebagian besar adil, dan saya tidak ingin terlalu memperumit langkah ini jika sumber daya Anda sudah terkuras. Namun, faktanya, tidak semua browser diciptakan sama. Di tim saya, kami mengelompokkan browser menurut pohon keputusan yang memperhitungkan penggunaan browser, kemudahan peningkatan, dan apakah browser tersebut adalah default OS atau tidak.

Sampai sekarang, spreadsheet Anda harus memiliki kolom untuk browser dan kolom untuk pangsa pasarnya; Anda sekarang membutuhkan kolom ketiga, yang menunjukkan prioritas mana yang menjadi prioritas browser. Sejujurnya, pekerjaan prioritas ini seharusnya dilakukan sebelum meluncurkan serangan tiga fase, tetapi untuk tujuan artikel ini, lebih masuk akal untuk menggambarkannya di sini karena prioritas tidak benar-benar diperlukan sampai fase pembersihan.

Berikut adalah pohon keputusan kami:

Kami telah merancang pohon keputusan kami sehingga browser P1 mencakup sekitar 70% audiens kami. Gabungan browser P1 dan P2 mencakup sekitar 90% audiens kami. Terakhir, browser P1, P2, dan P3 memberi kami cakupan audiens yang hampir lengkap. Kami bertujuan untuk menguji di semua browser P1, diikuti oleh P2, diikuti oleh P3, dalam urutan pangsa pasar yang menurun.

Seperti yang dapat Anda lihat di spreadsheet sebelumnya di artikel ini, kami hanya memiliki beberapa browser P1. Fakta bahwa kami dapat memverifikasi pengalaman lebih dari 70% audiens kami dengan sangat cepat berarti kami memiliki sedikit alasan untuk tidak menguji ulang di browser tersebut jika basis kode berubah. Saat kami beralih ke browser P2 dan P3, kami harus meningkatkan upaya untuk memverifikasi pengalaman ukuran audiens yang terus berkurang, jadi kami harus menetapkan ideal pengujian yang lebih realistis untuk browser dengan prioritas lebih rendah. Sebagai pedoman:

• P1 . Kita harus memeriksa kewarasan di browser ini sebelum keluar dari aplikasi. Jika kita membuat perubahan kecil pada kode kita, maka kita harus memeriksa kewarasan di browser ini lagi.
• P2 . Kita harus memeriksa kewarasan di browser ini sebelum keluar dari aplikasi. Jika kita membuat perubahan besar pada kode kita, maka kita harus memeriksa kewarasan di browser ini lagi.
• P3 . Kita harus memeriksa kewarasan di browser ini sekali, tetapi hanya jika kita punya waktu.

Jangan lupa kebutuhan untuk mendiversifikasi perangkat keras Anda. Jika Anda dapat menguji pada banyak ukuran layar yang berbeda dan pada perangkat dengan berbagai kemampuan perangkat keras saat mengikuti daftar ini, lakukanlah.

Ringkasan: serangan tiga fase

Setelah Anda berupaya untuk mengetahui musuh Anda ( menyederhanakan statistik audiens dan mengelompokkan browser ke dalam prioritas ), Anda dapat menyerang dalam tiga langkah:

1. Pengintaian : pengujian eksplorasi pada browser favorit Anda, untuk menemukan bug browser-agnostik .
2. Raid : pengujian pada browser Anda yang paling bermasalah yang didukung pada berbagai perangkat keras, untuk menemukan sebagian besar bug .
3. Izin : memverifikasi pengalaman aplikasi Anda pada browser yang paling banyak digunakan dan penting secara strategis, untuk mengatakan dengan keyakinan yang didukung secara kuantitatif bahwa aplikasi Anda berfungsi .