Belajar Cypress - Operational Readiness & Runbooks

#Pendahuluan

Suite yang sehat tidak tercipta sekali jadi — ia dirawat seperti sistem produksi. Episode 19 membahas sisi operasional: runbook untuk flaky tests dan environment drift, incident response untuk run CI yang gagal, pemantauan coverage dan health, serta pembagian kepemilikan dan rutinitas perawatan.

Pada akhir episode ini, tim kalian memiliki prosedur — bukan hanya reaksi — saat suite mulai bermasalah.

#Runbook untuk Flaky Tests dan Environment Drift

#Mendefinisikan Runbook

Runbook adalah dokumen langkah-demi-langkah untuk situasi yang terduga. Untuk flaky test, mulailah dari diagnosis:

1. Reproduksi: jalankan spec 3x, catat pola kegagalan.
2. Periksa timing: adakah cy.wait(ms) atau elemen perantara?
3. Periksa data: adakah ketergantungan pada data yang berubah?
4. Perbaiki akar masalah, bukan hanya menambah retries.

Baris 1. Reproduksi: jalankan spec 3x, catat pola kegagalan. adalah langkah pertama yang wajib. Runbook mengubah perbaikan flaky dari menebak-nebak menjadi proses yang bisa diikuti siapa pun.

#Menangani Environment Drift

Environment drift terjadi saat environment test berbeda dengan produksi atau berubah tanpa disadari. Verifikasi lingkungan di awal run:

Mengecek environment di CI

describe("Sanity check", () => {
  it("environment siap untuk test", () => {
    cy.request("GET", "/api/health").then((resp) => {
      expect(resp.status).to.eq(200);
    });
  });
});

cy.request("GET", "/api/health") memastikan backend hidup sebelum suite utama. Test sanity seperti ini menangkap drift lebih awal dan membuat kegagalan suite lebih mudah dibaca.

#Incident Response untuk Failing CI Runs

#Triage Cepat

Saat CI merah, hal pertama bukan memperbaiki — tetapi mengklasifikasikan. Buat daftar kategori yang jelas:

• Flaky: gagal sesekali tanpa perubahan kode.
• Regression: gagal konsisten setelah perubahan terakhir.
• Environment: gagal karena backend, seed, atau konfigurasi.

Membedakan kategori menentukan langkah berikutnya: flaky ditandai untuk diselidiki, regression dibisukan atau ditangani segera, environment dikembalikan ke kondisi normal. Kegagalan yang didokumentasikan dengan kategori jauh lebih mudah ditangani.

#Pembisuan yang Terkendali

Saat run menghalangi tim dan harus dilanjutkan, bisukan dengan alasan tercatat:

Membisukan test dengan alasan

it.skip("regresi pada daftar produk - menunggu perbaikan #1234", () => {
  cy.visit("/katalog");
});

it.skip(...) menonaktifkan test sambil menyimpan nomor issue. Bisukan hanya untuk waktu singkat; masukkan ke backlog perbaikan dan pantau agar tidak terlupakan.

#Maintaining Test Coverage dan Health

#Memantau Metrik

Kesehatan suite diukur dengan metrik yang konsisten:

Pass rate: 98% (target: min 95%)
Durasi: 6 menit (target: max 10 menit)
Flaky minggu ini: 3 (target: mendekati 0)

Pass rate: 98% (target: min 95%) memberi target eksplisit. Tanpa target, metrik tidak bisa diperdebatkan. Tetapkan juga target durasi dan jumlah flaky agar kesehatan terukur.

#Menjaga Coverage Tetap Bermakna

Coverage yang diukur adalah jumlah test per alur penting, bukan sekadar persentase baris kode. Tinjau berkala: alur mana yang masih tanpa test, test mana yang duplikat, dan alur mana yang jarang dipakai hingga tidak layak dirawat. Coverage yang bermakna lebih baik daripada angka yang mengesankan.

#Team Ownership dan Maintenance Routines

#Kepemilikan Per Modul

Test paling sehat saat ada pemiliknya. Bagi suite menjadi modul dan tetapkan owner:

auth-flow:
  owner: tim-frontend
  specs:
    - cypress/e2e/auth/**
checkout:
  owner: tim-commerce
  specs:
    - cypress/e2e/checkout/**

auth-flow: mendefinisikan modul beserta pemiliknya. Saat test auth gagal, tim-frontend yang tahu siapa yang harus dihubungi. Kepemilikan mencegah status "bukan punya siapa-siapa".

#Rutinitas Perawatan

Jadwalkan perawatan rutin: review mingguan flaky test, bulanan peninjauan selector dan helper, serta kuartalan audit seluruh suite terhadap perubahan aplikasi. Rutinitas yang konsisten menjaga suite tetap sehat sebelum masalah menumpuk.

#Penutup

Episode 19 menjadikan pengujian sebagai sistem yang dioperasikan: runbook untuk flaky dan drift, triage untuk CI yang gagal, metrik kesehatan dengan target, serta kepemilikan dan rutinitas perawatan yang jelas.

Inti yang harus dibawa pulang:

• Runbook mengubah perbaikan flaky menjadi proses yang bisa diikuti.
• Klasifikasikan kegagalan: flaky, regression, atau environment.
• Sanity check di awal run menangkap drift lebih dini.
• Tetapkan target pass rate, durasi, dan jumlah flaky.
• Beri kepemilikan per modul dan jadwalkan perawatan rutin.

Di episode 20 selanjutnya kita akan membahas real-world use cases dan patterns — studi kasus ecommerce, SaaS onboarding, dan dashboard flows, best practices test design dan prioritas, menyeimbangkan unit, integration, dan E2E, serta end-to-end reliability patterns.