Ritual mingguan QA untuk cegah regresi sebelum rilis bukan berarti menambah birokrasi, tetapi membuat verifikasi lebih terarah. Jika setiap minggu tim selalu menetapkan area berisiko, memeriksa smoke test, meninjau flaky test, dan menyepakati kriteria bug blocker, kemungkinan regresi lolos ke production turun secara nyata.

Untuk tim engineering kecil hingga menengah, masalah utamanya biasanya bukan kurangnya tool, melainkan kurang konsisten dalam memilih apa yang harus diuji lebih dulu. Ritual mingguan memberi struktur: apa fokus minggu ini, test mana yang wajib hijau, kapan hasil test boleh diabaikan, dan kapan bug harus menghentikan rilis.

Mengapa perlu ritual mingguan, bukan hanya regression test penuh?

Regression suite penuh sering mahal: durasinya lama, datanya tidak stabil, dan hasilnya kadang sulit dipercaya karena flaky test. Akibatnya, tim mulai mengabaikan sinyal kegagalan. Ritual mingguan QA memecah masalah ini menjadi langkah operasional yang kecil tetapi konsisten.

Tujuan utamanya ada tiga:

  • Memusatkan perhatian pada area berisiko tinggi, bukan menguji semuanya dengan bobot yang sama.
  • Menjaga kepercayaan terhadap hasil test dengan membatasi flaky test dan data test yang kotor.
  • Menyepakati aturan rilis agar keputusan tidak berubah-ubah tergantung siapa yang sedang on call.

Pendekatan ini cocok untuk tim yang merilis mingguan atau beberapa kali seminggu, terutama jika belum punya platform QA besar atau tim test automation khusus.

Komponen inti ritual mingguan QA

1. Menetapkan area berisiko minggu ini

Mulai dari perubahan yang benar-benar terjadi, bukan dari daftar test lama. Setiap Senin, kumpulkan input dari:

  • PR atau merge minggu lalu dan yang akan dirilis minggu ini
  • Perubahan schema database atau migrasi
  • Perubahan dependency eksternal, API pihak ketiga, feature flag, atau konfigurasi infra
  • Incident production terbaru
  • Bagian sistem yang historically sering gagal

Praktiknya, buat daftar maksimal 3-5 area berisiko. Jika terlalu banyak, fokus hilang. Contoh:

  • Alur login dan refresh token setelah perubahan middleware auth
  • Checkout dan kalkulasi diskon setelah update rules pricing
  • Upload dokumen karena storage path dipindah
  • Job sinkronisasi inventory karena retry policy diubah

Mengapa ini efektif? Karena sebagian besar regresi datang dari area yang baru disentuh, area dengan coupling tinggi, atau area yang pernah bermasalah sebelumnya.

2. Menjaga daftar smoke test tetap kecil dan wajib stabil

Smoke test adalah pagar pertama sebelum rilis. Daftarnya harus kecil, cepat, dan mewakili alur inti bisnis. Kesalahan umum adalah memasukkan terlalu banyak skenario hingga smoke test berubah menjadi regression suite mini yang lambat dan sulit dirawat.

Untuk tim kecil-menengah, pilih alur yang menjawab pertanyaan: jika ini gagal, apakah rilis harus dihentikan?

Contoh smoke test yang masuk akal:

  • User bisa login
  • User bisa membuat transaksi utama
  • Admin bisa melihat data transaksi
  • Worker atau queue memproses job penting
  • API health dan dependency inti merespons normal

Patokan praktis: smoke test sebaiknya selesai cepat dan jarang butuh investigasi panjang. Jika satu test terlalu sering gagal karena lingkungan atau timing, test itu belum layak menjadi smoke test.

3. Review flaky test setiap minggu

Flaky test adalah test yang kadang gagal, kadang lolos, tanpa perubahan kode yang relevan. Ini merusak kepercayaan tim terhadap CI. Jika dibiarkan, engineer akan menganggap merah di pipeline sebagai hal biasa.

Saat review mingguan, tandai test yang memiliki ciri berikut:

  • Sering hijau setelah rerun
  • Gagal hanya di jam tertentu atau pada runner tertentu
  • Tergantung urutan eksekusi test lain
  • Tergantung waktu, timezone, jaringan, atau data bersama

