Pengujian Regresi dalam Pengembangan Aplikasi Mobile — apa itu, jenis dan bagaimana dilakukan

Apa itu pengujian regresi?

Pengujian regresi adalah jenis pengujian yang bertujuan untuk mengonfirmasi bahwa perubahan dalam kode tidak merusak fungsionalitas yang ada. Istilah „regresi” berarti kembali ke keadaan yang lebih buruk — ketika fungsi yang berfungsi di versi sebelumnya berhenti berfungsi di versi baru. Tes regresi dijalankan berulang kali pada setiap siklus pengembangan, yang membedakannya dari tes fungsionalitas baru yang ditulis sekali.

Kebutuhan pengujian regresi muncul dari efek perubahan berantai: perbaikan bug dalam satu modul dapat menyelesaikan masalah tetapi merusak fungsionalitas di sekitarnya yang bergantung padanya. Misalnya, mengubah kueri SQL di repositori pengguna dapat mempercepat login tetapi merusak ekspor data yang menggunakan kueri yang sama. Tes regresi pada ekspor data akan mendeteksi pelanggaran ini sebelum rilis.

Menurut laporan CISQ 2023, biaya perbaikan cacat regresi yang terdeteksi di produksi 15 kali lebih tinggi daripada pada tahap proses regresi otomatis. Perusahaan yang berinvestasi dalam pengujian regresi otomatis mengurangi proporsi cacat regresi dalam rilis dari 25% menjadi 5% dalam satu tahun setelah implementasi, menurut Capgemini World Quality Report.

Jenis pengujian regresi

Ada beberapa pendekatan untuk pengujian regresi, yang berbeda dalam volume dan kriteria pemilihan tes. Pemilihan pendekatan tergantung pada ukuran proyek, frekuensi perubahan, dan waktu yang tersedia di pipeline CI. Berikut adalah jenis utama pengujian regresi dengan karakteristiknya.

Pengujian regresi penuh

Proses regresi penuh menjalankan semua tes otomatis proyek tanpa kecuali. Pendekatan ini memberikan keyakinan maksimal tetapi membutuhkan sumber daya komputasi dan waktu yang signifikan. Proses penuh dilakukan sebelum rilis besar — setiap 2–4 minggu. Untuk aplikasi dengan 5000 tes, proses penuh memakan waktu 2 hingga 6 jam tergantung pada infrastruktur.

Pengujian regresi selektif

Pendekatan selektif hanya menjalankan tes yang terkait dengan modul yang diubah. Untuk menentukan keterkaitan, digunakan analisis dependensi pada tingkat kode: jika kelas UserRepository diubah, tes yang bergantung pada UserRepository secara langsung atau transitif akan dijalankan. Alat Jacoco, Android Test Coverage, dan Xcode Code Coverage menyediakan peta cakupan untuk pemilihan yang tepat. Proses selektif dilakukan pada setiap pull request dan memakan waktu 5–15 menit.

Regresi berbasis risiko

Regresi berbasis risiko memeringkat tes berdasarkan kritikalitas fungsionalitas dan kemungkinan kerusakan. Fungsi kritis — pembayaran, otorisasi, sinkronisasi — diuji pada setiap perubahan kode. Fungsi pendukung — layar „Tentang Aplikasi”, animasi — hanya diuji sebelum rilis. Pemeringkatan ditinjau setiap kuartal berdasarkan data insiden produksi.

Perbedaan pengujian regresi dengan retest

Seringkali konsep pengujian regresi dan retest tertukar, meskipun ini adalah proses yang berbeda. Retest adalah menjalankan ulang tes tertentu yang sebelumnya gagal, setelah perbaikan cacat. Tujuan retest adalah memastikan perbaikan berfungsi: bug tidak lagi terulang. Retest dilakukan sekali, segera setelah perbaikan dan konfirmasi perbaikan oleh pengembang.

Pengujian regresi adalah menjalankan tes pada fungsionalitas yang ada yang TIDAK diubah. Tujuannya adalah memastikan bahwa perbaikan satu cacat tidak menciptakan cacat baru di tempat lain. Tes regresi dijalankan berulang kali pada setiap siklus pengembangan, terlepas dari bug spesifik apa yang diperbaiki. Perbedaan utama: retest memeriksa perbaikan itu sendiri, regresi memeriksa konsekuensi perbaikan.

Di pipeline CI/CD, kedua proses dijalankan secara berurutan. Setelah pull request digabungkan, retest bug spesifik dijalankan, diikuti oleh proses regresi penuh atau selektif. Menurut SmartBear (2022), pemisahan proses ini mengurangi waktu diagnostik proses CI yang gagal sebesar 30%, karena tim segera melihat bagian mana dari cacat terkait dengan regresi dan mana dengan perbaikan yang tidak berfungsi.

Otomatisasi pengujian regresi

