Belajar Selenium - Cross-browser Testing Strategies

#Pendahuluan

Pengguna kalian tidak semua memakai Chrome. Sebagian membuka aplikasi di Firefox, Edge, Safari, atau browser mobile. Cross-browser testing memastikan aplikasi berperilaku sama di semua browser yang didukung. Episode 14 membahas strategi menjalankan suite di banyak browser secara efisien dan terstruktur.

Keunggulan Selenium yang sudah dibahas di episode 1 — dukungan lintas browser — sekarang kita wujudkan: pola factory untuk membangun driver, strategi compatibility testing, pengelolaan quirk spesifik browser, dan cloud browser farms yang memberi akses ke ratusan kombinasi browser tanpa memiliki perangkat kerasnya.

#Menjalankan Test di Chrome, Firefox, Edge, dan Safari

#Factory Pattern untuk Browser

Daripada menulis konstruktor terpisah di setiap test, bangun satu factory yang menghasilkan driver sesuai nama browser:

Factory pembuat driver

from selenium import webdriver
 
 
def buat_driver(browser, headless=False):
    if browser == "chrome":
        opsi = webdriver.ChromeOptions()
        if headless:
            opsi.add_argument("--headless")
        return webdriver.Chrome(options=opsi)
    if browser == "firefox":
        opsi = webdriver.FirefoxOptions()
        if headless:
            opsi.add_argument("-headless")
        return webdriver.Firefox(options=opsi)
    if browser == "edge":
        return webdriver.Edge()
    raise ValueError(f"Browser tidak dikenal: {browser}")
 
 
driver = buat_driver("firefox", headless=True)

Fungsi buat_driver(browser, headless=False) memusatkan logika pembuatan driver. Menambah browser baru cukup menambah satu cabang if, dan seluruh test memakai satu jalur yang sama.

#Safari di macOS

Safari memerlukan aktor safaridriver yang diaktifkan lewat perintah sistem:

safaridriver --enable

Perintah safaridriver --enable mengaktifkan driver Safari di macOS. Perlu diingat: Safari hanya berjalan di macOS, sehingga untuk CI berbasis Linux kalian membutuhkan Mac runner atau cloud farm.

#Pola Cross-browser Compatibility

#Menentukan Matriks Browser yang Realistis

Jangan menguji di semua kombinasi browser dan versi. Tentukan matriks berdasarkan data analitik pengguna:

• Chrome dan Edge: mayoritas pengguna desktop — selalu diuji.
• Firefox: diuji di suite inti, tidak di semua test.
• Safari: diuji untuk flow bisnis paling penting.
• Versi lama: hanya versi yang masih dipakai signifikan oleh pengguna.

Matriks browser per suite

MATRIKS_INTI = ["chrome", "firefox"]
MATRIKS_KRITIS = ["chrome", "firefox", "safari"]

MATRIKS_INTI = ["chrome", "firefox"] dan MATRIKS_KRITIS memisahkan tingkat cakupan. Test bisnis kritis jalan di semua browser, test fungsional lain cukup di dua browser utama — keseimbangan antara cakupan dan biaya.

#Test Kritis vs Test Non-Kritis

Pisahkan test lintas browser berdasarkan nilai bisnisnya. Checkout, login, dan dashboard adalah kandidat untuk diuji lintas browser; test minor seperti warna tombol cukup di satu browser. Prinsip ini menjaga biaya cross-browser tetap proporsional dengan risikonya.

#Mengelola Browser-specific Quirks

Setiap browser punya perilaku khas. Yang paling sering ditemui:

• Render timing berbeda: elemen muncul lebih lambat di Firefox — pakai wait eksplisit, bukan asumsi waktu.
• Scroll behavior berbeda: Safari dan Firefox menangani scrollIntoView dengan nuansa berbeda.
• Perbedaan CSS kecil: margin beberapa pixel — jangan di-assert ketat.

Abstraksi quirk per browser

def klik_saat_terlihat(driver, locator):
    if driver.capabilities["browserName"] == "safari":
        driver.execute_script("arguments[0].scrollIntoView(true);", locator)
    driver.find_element(*locator).click()

driver.capabilities["browserName"] memberi tahu browser yang aktif. Dengan abstraksi seperti klik_saat_terlihat(...), quirk diselesaikan di satu tempat, bukan tersebar di seluruh test.

#Cloud Browser Farms

#BrowserStack dan Sauce Labs

Cloud farm memberi akses ke ratusan kombinasi browser dan OS tanpa perangkat keras sendiri. Test tetap memakai webdriver.Remote, hanya URL dan capabilities yang berbeda:

Remote ke BrowserStack

from selenium import webdriver
 
caps = {
    "browserName": "Chrome",
    "browserVersion": "126",
    "os": "Windows",
    "osVersion": "11",
    "name": "Test Checkout",
}
 
driver = webdriver.Remote(
    command_executor="https://username:access_key@hub.browserstack.com/wd/hub",
    desired_capabilities=caps,
)

webdriver.Remote(..., desired_capabilities=caps) membuka sesi di cloud farm. Kredensial username:access_key diambil dari environment, bukan ditulis langsung di kode.

#Kapan Memakai Cloud Farm

Cloud farm sangat berguna untuk Safari dan versi browser lama yang sulit dihadirkan di mesin lokal. Pertimbangkan biayanya: untuk kebutuhan harian, kombinasi lokal (Chrome, Firefox, Edge) plus grid sudah memadai; cloud farm dicadangkan untuk matriks lengkap sebelum release.

#Penutup

Episode 14 memberi kalian kendali penuh atas cakupan lintas browser: factory driver yang terpusat, matriks browser yang disesuaikan dengan risiko bisnis, abstraksi quirk spesifik browser, dan pemanfaatan cloud farm untuk kombinasi yang tidak bisa dihadirkan secara lokal.

Inti yang harus dibawa pulang:

• Factory pattern memusatkan pembuatan driver semua browser.
• Tentukan matriks browser berdasarkan data pengguna dan risiko bisnis.
• Uji lintas browser hanya untuk flow yang bernilai dan berisiko.
• Abstraksi quirk per browser agar perbaikan terpusat.
• Cloud farm untuk Safari dan kombinasi langka; lokal plus grid untuk harian.

Di episode 15 selanjutnya kita akan membahas performance testing dan visual regression — pengantar pengukuran performa browser, integrasi dengan Lighthouse atau tool performa, visual regression dengan perbandingan screenshot, dan deteksi layout regression serta UI drift.