Lalu putuskan salah satu tindakan berikut:

  1. Perbaiki segera jika test melindungi alur kritis.
  2. Karantina sementara jika test berguna tetapi belum stabil. Test tetap dijalankan terpisah dan tidak memblokir merge sampai diperbaiki.
  3. Hapus atau ganti jika test tidak lagi relevan atau terlalu rapuh dibanding nilai yang diberikannya.

Kesalahan umum adalah membiarkan flaky test tetap memblokir semua pipeline, lalu semua orang terbiasa menekan rerun tanpa analisis akar masalah.

4. Stabilisasi data test

Banyak regresi palsu bukan berasal dari bug aplikasi, tetapi dari data test yang tidak deterministik. Beberapa sumber masalah yang sering muncul:

  • Data dipakai bersama antar test
  • ID atau email unik tidak benar-benar unik
  • Urutan test memengaruhi hasil
  • Fixture terlalu besar dan sulit dipahami
  • Jam sistem, timezone, atau tanggal hard-coded

Pola yang lebih aman:

  • Setiap test membuat datanya sendiri jika memungkinkan
  • Gunakan factory atau fixture kecil yang fokus pada satu skenario
  • Reset state database secara konsisten
  • Mock dependency eksternal yang tidak perlu diuji end-to-end pada suite utama
  • Bekukan waktu untuk skenario yang sensitif terhadap tanggal

Jika tim menggunakan database untuk integration test, lebih baik punya strategi reset yang jelas daripada melakukan pembersihan manual yang tidak konsisten.

5. Menentukan prioritas regression suite

Tidak semua regression test punya nilai yang sama. Saat waktu rilis terbatas, kelompokkan suite menjadi beberapa lapis:

  • Tier 1: smoke test wajib lolos sebelum merge ke branch rilis
  • Tier 2: regression area berisiko minggu ini
  • Tier 3: regression lengkap yang bisa berjalan terjadwal, misalnya malam hari

Pemisahan ini penting agar tim tidak menunggu suite panjang untuk setiap perubahan kecil, tetapi tetap punya jaring pengaman yang memadai menjelang rilis.

6. Menetapkan aturan kapan bug memblokir rilis

Aturan bug blocker harus disepakati sebelum tekanan rilis datang. Jika tidak, keputusan akan emosional dan inkonsisten.

Contoh aturan yang cukup praktis:

  • Selalu blocker: bug pada login, pembayaran, pembuatan data inti, korupsi data, pelanggaran keamanan, atau crash layanan utama
  • Biasanya blocker: bug tanpa workaround pada fitur yang masuk changelog rilis minggu ini
  • Tidak selalu blocker: masalah UI minor, typo, atau bug pada fitur jarang dipakai yang punya workaround jelas

Tambahkan syarat keputusan:

  • Seberapa luas dampaknya?
  • Apakah ada workaround yang aman?
  • Apakah bug menyentuh data pelanggan?
  • Apakah area itu baru saja diubah pada rilis ini?
  • Apakah monitoring cukup untuk mendeteksi dampak pasca-rilis?

Aturan sederhana lebih berguna daripada matriks severity yang rumit tetapi tidak dipakai.

Workflow Senin-Jumat yang bisa langsung diterapkan

Senin: pilih goals verifikasi minggu ini

  1. Tinjau perubahan yang sudah merge dan yang direncanakan masuk rilis.
  2. Tentukan 3-5 area berisiko.
  3. Pilih regression subset untuk area tersebut.
  4. Tinjau flaky test dari minggu sebelumnya.
  5. Setujui daftar smoke test yang wajib hijau.

Output hari Senin harus konkret, misalnya satu dokumen pendek atau issue mingguan berisi target verifikasi dan owner.

Selasa: perkuat dasar test

  1. Perbaiki test paling flaky yang memengaruhi area kritis.
  2. Rapikan data test yang sering gagal karena state tidak bersih.
  3. Pastikan environment CI dan staging cukup konsisten.

Hari Selasa sebaiknya tidak dihabiskan untuk menambah banyak test baru jika fondasi test yang ada belum stabil.

