Regresi — apa itu, mengapa terjadi dan cara mengujinya

Apa itu regresi dalam pengembangan

Regresi — adalah situasi ketika fungsionalitas yang berfungsi di versi sebelumnya berhenti berfungsi setelah perubahan dilakukan. Perubahan bisa apa saja: perbaikan bug, penambahan fitur baru, refactoring, pembaruan pustaka, atau bahkan perubahan konfigurasi. Regresi adalah musuh utama stabilitas: setiap perubahan berisiko merusak sesuatu yang sudah diperiksa dan dirilis.

Istilah ini berasal dari pengujian: pengujian regresi — adalah menjalankan kembali pengujian yang ada setelah setiap perubahan. Jika pengujian yang sebelumnya lulus gagal — berarti telah terjadi regresi. Dalam arti luas, regresi bukan hanya kegagalan pengujian, tetapi juga setiap penurunan perilaku yang diamati oleh pengguna atau QA. Menurut Tricentis State of Testing 2023, regresi mencakup 35–45% dari semua bug yang ditemukan di produksi.

Regresi berbeda dari bug biasa dalam konteks waktu: bug mungkin sudah ada sejak awal, sedangkan regresi selalu merupakan hasil dari suatu perubahan. Ini adalah perbedaan penting, karena mencari penyebab regresi dimulai dengan analisis perubahan: apa yang berubah antara “berfungsi” dan “berhenti berfungsi”. Git bisect — alat standar untuk menemukan commit yang menyebabkan regresi.

Jenis regresi dan contoh

Regresi lokal — perubahan di modul A merusak fungsionalitas di modul A yang sama. Contoh: pengembang menulis ulang fungsi pengurutan, dan fungsi tersebut berhenti memproses array kosong dengan benar. Regresi lokal adalah yang paling mudah dideteksi dan diperbaiki, karena sebab dan akibat berdekatan.

Regresi jarak jauh — perubahan di modul A merusak fungsionalitas di modul B, yang tidak terhubung langsung melalui kode, tetapi terhubung melalui data atau waktu. Contoh: perubahan skema basis data di modul “Pengguna” merusak laporan di modul “Analitik” yang menggunakan tabel yang sama. Regresi jarak jauh adalah yang paling berbahaya: pengembang tidak curiga bahwa perubahannya akan memengaruhi modul lain.

Regresi efek samping — perubahan efek samping (logging, caching, pengiriman notifikasi) merusak perilaku yang diharapkan. Contoh: pengembang menambahkan caching untuk mempercepat kerja, tetapi karena cache yang usang, pengguna melihat data yang kedaluwarsa. Regresi efek samping sulit ditangkap dengan pengujian otomatis, karena efek samping sering tidak tercakup oleh pengujian.

Regresi kinerja — kode terus berfungsi dengan benar secara fungsional, tetapi lebih lambat dari sebelumnya. Contoh: algoritma enkripsi baru memberikan hasil yang sama, tetapi waktu eksekusi meningkat dari 2 ms menjadi 200 ms. Regresi kinerja tidak terdeteksi oleh pengujian unit biasa — diperlukan tolok ukur dan pembuatan profil.

Mengapa regresi terjadi

Penyebab pertama — keterkaitan kode (coupling). Semakin kuat modul bergantung satu sama lain, semakin tinggi kemungkinan bahwa perubahan di satu modul akan menyebabkan regresi di modul lain. Antipola klasik: God Object (objek yang melakukan segalanya), Shotgun Surgery (perubahan satu memerlukan perbaikan di puluhan tempat), Circular Dependency. Mengurangi coupling — tugas arsitektur: prinsip SOLID, Dependency Injection, arsitektur heksagonal.

Penyebab kedua — kurangnya pengujian untuk fungsionalitas yang diubah. Jika kode tidak tercakup oleh pengujian, pengembang hanya mengetahui tentang regresi dari QA atau pengguna. Menurut Google Testing Blog, proyek dengan cakupan pengujian >75% memiliki 5 kali lebih sedikit regresi dibandingkan proyek dengan cakupan <25%. TDD (Test-Driven Development) menjamin bahwa pengujian ditulis sebelum kode, bukan “ketika ada waktu”.

Penyebab ketiga — faktor manusia. Pengembang tidak mengetahui keberadaan fungsionalitas yang berdekatan, tidak memahami semua dependensi, atau hanya terburu-buru. Penyebab — berbagi pengetahuan tentang basis kode yang tidak memadai. Solusi: code review dengan partisipasi pengembang dari modul lain, pair programming, dokumentasi arsitektur. Bus factor proyek berbanding terbalik dengan jumlah keputusan arsitektur yang didokumentasikan.

Pengujian regresi dan perannya

