Strategi Prioritas Regression Test bertujuan agar tim CI hanya menjalankan pengujian yang benar-benar memvalidasi perubahan, sekaligus menghindari build yang gagal karena tes flaky. Dengan triase yang konsisten, kita bisa menjawab langsung pertanyaan: tes mana yang harus dijalankan, mana yang perlu ditunda, dan kapan gagalannya harus membuat build di-reject.

Pendekatan Triase Regression Test dalam Pipeline CI

1. Identifikasi Perubahan Berisiko

Mulai dari diff kode, perhatikan area yang terpengaruh seperti layanan backend, perubahan kontrak API, atau modul frontend yang sensitif. Bandingkan perubahan terhadap pekerjaan terakhir dan flag file yang berulang membuat regression. Risiko ditentukan oleh kompleksitas logika, keterkaitan lintas service, dan perubahan data schema.

Gunakan metadata commit atau PR (misalnya label atau daftar file) untuk menandai perubahan berisiko. Ketika area berbahaya terdeteksi, catat juga tes yang biasanya memverifikasi area tersebut.

2. Klasifikasi Tes Flaky

Klasifikasikan suite berdasarkan rekam jejak kestabilan. Tes dengan kegagalan sporadis (flaky) tetap berguna, tapi harus dikelola secara terpisah. Data historis dari CI menampilkan frekuensi gagal. Gunakan metrik sederhana:

  • Frekuensi gagal: jumlah run yang gagal dalam 30 hari terakhir.
  • Dampak pengguna: skala 1–5, seberapa besar bagian aplikasi yang diuji memengaruhi end-user.

Tes dengan frekuensi gagal tinggi tapi dampak rendah sebaiknya ditempatkan di batch eksplorasi, sementara tes dampak tinggi dan stabil diarahkan ke prioritas tertinggi.

3. Prioritas Pengujian Berdasarkan Dampak

Dengan data risiko dan kestabilan, kita bisa menentukan urutan eksekusi:

  • Prioritas tinggi: komponen berubah, tes dampak pengguna besar, dan stabil; jalankan di job utama minimal ganti branch.
  • Prioritas sedang: perubahan kerangka minor atau tes yang lebih lambat; bisa dijalankan di job tambahan atau setelah validasi awal.
  • Prioritas rendah: tes flaky atau area jarang disentuh; jalankan pada jadwal terpisah untuk menjaga data, bukan untuk memblokir build.

Contoh perhitungan prioritas:

function scoreTest(test) {
  const weightFail = 0.6;
  const weightImpact = 0.4;
  return test.frequencyFail * weightFail + test.userImpact * weightImpact;
}

const sortedTests = tests.sort((a, b) => scoreTest(b) - scoreTest(a));

Gunakan skor ini untuk menentukan tes yang dijalankan pertama. Jika skor tinggi gagal, build harus di-reject agar isu tidak menyebar ke branch main.

Metrik untuk Menentukan Tes Prioritas dan Threshold Reject

Kumpulkan metrik berikut di dashboard CI:

  • Frekuensi gagal: berapa kali tes gagal dalam 30 hari. Angka tinggi menunjukkan flaky atau regresi yang belum diperbaiki.
  • Dampak pengguna: asesmen kolektif tim (1–5). Fokuskan pengujian pada area dampak besar.
  • Time to Fix: rerata waktu yang dibutuhkan untuk memperbaiki tes yang gagal.

Threshold reject build bisa berupa: jika ada priority-high test gagal dua kali dalam satu pipeline, hentikan workflow dan laporkan ke pemilik feature sebelum merge. Buat juga aturan fail-fast untuk perubahan yang berisiko tinggi (misalnya database migration).

Workflow Verifikasi Patch: Local → PR → Main

Verifikasi patch harus mengikuti alur:

  1. Local: jalankan subset regression test yang relevan dengan perubahan. Prioritaskan test berstabil tinggi yang tercatat terdampak.
  2. Pull Request: CI menjalankan prioritas tertinggi plus tambahan smoke test. Jika gagal, sertakan log dan riwayat flake di komentar sehingga reviewer tahu konteks.
  3. Main: setelah merge, jalankan suite lengkap berbasis prioritas menurun. Bila tes prioritas tinggi masih gagal, rollback atau force stop deployment hingga diselesaikan.

Pastikan pipeline memberikan feedback cepat di tahapan awal. Misalnya, jadwalkan job per kategori prioritas dan tampilkan skor prioritas di dashboard agar reviewer tahu mengapa tes tertentu dijalankan.

Menjaga Stabilitas Suite Saat Tim Sering Merge

Frekuensi merge tinggi bisa mempercepat flaky test muncul. Berikut tip untuk menjaga stabilitas:

  • Segregasi tes: pisahkan suite stabil dan eksperimental. Suite stabil memblokir merge, suite eksperimental bisa dijalankan di luar jam kritis.
  • Monitor tren: gunakan metrik untuk mendeteksi lonjakan flake setelah merge besar. Jika terjadi, kurangi prioritas otomatis untuk menjalankan tes yang bermasalah sampai diperbaiki.
  • Dokumentasi flaky: catat penyebab dan owner. Saat tes prioritas rendah gagal, tim bisa menunda penanganan tanpa mengganggu pipeline utama.
  • Batch merge kecil: kurangi perubahan besar per PR. Ini memperkecil jumlah area yang terdampak dan memudahkan triase.

Dengan pendekatan ini, regression test tetap relevan sekaligus CI tidak berkutat pada kegagalan yang tidak berarti.

Kesimpulan

Strategi Prioritas Regression Test menggabungkan identifikasi risiko, klasifikasi flaky, dan pengukuran dampak pengguna untuk menjaga pipeline CI tetap efisien. Triase yang disiplin, dukungan metrik sederhana, dan workflow patch yang terstruktur membuat regression test tidak hanya mengecek kode, tetapi juga menjaga kualitas riil tanpa memperlambat merge ke main.