Strategi regression testing untuk CI cepat dan rilis lebih aman berfokus pada satu tujuan praktis: mendeteksi regresi penting secepat mungkin tanpa memaksa semua perubahan menunggu full test suite yang mahal. Pendekatan ini relevan untuk aplikasi web dan backend yang punya kombinasi API, database, background job, integrasi pihak ketiga, dan UI yang terus berubah.

Masalah umum di banyak tim bukan kekurangan test, melainkan semua test dijalankan di waktu yang salah. Akibatnya, pipeline pull request menjadi lambat, developer sering menunda perbaikan, dan test yang seharusnya melindungi rilis justru di-bypass. Solusinya adalah menyusun beberapa lapis suite: smoke test untuk validasi dasar, regression suite terpilih untuk perubahan harian, dan full test suite untuk validasi menyeluruh di waktu yang tepat.

Memahami perbedaan smoke test, regression test, dan full test suite

Smoke test

Smoke test adalah kumpulan test paling kecil untuk memastikan aplikasi masih bisa berjalan pada jalur utama. Tujuannya bukan memverifikasi seluruh perilaku, tetapi menjawab pertanyaan cepat: apakah build ini layak diuji lebih lanjut atau di-deploy ke environment berikutnya?

  • Contoh: aplikasi bisa start, koneksi database berhasil, health endpoint merespons, login dasar bekerja, endpoint API utama tidak 500.
  • Jumlah test sedikit, durasi sangat singkat.
  • Cocok dijalankan pada setiap push, setelah build artifact dibuat, atau setelah deploy ke staging.

Regression test

Regression test bertujuan memastikan fitur yang sebelumnya bekerja tidak rusak oleh perubahan baru. Suite ini lebih luas daripada smoke test, tetapi tidak harus mencakup semua test yang dimiliki proyek.

  • Fokus pada area yang rawan rusak atau berdampak bisnis tinggi.
  • Biasanya berisi test untuk alur kritis, area dengan histori bug tinggi, dan modul yang sering disentuh.
  • Sangat cocok sebagai baseline suite untuk pull request karena memberi sinyal yang lebih kuat daripada smoke test tanpa biaya full suite.

Full test suite

Full test suite mencakup seluruh spektrum test yang ingin dipertahankan tim: unit, integration, contract, end-to-end, migration, mungkin juga performance sanity test tertentu. Tujuannya adalah validasi menyeluruh sebelum rilis besar, nightly build, atau branch utama pada jadwal tertentu.

  • Memberi cakupan tertinggi.
  • Biayanya paling mahal dari sisi durasi, resource, dan maintenance.
  • Tidak ideal dijalankan penuh pada setiap commit jika membuat feedback loop terlalu lambat.

Aturan praktis: smoke test menjawab “apakah sistem masih hidup?”, regression suite menjawab “apakah perubahan ini merusak perilaku penting yang pernah benar?”, full suite menjawab “apakah keseluruhan sistem masih konsisten?”.

Strategi regression testing untuk CI cepat: bagi test berdasarkan risiko

Jika regression suite dipilih secara acak, hasilnya biasanya buruk: test banyak tetapi tidak relevan. Suite yang efektif dibangun dari risiko perubahan, critical path, dan histori bug.

1. Risiko perubahan

Tidak semua perubahan punya potensi dampak yang sama. Perubahan pada helper kecil biasanya lebih aman daripada perubahan pada autentikasi, query billing, atau skema database.

Klasifikasikan perubahan menjadi beberapa kategori:

  • Risiko rendah: perubahan copy text, refactor lokal tanpa perubahan perilaku, styling minor.
  • Risiko sedang: perubahan endpoint non-kritis, validasi form, aturan filtering.
  • Risiko tinggi: autentikasi, otorisasi, pembayaran, pembuatan order, sinkronisasi data, migration database, caching, antrean job, integrasi eksternal.

Dari sini, Anda bisa menentukan suite minimum yang wajib jalan. Semakin tinggi risikonya, semakin besar subset regression test yang harus dieksekusi.

2. Critical path

Critical path adalah alur yang paling penting bagi pengguna atau bisnis. Untuk aplikasi backend/web, jalur ini biasanya meliputi:

  • registrasi dan login,
  • membaca dan menulis data utama,
  • checkout atau pembayaran,
  • pembuatan transaksi/order,
  • otorisasi akses,
  • proses background job yang mengubah status bisnis.

Regression suite untuk pull request hampir selalu harus mencakup critical path, meskipun file yang berubah tampak tidak terkait. Alasannya sederhana: banyak regresi muncul dari shared component seperti middleware, model, serializer, caching, atau konfigurasi environment.

3. Histori bug

Modul yang sering memunculkan bug layak mendapat prioritas lebih tinggi. Jika area tertentu pernah menyebabkan insiden berulang, jangan hanya memperbaiki bug-nya; masukkan test yang relevan ke regression suite.

