Review Test Pipeline sebagai Jawaban terhadap Flaky dan Regresi

Review test pipeline adalah langkah sistematis untuk memastikan masukan pengujian sebelum menggabungkan kode. Dengan memeriksa pipeline, tim mengetahui apakah flaky test atau regresi baru berpotensi terlewat, sehingga kita bisa mengambil tindakan sebelum merge.

Pada tingkat paling praktis, fokusnya adalah: (1) menempatkan gate yang mencegah merge sampai pipeline yang relevan berhasil, (2) mengenali flaky test lewat rerun terkontrol, dan (3) memakai metrik validasi agar setiap penambahan kasus tidak merusak kualitas fungsional sebelumnya. Pendekatan ini mengurangi kebocoran bug dan membantu menjaga kepercayaan terhadap suite otomatis.

Menetapkan Gate Test Sebelum Merge

Gate adalah langkah otomatis yang menahan merge hingga pipeline tertentu selesai tanpa kegagalan. Implementasi gate biasanya dilakukan pada level workflow: bagian yang paling kritikal (misal integrasi backend, pengujian regresi UI, security scan) dilabeli sebagai required check di sistem seperti GitHub atau GitLab.

Contoh potongan GitHub Actions ini menunjukkan struktur gate yang memaksa semua job dependensinya lulus sebelum merge:

jobs:
  unit-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install && npm test

  integration-tests:
    runs-on: ubuntu-latest
    needs: unit-tests
    steps:
      - uses: actions/checkout@v4
      - run: npm run integration-test

  review-gate:
    runs-on: ubuntu-latest
    needs: [unit-tests, integration-tests]
    steps:
      - run: echo "Gate terpenuhi"

Dalam kondisi nyata, cukup konfigurasikan branch protection rule agar job unit-tests dan integration-tests berstatus sukses sebelum merge. Gate seperti ini melokalisir respons terhadap masalah testing.

Catatan praktik: bila pipeline terlalu besar, pecah gate menjadi level incremental (unit -> integration -> e2e). Hindari menggabungkan semua job ke satu workflow karena akan menyebabkan waktu tunggu dan potensi false negative.

Identifikasi dan Rekam Flaky dengan Rerun Terkontrol

Flaky test memperumit interpretasi pipeline. Solusi sederhana tapi efektif adalah mengatur rerun terkontrol: rerun otomatis hanya di lingkungan staging, tidak menghentikan gate, dan dicatat agar bisa dilacak.

Strategi yang bisa diterapkan:

  • Rerun berbasis tag: jalankan ulang job hanya jika gagal dan hanya untuk branch staging atau fitur tertentu.
  • Logging hasil rerun: rekam tiap rerun di sistem observabilitas (misal log ke database atau dashboard internal) dengan metadata seperti commit, job, dan hasil terakhir.
  • Trigger analisis: jika satu kasus gagal lebih dari tiga kali berturut-turut, tandai sebagai flaky agar tim inspeksi bisa mengambil tindakan.

Rerun perlu dibatasi agar tidak mengejar false positive. Gunakan timeout yang sama dengan run pertama dan beri jeda singkat antar rerun agar tidak memicu pembatasan layanan CI.

Debugging tip: saat rerun gagal konsisten, bandingkan log dengan run sebelumnya. Jika rerun berhasil, kemungkinan besar ada race condition atau ketergantungan lingkungan; gunakan
--runInBand (untuk Jest) atau isolasi tambahan untuk menelusuri.

Metrik Validasi untuk Kurangi Regresi Saat Menambahkan Kasus Baru

Menambahkan test baru bisa jadi jalan buntu jika tidak ada metrik pendamping. Metodologi yang terbukti adalah menggabungkan metrik coverage dengan metrik performa dan tingkat kegagalan historis.

Implementasi sederhana:

  1. Coverage baru vs baseline: catat persentase coverage sebelum dan sesudah penambahan test. Jika coverage turun, perlu ditinjau.
  2. Trend waktu eksekusi: ukur total waktu pipeline sebelum penambahan dan setelah. Penambahan test harus proporsional; jika waktu naik tajam, pertimbangkan memindahkan ke job paralel atau menurunkan data input.
  3. Rasio regresi: terapkan query pada sistem observasi test: jumlah kasus gagal hari ini yang sebelumnya stabil / total cases. Jika rasio naik, tinjau perubahan terakhir.

Gunakan dashboard atau notifikasi otomatis jika metrik melewati ambang. Misalnya, alert jika coverage turun > 0,5% atau rata-rata waktu eksekusi job > 10% dari baseline. Ini memaksa developer mengevaluasi trade-off antara cakupan vs waktu.

Monitoring dan Feedback Loop

Review test pipeline tidak berhenti setelah gate dan metrik. Monitoring berkelanjutan serta feedback dari tim QA atau reviewer memastikan pipeline tetap sehat.

Susun rutinitas berikut:

  • Rapikan daftar flaky teridentifikasi: buat ticket atau board khusus untuk remediasi flaky.
  • Review perubahan pipeline per sprint: setiap pertemuan teknis, bahas perubahan signifikan agar tidak ada gangguan yang tidak dikomunikasikan.
  • Catat insight: misal, job integration cenderung gagal karena dependency database; jadikan catatan perbaikan seperti mock service atau container yang lebih ringan.

Kecepatan rerun, gate yang cocok, dan metrik validasi menciptakan pipeline yang dapat diandalkan. Review secara rutin memastikan regresi atau flaky test tidak menggerus kepercayaan terhadap proses otomatisasi.