Strategi testing saat migrasi aplikasi Android ke web harus langsung menjawab kekhawatiran utama: apakah perilaku, performa, dan pengalaman pengguna tetap konsisten ketika logika berpindah ke browser. Untuk itu, kita butuh peta use case Android, lapisan pengujian yang sesuai, serta workflow verifikasi yang mencegah regresi sebelum rilis. Tulisan ini terinspirasi dari pengalaman migrasi nyata dan dirancang agar tim engineering tetap fokus pada kualitas fungsional dan teknis.

Memetakan Use Case Android ke Fitur Web

Langkah pertama adalah memetakan fungsi-fungsi Android ke fitur yang akan berjalan di web. Gunakan matriks use case: kolom untuk fitur (navigasi layar, notifikasi, sinkronisasi data, otentikasi), baris untuk komponen web (route, API, service worker, UI). Mencatat batasan platform membantu memilih alternatif implementasi nyata web seperti strategi polling vs push.

  • State lifecycle: Android punya lifecycle activity/fragment. Web mengandalkan routing dan component mount. Identifikasi transisi yang harus diuji ulang (misal: dari list ke detail dan kembali tanpa kehilangan state).
  • Integrasi native: Jika Android memakai sensor atau push, tentukan apakah web menggantinya dengan Web Push, Background Sync, atau polyfill. Sertakan asumsi dalam dokumentasi testing.
  • Handling offline: Pada Android, offline cache bisa diaktifkan via Room/SQLite; di web, service worker dan IndexedDB. Pastikan skenario sync yang sebelumnya diuji di Android juga dicakup.

Dokumen ini semakin berguna jika dimasukkan dalam requirement testing sehingga QA tahu fungsi mana yang wajib ditranslasikan dan mana yang memerlukan penyesuaian UI/UX.

Lapisan Testing Berlapis dengan E2E, Contract, dan Visual Regression

Strategi pengujian harus mencakup setidaknya tiga lapisan: end-to-end, contract, dan visual regression. Masing-masing menangani regressi berbeda dan memastikan tim tidak hanya bergantung pada satu jenis test.

End-to-End Testing

Gunakan e2e test (misal Cypress atau Playwright) untuk memvalidasi alur utama seperti login, navigasi, dan penanganan error API. Fokus pada user flow yang sebelumnya diuji di Android. Contoh test Cypress untuk flow login:

describe('Login dan Sync', () => {
  it('menyelesaikan login dan menampilkan dashboard', () => {
    cy.visit('/login');
    cy.get('[data-test=email]').type('[email protected]');
    cy.get('[data-test=password]').type('s3cret');
    cy.get('form').submit();
    cy.url().should('include', '/dashboard');
    cy.contains('Data Terbaru').should('be.visible');
  });
});

Pastikan test memeriksa efek samping seperti penyimpanan local (misalnya token di localStorage) agar tidak ada regresi state.

Contract Testing

Contract test menjaga konsistensi API backend dengan klien web. Gunakan Pact atau Postman test suite untuk memverifikasi response structure dan kode status sesuai asumsi Android. Dengan contract, perubahan backend yang memutus flow migrasi bisa dideteksi lebih awal. Fokus pada contract yang sering dipakai (autentikasi, list data utama, sync) agar tidak ada kejutan runtime.

Visual Regression

Visual regression mencegah perbedaan UI yang tidak diinginkan saat berpindah ke web. Alat seperti Percy atau Reg-Suit bisa menangkap snapshot halaman penting dan memperingatkan perbedaan layout akibat CSS baru. Fokus pada area yang sebelumnya memiliki desain spesifik di Android seperti bentuk kartu, tombol CTA, atau state loading.

Untuk menghindari false positive, batasi snapshot ke elemen yang stabil dan gunakan toleransi yang wajar terhadap perubahan warna kecil.

Identifikasi Area Rentan Flaky Test dan Mitigasi

Flaky test sering muncul ketika kita bergantung pada waktu tunggu, state asynchronous, atau resource eksternal. Identifikasi area rentan membantu memilih strategi mitigasi.

  • Koneksi jaringan: Pengujian di Android biasanya mengandalkan mock network. Di web, pastikan e2e maupun contract test memakai mock server yang bisa direset dan tidak memicu timeout default.
  • Animasi atau delay UI: Jika Anda punya animasi transisi, jadikan selector lebih deterministik (pakai data-test) dan hindari menunggu waktu tetap. Gunakan assertion based on state ready.
  • Integrasi async: Alur sync data mungkin berjalan di background. Pakai hook (misal event bus atau observer) untuk mengetahui kapan data selesai dan jangan hanya mengandalkan timeout.

Catat metrik keandalan berikut sebagai bagian dari monitoring regression:

  • Latency: Pantau 95th percentile waktu respons API dan render halaman utama agar tidak ada regresi performa.
  • Error rate: Hitung persentase request gagal di staging/test environment setelah deployment testing.
  • Flake rate: Terapkan pencatatan rerun test (misal e2e rerun max 2 kali) untuk menghitung persentase kegagalan non-deterministik.

Gunakan data ini dalam dashboard QA sehingga tim tahu apakah perubahan memperburuk reliabilitas.

Workflow Verifikasi Pra-Rilis

Workflow testing harus terintegrasi dengan pipeline CI/CD. Berikut tahap yang terbukti efektif:

  1. Build Staging Web: Setelah CI selesai, deploy ke staging dengan environment menyerupai production (sama domain, HTTPS, API endpoint).
  2. Contract & API Smoke: Jalankan suite contract, lalu smoke test API yang memegang peran vital (login, fetch utama).
  3. Regression E2E: Jalankan e2e utama; bila ada failure, log detail (screenshots, video) dan integrasikan dengan ticket.
  4. Visual Regression: Snapshot halaman kritikal; QA review perbedaan via PR review atau dashboard visual.
  5. Checklist Manual: QA/PO memverifikasi daftar hal-hal prioritas sebelum release ke production.

Checklist Testing Utama

  • Gunakan data sample yang sama dengan Android untuk memastikan tampilan dan data konsisten.
  • Pastikan form validasi dan error handling bekerja dengan feedback yang sama.
  • Verifikasi integrasi webhook/push (jika ada) dari perspektif web.
  • Test fallback jika API utama tidak tersedia (error screen, retry).
  • Konfirmasi perbedaan resolusi layar di browser dengan responsive test.

Penutup

Migrasi dari Android ke web bukan sekadar porting UI, melainkan memastikan perilaku, performa, dan reliabilitas tetap terjaga. Dengan memetakan use case secara detail, menggabungkan lapisan testing yang saling melengkapi, mengamati area flaky, serta menformalisisasi workflow verifikasi, tim bisa mendeteksi regresi sebelum pengguna akhir terpengaruh.

Ingat bahwa pengukuran metrik seperti latency, error rate, dan flake rate memberikan sinyal yang konkret tentang kesiapan release. Terus lakukan pruning terhadap test yang tidak memberikan nilai dan perkuat coverage pada area yang kritikal.