Pengujian regresi — adalah proses menjalankan kembali pengujian yang ada setelah setiap perubahan untuk memeriksa apakah fungsionalitas lama tidak rusak. Ini adalah satu-satunya cara untuk menjamin bahwa perubahan baru tidak mengganggu kinerja kode yang ada. Tanpa pengujian regresi, setiap rilis adalah lotere: pengembang berharap tidak merusak apa pun, tetapi tidak dapat memastikannya.

Pengujian regresi manual — pendekatan termahal dan paling tidak efisien. Seiring pertumbuhan proyek, jumlah skenario pengujian regresi meningkat secara linear, dan waktu untuk menjalankannya secara manual — secara eksponensial. Setelah 2–3 tahun pengembangan, menjalankan regresi secara manual dapat memakan waktu 2–3 minggu, yang membuat rilis sering menjadi tidak mungkin. Satu-satunya jalan keluar adalah otomatisasi.

Pengujian regresi otomatis dibagi menjadi beberapa tingkatan menurut piramida pengujian:

• Pengujian unit — cepat, terisolasi, mencakup fungsi dan metode individual
• Pengujian integrasi — memeriksa interaksi antar modul, DB, layanan eksternal
• Pengujian E2E — memeriksa skenario pengguna lengkap melalui UI atau API
• Pengujian snapshot — membandingkan keluaran komponen saat ini dengan referensi

Menurut Google Testing Blog, rasio optimal: 70% pengujian unit, 20% integrasi, 10% E2E. Penyimpangan dari rasio ini mengurangi efektivitas pengujian regresi: kelebihan pengujian E2E memperlambat pipeline, kekurangan pengujian unit membuat microbug tidak terdeteksi.

Strategi otomatisasi pengujian regresi

Strategi pertama — Full Regression. Semua pengujian proyek dijalankan. Pendekatan paling andal, tetapi juga paling lambat. Cocok untuk proyek kecil (hingga 10.000 pengujian, waktu eksekusi <30 menit). Untuk proyek besar, regresi penuh dapat memakan waktu berjam-jam, yang membuat pipeline CI/CD tidak praktis.

Strategi kedua — Selective Regression. Hanya pengujian yang terkait dengan kode yang diubah yang dijalankan. Untuk menentukan hubungan, digunakan grafik dependensi kode. Alat: Bazel (Google), Nx (JavaScript), sbt (Scala). Selective regression menghemat 60–80% waktu eksekusi, tetapi memerlukan pembuatan grafik dependensi yang akurat — kesalahan menyebabkan regresi terlewatkan.

Strategi ketiga — Prioritized Regression. Semua pengujian diperingkat berdasarkan prioritas: critical path (skenario pengguna terpenting), high risk (kode dengan riwayat bug), changed code (kode yang terpengaruh oleh perubahan). Pertama, pengujian dengan prioritas tertinggi dijalankan — jika lulus, pengembang mendapatkan umpan balik cepat. Eksekusi terbatas waktu: dalam 10 menit pengujian kritis diperiksa, sisanya — di latar belakang.

Cara mencegah regresi dalam proyek

Langkah pertama dan terpenting — budaya menulis pengujian. Setiap perubahan harus disertai dengan pengujian yang memeriksa bahwa perubahan berfungsi dan pengujian yang memeriksa bahwa tidak ada yang rusak. TDD (Test-Driven Development) memberikan hasil terbaik: pengembang pertama-tama menulis pengujian yang gagal, lalu kode yang membuatnya lulus. Ini menjamin bahwa pengujian ada sebelum kode.

Langkah kedua — pipeline CI/CD dengan eksekusi pengujian wajib. Pull request tidak dapat digabungkan sampai semua pengujian lulus. Pengujian tidak dapat “dilewati” karena urgensi — perubahan mendesak melalui rangkaian pengujian yang dipercepat tetapi wajib. Menurut Google DevOps Research, tim dengan CI/CD wajib memiliki 3 kali lebih sedikit regresi di produksi.

Langkah ketiga — monitoring di produksi. Bahkan pengujian terbaik pun tidak menjamin perlindungan 100% terhadap regresi. Alat observability (Sentry, Datadog, New Relic) harus melacak metrik utama setelah setiap penerapan: tingkat kesalahan, latensi, throughput. Pengembalian otomatis (rollback) saat melebihi ambang batas — bantalan pengaman jika regresi tetap masuk ke produksi.

Langkah keempat — code review dengan pemikiran regresi. Peninjau harus mengajukan pertanyaan: “Modul lain mana yang mungkin rusak karena perubahan ini?”. Tidak cukup memeriksa bahwa kode itu benar — perlu memeriksa bahwa kode tidak akan mengganggu fungsionalitas yang berdekatan. Daftar periksa untuk code review harus menyertakan poin “pemeriksaan regresi di modul yang berdekatan”.