Sumber data yang berguna:

  • issue tracker,
  • postmortem insiden,
  • PR yang sering rollback,
  • log error production,
  • modul dengan perubahan paling sering.

Prinsip pentingnya: setiap bug produksi yang signifikan sebaiknya menghasilkan test yang mencegah bug itu lolos lagi. Jika tidak, regression suite tidak benar-benar belajar dari histori sistem Anda.

Menyusun lapisan suite: baseline untuk PR, lengkap untuk nightly

Baseline suite untuk pull request

Baseline suite adalah regression suite minimum yang harus lolos sebelum merge. Isinya bukan semua test, melainkan kombinasi berikut:

  • smoke test inti,
  • critical path utama,
  • test dari area berisiko tinggi,
  • test untuk bug yang pernah lolos ke production,
  • test pada komponen bersama seperti auth, permission, serialization, persistence, dan API contract utama.

Karakteristik baseline suite yang baik:

  • cukup kecil untuk memberi feedback cepat,
  • cukup kuat untuk menangkap regresi yang paling mahal,
  • stabil dan tidak flaky,
  • mudah dipahami oleh tim.

Jika baseline suite terlalu besar, developer akan terdorong untuk menunggu lama atau mengabaikan hasil CI. Jika terlalu kecil, false confidence meningkat.

Suite lengkap untuk nightly atau jadwal berkala

Full suite lebih cocok dijalankan secara nightly, pada branch utama setelah merge, atau sebelum rilis. Dengan jadwal ini, tim tetap mendapatkan coverage luas tanpa mengorbankan kecepatan review harian.

Yang biasanya masuk ke full suite:

  • seluruh unit dan integration test,
  • end-to-end yang mahal,
  • test lintas service,
  • compatibility check tertentu,
  • migration test dan rollback check bila relevan,
  • test yang butuh environment lebih berat.

Nightly run berguna untuk mendeteksi interaksi antarperubahan yang tidak terlihat di level PR. Kegagalan pada nightly tidak boleh diabaikan; tim perlu aturan eskalasi yang jelas, misalnya memperbaiki sebelum jam kerja berikutnya atau membekukan merge pada area tertentu.

Teknik test selection yang praktis

Kunci CI cepat bukan hanya mengurangi jumlah test, tetapi memilih test yang paling relevan terhadap perubahan.

1. Tagging test berdasarkan kategori dan risiko

Metode paling mudah diterapkan adalah memberi tag atau label pada test. Tag yang umum dan berguna:

  • smoke
  • regression
  • critical-path
  • db
  • api
  • auth
  • billing
  • slow
  • flaky (hanya sementara untuk isolasi, bukan pembenaran permanen)

Dengan tagging, pipeline bisa menjalankan subset yang tepat tanpa bergantung pada struktur folder saja.

# Contoh pseudo-command, sesuaikan dengan runner test Anda
run-tests --tag smoke
run-tests --tag regression
run-tests --tag critical-path --exclude-tag slow

Tagging bekerja baik jika disiplin dijaga. Kesalahan umum adalah memberi terlalu banyak tag tanpa aturan yang jelas, sehingga suite menjadi sulit diprediksi.

2. Selection berbasis file yang berubah

Pendekatan berikutnya adalah memilih test berdasarkan file atau modul yang berubah. Misalnya, perubahan pada modul pembayaran memicu test payment, invoice, refund, dan contract terkait.

Ini efektif jika:

  • struktur kode cukup modular,
  • dependency antar modul bisa dipetakan,
  • tim memahami bahwa perubahan shared library dapat berdampak luas.

Namun ada keterbatasan besar: pemetaan file ke test sering gagal menangkap dampak tidak langsung, seperti perubahan serializer, middleware, konfigurasi cache, atau query helper yang dipakai banyak modul. Karena itu, file-based selection sebaiknya ditambah baseline suite tetap, bukan menggantikannya.

3. Test impact analysis

Pada organisasi yang lebih matang, Anda bisa menerapkan test impact analysis: sistem menganalisis dependency kode dan histori eksekusi untuk menentukan test yang relevan. Pendekatan ini bisa sangat efisien, tetapi implementasinya lebih kompleks dan butuh data yang konsisten.

Gunakan pendekatan ini jika:

  • jumlah test sudah besar,
  • durasi pipeline mulai mengganggu throughput tim,
  • arsitektur dan tooling memungkinkan pelacakan dependency yang masuk akal.

Jangan mulai dari sini jika tim belum punya tagging yang rapi, metrik dasar, dan suite stabil. Kompleksitasnya tidak akan terbayar.

4. Parallelization dan sharding

