Belajar Playwright - Operational Readiness & Runbooks

#Pendahuluan

Suite yang sehat bukan hanya soal test yang hijau hari ini — ia soal bagaimana tim bereaksi saat test gagal, siapa yang bertanggung jawab, dan bagaimana memulihkan diri setelah masalah. Episode 19 ini membahas operational readiness: runbook, ownership, dan proses maintenance yang membuat suite bisa dikelola dalam jangka panjang.

Seperti operasi produksi, test suite perlu prosedur. Runbook menjawab "apa yang harus kulakukan saat ini?" saat test flaky, environment drift, atau browser failure. Ownership menjawab "siapa yang menyelesaikan ini?" Dan maintenance menjawab "kapan kita merawat suite sebelum rusak?" Ketiganya akan kita susun satu per satu.

#Runbook untuk Flaky Tests, Environment Drift, dan Browser Failures

#Runbook Flaky Test

Test flaky adalah test yang kadang lolos, kadang gagal tanpa perubahan kode. Ini runbook langkah demi langkah:

1. Ambil trace dan artifact dari CI — jangan menebak.
2. Periksa apakah kegagalan berhubungan dengan timing atau locator.
3. Buka trace viewer dan amati langkah yang gagal.
4. Jika masalahnya locator, ganti dengan getByRole atau getByTestId.
5. Jika masalahnya timing, ganti waitForTimeout dengan menunggu kondisi.
6. Tambahkan retry sementara, tapi tetap tandai untuk investigasi root cause.

[ ] Ambil trace dari CI
[ ] Identifikasi langkah yang gagal
[ ] Periksa locator dan timing
[ ] Perbaiki root cause, bukan gejala

#Runbook Environment Drift

Environment drift terjadi ketika CI berbeda dari lokal — versi Node, browser, atau dependency tidak sinkron. Deteksi dan langkahnya:

• Bandingkan npx playwright --version di CI dan lokal.
• Pastikan lockfile (package-lock.json atau bun.lock) di-commit.
• Gunakan image atau action Playwright resmi yang sudah berisi dependencies.
• Pastikan seed data dan environment variables identik.

#Runbook Browser Failure

Browser tidak bisa diluncurkan biasanya karena dependency sistem hilang di Linux CI. Solusinya:

npx playwright install --with-deps

npx playwright install --with-deps menginstall browser beserta dependencies sistem. Jika runner CI sudah memakai image resmi Playwright, dependencies ini sudah ada — jadi pilih image yang sesuai dengan versi Playwright kalian.

#Managing Test Suite Health dan Team Ownership

#Metrik Kesehatan Suite

Kesehatan suite bisa diukur dengan metrik sederhana yang dipantau rutin:

• Flakiness rate: persentase test yang gagal lalu lolos setelah retry.
• Durasi total: waktu yang dibutuhkan seluruh suite berjalan.
• Skip/fixme count: berapa banyak test yang tidak aktif dan alasannya.
• Coverage fitur: berapa persen alur bisnis penting yang punya test.

npx playwright test --reporter=json --output=report.json

--reporter=json menghasilkan data terstruktur yang bisa diolah script untuk memantau metrik kesehatan secara otomatis.

#Kepemilikan Suite

Setiap test suite butuh pemilik yang jelas — bukan "semua orang" yang berarti tidak ada orang. Tetapkan ownership per area: tim frontend memegang test UI, tim backend memegang test API, dan ada satu koordinator yang menjaga konfigurasi dan infrastruktur suite.

#Code Review untuk Test

Perlakukan test seperti kode produksi: setiap perubahan test harus melewati review. Ini mencegah perubahan yang menurunkan kualitas — misalnya menghapus assertion untuk membuat test lolos, atau menambah waitForTimeout untuk menutupi masalah.

#Recovery Strategy Saat Test Baseline Berubah

#Baseline Berubah Secara Sengaja

Saat desain berubah, baseline visual (episode 16) harus diperbarui. Prosedur yang aman:

1. Jalankan visual test dan periksa setiap diff.
2. Konfirmasi bahwa perubahan memang sesuai desain baru.
3. Update baseline dengan --update-snapshots.
4. Review diff di PR agar semua orang melihat apa yang berubah.

#Baseline Berubah Tanpa Disengaja

Jika diff muncul tanpa ada perubahan desain, itu alarm — jangan update baseline untuk menutupinya. Selidiki penyebabnya: mungkin font berubah, konten dinamis ikut ter-render, atau environment rendering berbeda.

#Menangani Perubahan Besar

Untuk perubahan besar (redesign seluruh halaman), bekukan visual test sementara, selesaikan perubahan, lalu regenerate baseline dari kondisi yang benar. Dokumentasikan periode freeze agar tim memahami kenapa visual test tidak berjalan saat itu.

#Maintenance Schedule dan Cleanup Tasks

#Jadwal Maintenance Rutin

Suite butuh perawatan berkala, bukan hanya saat rusak. Jadwal yang sehat:

• Mingguan: cek flakiness rate dan test yang sering gagal.
• Per sprint: audit skip dan fixme, tambah test untuk fitur baru.
• Per rilis: tinjau durasi suite, perbarui baseline visual, hapus test usang.

#Cleanup Test Usang

Fitur yang dihapus menyisakan test yang mati. Hapus test usang bersamaan dengan fiturnya — test yang menunjuk fitur yang sudah tidak ada hanya menambah runtime dan kebingungan.

[ ] Hapus test untuk fitur yang sudah dihapus
[ ] Perbarui locator yang menyebut elemen lama
[ ] Verifikasi fixture dan helper yang masih dipakai
[ ] Perbarui snapshot baseline setelah desain berubah

#Menjadwalkan Pembersihan Artifact

Artifact test (screenshot, video, trace) cepat mengisi storage. Atur retention di CI — GitHub Actions bisa menyetel retention-days, dan folder test-results lokal bisa dibersihkan otomatis:

rm -rf test-results playwright-report

Perintah rm -rf test-results playwright-report membersihkan hasil test lokal. Biasakan menjalankannya berkala agar workspace tidak membengkak dengan artifact lama.

#Penutup

Episode 19 melengkapi kalian dengan sisi operasional testing: runbook untuk tiga kegagalan paling umum, metrik dan ownership untuk menjaga kesehatan suite, prosedur recovery saat baseline berubah, serta jadwal maintenance dan cleanup yang mencegah pembusukan diam-diam.

Inti yang harus dibawa pulang:

• Runbook mempercepat respons terhadap flaky, environment drift, dan browser failure.
• npx playwright install --with-deps menyelesaikan mayoritas browser failure di Linux CI.
• Pantau metrik kesehatan suite dan tetapkan ownership per area.
• Perbarui baseline hanya saat perubahan memang disengaja dan terverifikasi.
• Jadwalkan maintenance berkala dan bersihkan artifact serta test usang.

Di episode 20 selanjutnya kita akan membahas real-world use cases dan patterns — contoh kasus nyata checkout e-commerce, signup flow, dan dashboard workflows, pola desain test untuk end-to-end automation, keseimbangan UI test dengan API dan component test, serta prioritas test untuk jalur bisnis kritis.