Otomatisasi pengujian regresi adalah faktor keberhasilan kritis untuk proyek mobile modern. Pengujian regresi manual tidak dapat diskalakan: dengan set 200 tes, satu proses membutuhkan 2–3 hari kerja insinyur QA, yang membuat proses harian tidak mungkin dilakukan. Tes regresi otomatis dijalankan dalam 10–60 menit tanpa campur tangan manusia, memungkinkannya dijalankan pada setiap commit atau pull request.

• Tes unit — dasar set regresi (70%). Dijalankan dalam hitungan detik, tidak memerlukan emulator, menunjukkan kelas yang rusak dengan tepat.
• Tes integrasi — tingkat kedua (20%). Memeriksa lapisan jaringan, database, dan layanan sistem dengan dependensi yang terkontrol.
• Tes UI dan E2E — puncak piramida (10%). Mencakup skenario pengguna kritis: pendaftaran, pembayaran, sinkronisasi.

Untuk menjaga set regresi tetap terkini, digunakan analitik tes: alat seperti Allure, ReportPortal, dan Xray melacak persentase kelulusan, durasi, dan stabilitas setiap tes. Tes yang stabilitasnya turun di bawah 90% (sering rusak karena perubahan persyaratan) ditandai sebagai legacy dan dikirim untuk ditinjau oleh pemiliknya.

Contoh konfigurasi tes regresi

Mari kita lihat konfigurasi tes regresi otomatis di Android menggunakan pustaka JUnit 5 dan Espresso. Contoh ini menunjukkan regresi selektif — tes memeriksa bahwa setelah refactoring repositori pengguna, layar profil tidak rusak. Untuk iOS digunakan XCTest dengan logika serupa — tes berulang pada skenario utama.

Android: tes regresi profil

Tes menggunakan MockWebServer untuk emulasi server dan memeriksa jalur lengkap: memuat data pengguna, menampilkan di layar profil, dan menangani kesalahan saat server tidak tersedia. Tes semacam itu disertakan dalam set regresi dan dijalankan pada setiap perubahan di module-profile.

@RunWith(AndroidJUnit4::class)
class ProfileRegressionTest {

    @get:Rule
    val composeRule = createComposeRule()

    @Test
    fun profileScreen_rendersCorrectly() {
        val user = User(id = 1, name = "Alice", email = "alice@test.com")
        composeRule.setContent {
            ProfileScreen(user)
        }
        composeRule.onNodeWithText("Alice").assertIsDisplayed()
        composeRule.onNodeWithText("alice@test.com").assertIsDisplayed()
    }

    @Test
    fun profileScreen_handlesNetworkError() {
        setNetworkError()
        composeRule.onNodeWithText("Kesalahan pemuatan").assertIsDisplayed()
    }
}

iOS: tes regresi dengan XCTest

Untuk iOS, tes regresi menggunakan XCTestExpectation untuk pemeriksaan asinkron pembaruan UI setelah menerima data dari API. Tes meniru respons jaringan dan memeriksa bahwa elemen UI telah diperbarui dengan benar.

class ProfileRegressionTests: XCTestCase {
    func testProfileScreen_rendersCorrectly() {
        let viewModel = ProfileViewModel(userId: 1)
        let view = ProfileView(viewModel: viewModel)
        viewModel.loadProfile()

        let expectation = expectation(description: "profile loaded")
        viewModel.onProfileLoaded = {
            XCTAssertEqual(viewModel.userName, "Alice")
            XCTAssertEqual(viewModel.userEmail, "alice@test.com")
            expectation.fulfill()
        }
        waitForExpectations(timeout: 3.0)
    }
}

Strategi membangun set regresi

Membangun set regresi yang efektif adalah proses berulang berdasarkan data tentang cacat dan perubahan kode. Strategi utama adalah menyertakan semua tes yang ada dalam set regresi dan menjalankan proses penuh sebelum setiap rilis. Seiring pertumbuhan basis tes (di atas 2000 tes), proses penuh menjadi terlalu lama dan memerlukan pendekatan selektif.

Fase kedua — implementasi alat analisis dependensi: Jacoco untuk Android, Xcode Test Plan untuk iOS. Alat-alat ini membangun peta „tes — kelas — metode” dan memungkinkan menentukan tes mana yang terpengaruh oleh perubahan tertentu. Proses selektif berdasarkan analisis cakupan mengurangi waktu eksekusi sebesar 60–80% sambil mempertahankan 95% efektivitas deteksi regresi, menurut Spotify Engineering (2022).

Fase ketiga — pemantauan dan optimalisasi berkelanjutan. Tes yang tidak gagal selama 6 bulan dipindahkan ke set prioritas rendah. Tes yang gagal lebih dari sekali sebulan adalah kandidat untuk ditinjau: apakah mereka menangkap masalah nyata (memerlukan perbaikan) atau terlalu rapuh (memerlukan stabilisasi). Reviu triwulanan set regresi adalah praktik standar untuk mempertahankan efektivitas dan kecepatan eksekusinya.