Terkadang masalah utamanya bukan terlalu banyak test, melainkan semua test dijalankan serial. Memecah suite menjadi shard paralel sering memberi pengurangan durasi yang signifikan tanpa menurunkan coverage.

Perhatikan beberapa hal:

  • test harus independen,
  • resource bersama seperti database dan cache tidak boleh saling mengganggu,
  • urutan eksekusi tidak boleh memengaruhi hasil.

Jika parallel run membuat banyak test gagal acak, biasanya ada masalah isolasi state yang memang perlu dibenahi.

Contoh workflow CI yang seimbang

Berikut contoh alur yang realistis untuk aplikasi backend/web:

  1. Setiap push ke branch fitur: lint, static analysis, unit test cepat, smoke test.
  2. Saat pull request dibuat atau diupdate: baseline regression suite + test yang dipilih berdasarkan area perubahan.
  3. Setelah merge ke branch utama: baseline suite lagi, plus subset integrasi tambahan jika diperlukan.
  4. Nightly: full test suite, termasuk end-to-end, migration, contract, dan skenario mahal.
  5. Sebelum rilis: full suite pada artifact yang benar-benar akan dirilis, bukan build berbeda.

Contoh pseudo-konfigurasi workflow:

workflows:
  push:
    steps:
      - lint
      - static-analysis
      - tests: [unit-fast, smoke]

  pull_request:
    steps:
      - build
      - tests: [baseline-regression]
      - tests: [change-based-selection]

  main_branch:
    steps:
      - build
      - tests: [baseline-regression, integration-core]

  nightly:
    steps:
      - build
      - tests: [full-suite]
      - publish-report

  release_candidate:
    steps:
      - build-release-artifact
      - tests: [full-suite]
      - deploy-staging
      - tests: [post-deploy-smoke]

Prinsip penting dari workflow ini:

  • Feedback cepat untuk developer saat masih mengerjakan perubahan.
  • Proteksi memadai sebelum merge.
  • Coverage luas pada jadwal yang tidak menghambat iterasi harian.
  • Smoke test pasca-deploy untuk memastikan masalah environment tidak lolos.

Mengukur efektivitas strategi regression testing

Tanpa metrik, Anda hanya menebak-nebak apakah suite yang dipilih benar-benar membantu. Minimal, ukur tiga hal berikut.

1. Fail rate

Fail rate menunjukkan seberapa sering suite gagal. Metrik ini harus dibaca dengan konteks:

  • Jika fail rate sangat rendah dan hampir tidak pernah menemukan bug, mungkin suite terlalu lemah.
  • Jika fail rate tinggi tetapi banyak false positive, kemungkinan besar test tidak stabil atau environment bermasalah.

Pisahkan antara:

  • gagal karena bug valid,
  • gagal karena flaky test,
  • gagal karena infrastruktur CI.

Pemisahan ini penting agar tim tidak salah menyimpulkan kualitas kode dari kualitas pipeline.

2. Durasi suite

Durasi harus diukur per lapisan suite:

  • smoke,
  • baseline regression,
  • full suite.

Yang penting bukan hanya rata-rata, tetapi juga tail latency: berapa lama run terlama dan seberapa sering antre. Pipeline yang secara teori cepat bisa tetap menyakitkan jika sering menunggu resource atau memicu rerun karena flaky.

3. Escaped defects

Escaped defects adalah bug yang lolos ke staging atau production. Ini metrik paling penting karena langsung menunjukkan apakah strategi test melindungi area yang benar.

Pertanyaan yang perlu dijawab untuk setiap escaped defect:

  • Apakah bug ini seharusnya bisa tertangkap oleh smoke, baseline regression, atau full suite?
  • Jika ya, test apa yang hilang?
  • Jika test sudah ada tetapi gagal mendeteksi, apakah datanya tidak realistis, assertion terlalu lemah, atau jalur eksekusinya tidak terpicu?

Dari sini Anda bisa memperbaiki kualitas suite secara bertahap, bukan menambah test secara membabi buta.

Indikator strategi yang sehat: baseline suite cukup cepat untuk dipakai harian, cukup sering menangkap regresi nyata, dan jumlah bug penting yang lolos ke production menurun tanpa membuat CI menjadi bottleneck.

Menjaga test tetap reliabel dan tidak berubah jadi flaky

Regression suite yang cepat tetapi flaky tetap buruk, karena developer kehilangan kepercayaan pada CI. Begitu test sering gagal acak, hasil pipeline akan diabaikan.

Penyebab flaky test yang umum

  • bergantung pada waktu nyata atau timezone,
  • bergantung pada urutan eksekusi test,
  • menggunakan data bersama yang tidak dibersihkan,
  • mengakses layanan eksternal tanpa kontrol,
  • assertion pada elemen atau response yang tidak deterministik,
  • timeout terlalu agresif,
  • race condition pada job asynchronous atau cache.