Rabu: jalankan regression terarah

  1. Eksekusi smoke test di CI dan/atau staging.
  2. Jalankan regression suite untuk area berisiko minggu ini.
  3. Catat kegagalan: bug nyata, flaky, atau masalah environment.

Poin pentingnya adalah klasifikasi. Jika semua kegagalan hanya diberi label “test failed”, tim tidak akan tahu masalah sebenarnya.

Kamis: triage dan keputusan rilis

  1. Bahas bug yang ditemukan dan tentukan apakah blocker.
  2. Evaluasi apakah ada test tambahan yang perlu dimasukkan ke smoke test atau regression subset.
  3. Putuskan apakah perlu menunda rilis, mempersempit scope, atau menambah observability.

Di tahap ini, jangan hanya melihat jumlah bug. Lihat juga jenisnya. Satu bug korupsi data lebih penting daripada lima bug kosmetik.

Jumat: final check dan retrospektif singkat

  1. Pastikan smoke test terakhir hijau.
  2. Pastikan bug blocker selesai atau rilis ditunda.
  3. Catat metrik mingguan.
  4. Tulis 2-3 perbaikan proses untuk minggu berikutnya.

Retrospektif cukup 10-15 menit. Fokus pada apa yang membuat sinyal test lebih dapat dipercaya.

Template checklist ritual mingguan QA

Template berikut bisa dipakai di issue tracker, Notion, atau file di repository.

Ritual Mingguan QA - [Minggu/Periode Rilis]

1. Goals verifikasi minggu ini
- [ ] Area risiko #1:
- [ ] Area risiko #2:
- [ ] Area risiko #3:

2. Smoke test wajib hijau
- [ ] Login user
- [ ] Buat transaksi utama
- [ ] Lihat transaksi di admin
- [ ] Proses job kritis
- [ ] Health check API / service inti

3. Review flaky test
- [ ] Daftar test yang gagal > 1 kali minggu lalu
- [ ] Klasifikasi: flaky / bug nyata / environment
- [ ] Owner perbaikan ditetapkan
- [ ] Test yang dikarantina didokumentasikan

4. Data test dan environment
- [ ] Reset database konsisten
- [ ] Fixture/factory untuk skenario baru tersedia
- [ ] Dependency eksternal yang tidak perlu sudah dimock
- [ ] Timezone/waktu pada test sensitif sudah dikontrol

5. Regression suite prioritas
- [ ] Tier 1 dijalankan di setiap PR penting
- [ ] Tier 2 dijalankan sebelum cut release
- [ ] Tier 3 dijadwalkan periodik

6. Aturan blocker rilis
- [ ] Bug pada alur inti = blocker
- [ ] Korupsi/kehilangan data = blocker
- [ ] Isu keamanan signifikan = blocker
- [ ] UI minor dengan workaround = non-blocker

7. Metrik minggu ini
- [ ] Failure rate:
- [ ] Rerun rate:
- [ ] Jumlah flaky test aktif:
- [ ] Jumlah bug blocker:

Metrik sederhana yang cukup untuk tim kecil-menengah

Tidak perlu dashboard rumit di awal. Dua metrik yang paling berguna adalah failure rate dan rerun rate.

Failure rate

Definisi sederhana:

failure_rate = jumlah run gagal / total run

Gunakan per suite, bukan hanya global. Contohnya, smoke test bisa punya failure rate terpisah dari regression penuh. Ini membantu melihat suite mana yang tidak stabil.

Rerun rate

Definisi sederhana:

rerun_rate = jumlah run yang perlu diulang / total run gagal

Jika rerun rate tinggi, biasanya ada dua kemungkinan:

  • test memang flaky, atau
  • environment CI tidak stabil

Rerun rate penting karena banyak tim keliru merasa pipeline “aman” hanya karena akhirnya hijau setelah beberapa kali rerun.

Metrik tambahan yang masih ringan

  • Jumlah flaky test aktif
  • Waktu rata-rata investigasi kegagalan smoke test
  • Jumlah bug blocker per rilis
  • Persentase area berisiko yang punya test otomatis

Jangan mengejar terlalu banyak metrik. Jika tim belum rutin menindaklanjuti hasilnya, metrik tambahan hanya jadi noise.

Integrasi dengan CI tanpa membuat pipeline terlalu berat

