Belajar Selenium - Test Stability & Flakiness

#Pendahuluan

Tidak ada yang lebih menguras kepercayaan tim terhadap automasi selain flaky test — test yang kadang lulus, kadang gagal, tanpa perubahan apa pun. Tim yang terus menerus dihantui test random akan mulai mengabaikan hasil CI, dan suite kehilangan nilai sepenuhnya. Episode 13 membahas cara memberantas flakiness dari akar.

Kita akan membedah sumber-sumber flakiness, membangun selector yang reliable, menerapkan retry dan deteksi flaky yang benar, serta memonitor stabilitas suite sebagai metrik yang dijaga seperti metrik lainnya.

#Sumber-sumber Flakiness

Sebelum memperbaiki, kenali penyebabnya. Lima sumber flakiness paling umum di automasi Selenium:

• Timing: elemen belum muncul ketika dicari — diatasi dengan wait yang benar (episode 5).
• Selector lemah: locator yang cocok dengan banyak elemen atau berubah dengan layout.
• State bersama: test saling memengaruhi lewat data atau sesi yang dipakai bersama.
• Environment: browser, driver, atau resource mesin yang tidak stabil.
• Urutan eksekusi: test yang lulus hanya jika berjalan setelah test lain.

timing -> selector -> shared state -> environment -> test order

timing -> selector -> shared state -> environment -> test order adalah urutan pengecekan yang disarankan: periksa yang paling sering terjadi lebih dulu.

#Selector yang Reliable

#Aturan Memilih Locator

Kualitas selector menentukan sebagian besar stabilitas suite. Aturan yang kami terapkan di semua project:

• Prioritaskan id dan data-testid yang dibuat khusus untuk testing.
• Hindari locator berbasis teks yang mudah berubah dengan kopi baru.
• Hindari index seperti div[2] yang rapuh terhadap perubahan struktur.
• Jangan terlalu panjang — locator yang spesifik berlebihan juga mudah patah.

Selector kuat vs lemah

# Kuat: atribut khusus test
driver.find_element("css selector", "[data-testid='tombol-beli']")
 
# Lemah: posisi dan kelas generik
driver.find_element("css selector", "div.wrapper > div:nth-child(2) > button.btn")

Pola [data-testid='tombol-beli'] jauh lebih stabil daripada div.wrapper > div:nth-child(2) > button.btn. Jika tim produk mau bekerja sama menambahkan data-testid, investasi ini membayar berkali-kali lipat di stabilitas suite.

#Konsistensi di Seluruh Suite

Selector yang sama untuk elemen yang sama harus dipakai di semua test. Ini bukan sekadar kerapian — ini mencegah dua test mengacu ke elemen yang sama dengan dua cara berbeda, sehingga satu perubahan layout hanya merusak satu titik.

#Retry Strategy dan Deteksi Flaky

#Retry sebagai Jaring Pengaman Sementara

Retry bukan solusi permanen, tapi bisa menyelamatkan pipeline sementara akar masalah diburu. Plugin pytest-rerunfailures menyediakan retry per test:

pip install pytest-rerunfailures

Setelah pip install pytest-rerunfailures, tandai test yang butuh retry:

Retry per test

@pytest.mark.flaky(reruns=2, reruns_delay=1)
def test_checkout():
    ...

@pytest.mark.flaky(reruns=2, reruns_delay=1) mengulang test hingga dua kali dengan jeda satu detik. Penting: setiap test yang butuh retry harus memiliki ticket perbaikan — retry tanpa penyelidikan hanya menyembunyikan masalah.

#Mendeteksi Flaky Test

Cara paling efektif mendeteksi flaky: jalankan test berulang kali dan lihat yang gagal sesekali:

pytest tests/test_checkout.py -n 4 --count 3

pytest tests/test_checkout.py -n 4 --count 3 (dengan plugin pytest-repeat) menjalankan test berkali-kali. Test yang sesekali gagal adalah kandidat flaky yang harus diselidiki sebelum mencemari suite.

#Monitoring Stabilitas Eksekusi

Stabilitas adalah metrik yang bisa diukur. Lacak tiga angka di setiap run CI:

• Pass rate: persentase test yang lulus.
• Flaky rate: test yang berganti hasil antara run.
• Durasi: waktu yang dibutuhkan suite penuh.

Simpan angka ini di laporan atau dashboard sederhana. Ambang batas yang kami sarankan: pass rate di atas 99% dan flaky rate mendekati nol — bila meleset, prioritas tim adalah stabilisasi, bukan menambah test baru.

#Best Practice untuk Stable Automation Suite

Ringkasan kebiasaan yang menjaga suite tetap stabil dalam jangka panjang:

• Isolasi test: setiap test menyiapkan data sendiri, tidak bergantung pada test lain.
• Teardown wajib: tutup driver dan bersihkan data, apa pun hasil test.
• Gunakan wait eksplisit untuk interaksi penting, bukan sleep statis.
• Kombinasikan dengan API setup (episode 16) untuk melewati UI yang lambat.
• Jadwalkan pemeriksaan flaky sebagai ritual mingguan tim.

Fixture isolasi sederhana

@pytest.fixture
def data_test():
    pengguna = buat_pengguna_unik()
    yield pengguna
    hapus_pengguna(pengguna.id)

buat_pengguna_unik() menjamin setiap test punya data sendiri. Pola buat-pakai-hapus ini mencegah tabrakan data yang menjadi biang flaky.

#Penutup

Episode 13 mengubah cara tim memandang flaky test: bukan gangguan acak yang ditoleransi, melainkan bug yang harus diburu. Kalian kini mengenali lima sumber flakiness, membangun selector reliable berbasis data-testid, menerapkan retry sebagai jaring sementara, dan memonitor pass rate sebagai metrik tim.

Inti yang harus dibawa pulang:

• Lima sumber flakiness: timing, selector, shared state, environment, test order.
• Selector id dan data-testid jauh lebih stabil daripada posisi atau teks.
• Retry adalah penanganan sementara, bukan pengganti perbaikan akar masalah.
• Isolasi data test mencegah tabrakan antar test.
• Pantau pass rate dan flaky rate sebagai metrik stabilitas tim.

Di episode 14 selanjutnya kita akan membahas cross-browser testing strategies — menjalankan test di Chrome, Firefox, Edge, dan Safari, pola compatibility testing, mengelola browser-specific quirks, serta memakai cloud browser farms seperti BrowserStack dan Sauce Labs.