Belajar Selenium - Operational Readiness & Runbooks

#Pendahuluan

Suite test yang sudah berjalan di CI adalah sistem produksi — dan sistem produksi butuh prosedur operasional. Episode 19 membahas operational readiness: runbook untuk menangani broken tests, strategi menghadapi maintenance window dan environment drift, proses triage kegagalan yang disiplin, dan kepemilikan test dalam tim.

Banyak tim membangun suite dengan semangat, lalu kehilangan semangat begitu suite mulai menuntut perhatian rutin. Perbedaannya ada pada prosedur: tim yang punya runbook dan aturan kepemilikan akan menangani kegagalan dengan tenang, sementara tim tanpa prosedur akan panik setiap CI merah.

#Runbook untuk Broken Tests

#Struktur Runbook

Runbook adalah dokumen langkah demi langkah untuk merespons insiden. Untuk broken tests, buat template yang menjawab tiga pertanyaan: apa gejalanya, bagaimana mendiagnosis, dan bagaimana memulihkan.

Judul: Test X gagal di CI
1. Lihat artifact screenshot dari job.
2. Cek log test untuk langkah terakhir yang berhasil.
3. Cek versi browser yang dipakai vs versi driver.
4. Reproduksi lokal dengan perintah yang sama.
5. Jika berulang, buat ticket dan assign ke pemilik test.

Template di atas adalah contoh struktur runbook. Langkah-langkahnya terurut dari bukti termurah — screenshot dan log — hingga investigasi penuh, sehingga siapa pun bisa mengikuti tanpa pengalaman mendalam.

#Runbook dalam Repository

Simpan runbook di repository, misalnya docs/runbooks/ agar bisa di-update bersama kode. Runbook yang hidup di laci dokumen pribadi tidak akan pernah dibaca saat dibutuhkan.

#Maintenance Window dan Environment Drift

#Maintenance Window untuk Test

Test juga butuh waktu pemeliharaan terjadwal. Buat agenda berkala — misalnya mingguan — untuk membersihkan test usang, memperbarui selector yang berubah, dan memverifikasi baseline visual. Tanpa maintenance window, kotoran menumpuk sampai menjadi proyek besar.

#Environment Drift

Environment drift terjadi ketika environment test berbeda dari produksi atau berubah diam-diam: versi browser berubah, data test kedaluwarsa, atau staging di-reset. Deteksi drift dengan menyimpan catatan environment:

google-chrome --version
chromedriver --version

google-chrome --version dan chromedriver --version mencatat versi yang dipakai. Catat kedua angka ini di log setiap run — perubahan versi adalah salah satu penyebab paling umum broken test yang tidak berkaitan dengan kode.

#Mengelola Test Suite dan Triage Kegagalan

#Prioritas Triage

Tidak semua kegagalan sama. Terapkan triage berlapis:

1. Infrastruktur: grid mati, browser gagal start — perbaiki environment dulu.
2. Automasi: selector patah, wait kurang — koreksi test.
3. Produk: behavior aplikasi berubah — konfirmasi dengan tim produk.

Skrip triage ringkas

def klasifikasi_gagal(pesan):
    if "session not created" in pesan:
        return "infrastruktur"
    if "no such element" in pesan:
        return "automasi"
    return "produk"

Fungsi klasifikasi_gagal(pesan) adalah contoh otomasi triage sederhana berdasarkan pesan error. Mengklasifikasikan kegagalan sebelum memburu detail membuat upaya tim terarah.

#Metrik Triage

Lacak jumlah kegagalan per kategori setiap minggu. Jika kategori "automasi" mendominasi, suite butuh perbaikan kualitas; jika "produk" yang dominan, aplikasi yang berubah terlalu cepat — keduanya butuh pendekatan berbeda.

#Recovery untuk Kompatibilitas Browser

#Langkah Recovery Standar

Browser auto-update tanpa izin adalah penyebab klasik broken test. Runbook recovery untuk ini singkat dan jelas:

google-chrome --version
pip show selenium | grep -i version

Jika test rusak setelah update browser, periksa kompatibilitas: driver harus cocok dengan browser (episode 3), dan API Selenium yang dipakai harus didukung versi browser tersebut. Selenium Manager biasanya menyelesaikan ini otomatis; untuk kasus khusus, kunci versi browser di CI.

#Kunci Versi Browser di CI

Untuk stabilitas maksimal, gunakan image CI dengan versi browser yang terkunci, seperti image Selenium resmi yang sudah berpasangan dengan driver:

services:
  chrome:
    image: selenium/standalone-chrome:132.0

selenium/standalone-chrome:132.0 mengunci versi Chrome dan driver sekaligus. Mengunci versi menunda masalah — tim mendapat waktu untuk menyesuaikan sebelum update berikutnya.

#Team Ownership dan Pemeliharaan Test

#Satu Test, Satu Pemilik

Setiap test harus punya pemilik yang jelas. Ini bukan birokrasi — ini mencegah "tragedy of the commons" di mana semua orang menganggap test rusak adalah urusan orang lain. Peta kepemilikan cukup sederhana:

• Suite e-commerce: tim checkout.
• Suite login dan akun: tim identity.
• Infrastruktur test: tim platform/QA.

#Menjadikan Pemeliharaan Ritme Tim

Jadwalkan pemeliharaan sebagai aktivitas tim, bukan hukuman untuk satu orang. Review test yang paling sering gagal, pelajari polanya, dan perbaiki bersama. Suite yang dipelihara bersama akan hidup lebih lama daripada suite yang dirawat oleh satu orang yang pergi.

#Penutup

Episode 19 mengubah suite kalian dari "koleksi script" menjadi "sistem dengan prosedur": runbook untuk broken tests, strategi maintenance window dan anti-drift, triage kegagalan yang berlapis, recovery kompatibilitas browser, serta kepemilikan test yang jelas di dalam tim.

Inti yang harus dibawa pulang:

• Runbook memberi langkah terurut untuk merespons broken tests.
• Catat versi browser dan driver untuk mendeteksi environment drift.
• Triage kegagalan: infrastruktur dulu, lalu automasi, lalu produk.
• Kunci versi browser di CI untuk stabilitas, dan samakan bila rusak.
• Setiap test punya pemilik; pemeliharaan adalah aktivitas tim terjadwal.

Di episode 20 selanjutnya kita akan membahas real-world use cases dan patterns — contoh use case e-commerce checkout, login flow, dan interaksi dashboard, pola desain test untuk automasi end-to-end, perbedaan component-level dan full UI test, serta cara memprioritaskan test untuk flow yang kritis bagi bisnis.