Praktik untuk mengurangi flakiness

  • Isolasi state: setiap test menyiapkan dan membersihkan datanya sendiri.
  • Kontrol waktu: gunakan fake clock atau waktu tetap jika memungkinkan.
  • Mock secukupnya: mock layanan eksternal untuk kasus yang tidak sedang menguji integrasi nyata.
  • Data deterministic: hindari assertion terhadap urutan hasil yang tidak dijamin.
  • Retry dengan hati-hati: retry boleh membantu diagnosis infrastruktur, tetapi jangan dipakai untuk menutupi bug atau test buruk.
  • Karantina test flaky: keluarkan sementara dari gate utama, beri owner, dan tetapkan tenggat perbaikan.

Jika sebuah test flaky berada di baseline suite, prioritas perbaikannya harus lebih tinggi daripada test flaky di nightly. Alasannya sederhana: baseline suite memengaruhi alur kerja harian seluruh tim.

Anti-pattern umum dalam regression testing

1. Menjalankan full suite pada setiap pull request tanpa evaluasi

Ini terdengar aman, tetapi sering membuat feedback terlalu lambat. Ketika durasi bertambah, tim mulai mencari jalan pintas seperti merge tanpa menunggu, rerun sembarangan, atau menonaktifkan test.

2. Hanya mengandalkan test selection berbasis file

Perubahan kecil pada shared component bisa berdampak ke banyak area yang tidak terlihat dari nama file. Selalu pertahankan baseline suite tetap untuk area kritis.

3. Semua test dianggap regression test

Jika label regression dipasang ke hampir semua test, istilah itu kehilangan nilai operasional. Regression suite harus punya batas yang jelas dan alasan pemilihan yang dapat dijelaskan.

4. Tidak ada proses memasukkan bug produksi ke suite

Tim memperbaiki insiden tetapi tidak menambah test pencegah. Akibatnya, bug yang sama bisa terulang dengan variasi berbeda.

5. Membiarkan flaky test terlalu lama

Flaky test yang dibiarkan akan merusak kredibilitas seluruh pipeline. Test seperti ini harus diperbaiki, diisolasi, atau dihapus jika memang tidak memberi nilai.

6. Mengukur coverage semata sebagai indikator kualitas

Coverage berguna, tetapi tidak cukup. Test dengan coverage tinggi bisa tetap gagal melindungi critical path jika assertion lemah atau data tidak realistis.

Checklist implementasi bertahap

Jika tim Anda belum punya strategi regression testing yang terstruktur, lakukan secara bertahap.

Tahap 1: Petakan kondisi saat ini

  • Daftar semua jenis test yang ada.
  • Catat durasi masing-masing suite.
  • Identifikasi test paling lambat dan paling sering gagal.
  • Tentukan alur bisnis yang benar-benar kritis.

Tahap 2: Bentuk baseline suite

  • Pilih smoke test inti.
  • Tambahkan test untuk critical path.
  • Masukkan test dari area berisiko tinggi dan histori bug.
  • Pastikan suite ini stabil sebelum dijadikan gate merge.

Tahap 3: Tambahkan tagging dan aturan eksekusi

  • Buat kategori tag yang sederhana dan konsisten.
  • Terapkan pada test baru dan lama secara bertahap.
  • Atur PR untuk menjalankan baseline + selection berbasis perubahan.

Tahap 4: Jadwalkan full suite

  • Jalankan nightly atau pada branch utama.
  • Publikasikan hasil dan tetapkan owner untuk kegagalan.
  • Pastikan temuan nightly benar-benar ditindaklanjuti.

Tahap 5: Tutup loop dengan metrik

  • Pantau fail rate dan klasifikasikan penyebabnya.
  • Pantau durasi dan antrian pipeline.
  • Review escaped defects secara rutin.
  • Masukkan test baru berdasarkan insiden nyata.

Rekomendasi praktis untuk aplikasi web dan backend

Untuk kebanyakan tim web/backend, strategi yang seimbang biasanya seperti ini:

  • Setiap push: lint, static analysis, unit test cepat, smoke test.
  • Setiap pull request: baseline regression suite yang stabil dan relatif singkat, ditambah test area terdampak.
  • Nightly: full suite termasuk integration dan end-to-end yang mahal.
  • Setiap bug penting di production: tambahkan test pencegah ke lapisan suite yang paling sesuai, biasanya baseline jika dampaknya tinggi.
  • Setiap minggu atau sprint: review flaky test, durasi suite, dan escaped defects.

Jangan mengejar desain sempurna sejak awal. Yang lebih penting adalah membuat strategi yang konsisten, bisa dijelaskan, dan bisa diperbaiki dari data. Regression testing yang efektif bukan tentang jumlah test terbanyak, melainkan tentang menempatkan test yang tepat pada tahap CI yang tepat.