CI sebaiknya mendukung ritual mingguan QA, bukan justru membuat semua langkah menjadi lambat. Prinsipnya adalah memisahkan jalur verifikasi berdasarkan kebutuhan.

Pola pipeline yang umum dan efektif

  • PR pipeline: lint, unit test penting, dan smoke test cepat
  • Release candidate pipeline: smoke test + regression area berisiko minggu ini
  • Scheduled pipeline: regression suite penuh, misalnya di malam hari atau harian

Dengan pola ini, developer tetap mendapat feedback cepat di PR, sementara verifikasi yang lebih mahal dijalankan pada momen yang tepat.

Contoh konfigurasi pipeline generik

stages:
  - lint
  - unit
  - smoke
  - regression

lint:
  script:
    - run-linter

unit:
  script:
    - run-unit-tests

smoke:
  script:
    - run-smoke-tests

regression_risk_based:
  script:
    - run-regression-suite --group=checkout,auth,worker
  rules:
    - if: release_branch

regression_full_nightly:
  script:
    - run-regression-suite --all
  rules:
    - if: scheduled_run

Contoh di atas sengaja generik. Intinya bukan nama tool, tetapi pemisahan tanggung jawab antar job.

Tips implementasi CI

  • Publikasikan hasil test per kelompok agar mudah dilacak.
  • Bedakan failure karena aplikasi dan failure karena environment jika tooling mendukung.
  • Simpan histori test untuk melihat pola flaky.
  • Jangan langsung menambahkan rerun otomatis ke semua job tanpa batas; itu bisa menyembunyikan masalah nyata.

Praktik yang sehat: jika rerun otomatis dipakai, gunakan terbatas dan catat tetap sebagai sinyal instabilitas, bukan dianggap lolos bersih.

Kesalahan umum saat menerapkan ritual mingguan QA

1. Smoke test terlalu besar

Jika smoke test berjalan terlalu lama atau sering gagal karena alasan non-kritis, tim akan berhenti mempercayainya. Kecilkan cakupannya hingga hanya alur inti.

2. Semua bug dianggap blocker

Akibatnya tim kehilangan kemampuan membuat keputusan rilis yang proporsional. Gunakan kriteria dampak, workaround, dan risiko data.

3. Flaky test didiamkan terlalu lama

Sekali tim terbiasa menekan rerun, kualitas sinyal CI akan turun drastis. Flaky test harus punya owner dan tenggat perbaikan.

4. Regression suite tidak mengikuti perubahan sistem

Suite yang relevan enam bulan lalu belum tentu relevan sekarang. Tinjau ulang test berdasarkan insiden terbaru dan area yang paling sering berubah.

5. Tidak ada owner yang jelas

Ritual mingguan tidak harus dimiliki QA saja. Satu engineer release owner per minggu sering lebih efektif, asalkan product engineer ikut bertanggung jawab pada stabilitas test dan keputusan bug.

Contoh pembagian peran yang realistis

  • Release owner minggu ini: memimpin triage, memastikan checklist terisi, dan memutuskan readiness bersama tim
  • Developer area owner: memperbaiki test dan bug pada domain yang diubah
  • QA atau engineer yang menangani test automation: menjaga struktur suite, data test, dan pelabelan flaky
  • DevOps atau platform engineer: membantu jika kegagalan berasal dari runner, environment, atau dependency CI

Di tim kecil, satu orang bisa memegang beberapa peran. Yang penting bukan jumlah orangnya, tetapi kejelasan tanggung jawab.

Penutup

Ritual mingguan QA untuk cegah regresi sebelum rilis bekerja karena memaksa tim fokus pada risiko aktual, bukan pada daftar test yang dijalankan secara buta. Mulailah dari hal sederhana: pilih area berisiko setiap Senin, jaga smoke test tetap kecil, review flaky test tiap minggu, rapikan data test, dan sepakati aturan bug blocker sebelum rilis mendekat.

Jika baru mulai, jangan langsung membangun proses besar. Cukup jalankan satu checklist mingguan, satu subset regression berbasis risiko, dan dua metrik sederhana: failure rate serta rerun rate. Dari situ, kualitas rilis biasanya membaik bukan karena tim mengetes lebih banyak, tetapi karena tim mengetes lebih tepat.