Cara Menguji Aplikasi Anda Sebelum Peluncuran: Rencana Praktis Pra-Peluncuran

Untuk menguji aplikasi sebelum peluncuran, buat daftar beberapa alur yang harus bisa diselesaikan pengguna, jalankan masing-masing sebagai pengguna baru di laptop dan ponsel, lalu coba cara-cara pengguna bisa salah: data kosong, input buruk, akun kedua, koneksi lambat. Uji apa pun yang melibatkan uang atau data pribadi dengan lebih hati-hati, dan ulangi alur utama di URL live setelah publikasi. Selesaikan dengan mengamati seseorang yang belum pernah melihat aplikasi mencoba menggunakannya.

Anda tidak perlu tim QA atau framework pengujian untuk ini. Yang dibutuhkan adalah daftar, satu atau dua jam, dan kedisiplinan untuk benar-benar mengkliknya satu per satu.

Langkah 1: Tulis alur yang penting

Alur adalah tugas dari awal sampai akhir yang ingin diselesaikan pengguna. Kebanyakan aplikasi punya tiga sampai enam alur yang benar-benar penting. Untuk aplikasi booking:

Daftar dan konfirmasi akun
Cari kelas dan pesan
Batalkan pemesanan
Bayar paket kelas
Staf: lihat pemesanan hari ini

Jika Anda sudah menulis user stories, kriteria penerimaannya sudah menjadi kasus uji Anda. Jika belum, tulis satu baris per alur yang menjelaskan seperti apa "berhasil" itu.

Urutkan. Alur yang menghasilkan uang atau yang dilalui setiap pengguna (pendaftaran, login, aksi inti) diuji lebih dulu dan lebih menyeluruh.

Langkah 2: Uji jalur ideal sebagai pengguna baru

"Jalur ideal" adalah alur yang berjalan persis seperti yang dimaksudkan. Uji sebagaimana orang asing akan mengalaminya:

Gunakan jendela browser privat, agar Anda tidak dalam keadaan login dan tidak punya data tersimpan.
Gunakan akun baru dengan email sungguhan yang bisa Anda cek.
Mulai dari halaman utama atau tautan, bukan halaman yang Anda simpan sebagai bookmark saat membangun.

Pengguna baru tidak punya data. Banyak bug hanya muncul ketika daftar kosong, profil tidak punya foto, atau belum ada yang dibeli. Akun Anda sendiri yang penuh data uji justru menyembunyikannya.

Langkah 3: Coba buat aplikasinya rusak

Sekarang ulangi setiap alur dan lakukan hal yang salah dengan sengaja.

Coba ini	Yang diperiksa
Kirim formulir dalam keadaan kosong, atau hanya berisi spasi	Kolom wajib ditegakkan, dengan pesan yang jelas
Teks sangat panjang, emoji, nama dengan aksen	Tata letak tetap rapi, data tersimpan dengan benar
Format salah: huruf di kolom telepon, tanggal yang sudah lewat	Validasi di halaman dan di server
Klik ganda tombol kirim	Tidak ada pesanan atau booking ganda
Tombol kembali browser di tengah alur	Tidak ada keadaan rusak atau data yang hilang
Muat ulang di setiap halaman	Data tetap ada; tidak ada halaman kosong atau 404
Logout, lalu tekan kembali	Halaman privat tidak tampil
Dua tab mengedit hal yang sama	Penyimpanan terakhir tidak diam-diam menghapus yang pertama

Muat ulang layak diperhatikan: jika aplikasi berfungsi saat Anda mengkliknya, tetapi muat ulang di halaman yang lebih dalam menampilkan 404, lihat cara memperbaiki error 404 setelah deploy.

Langkah 4: Uji izin akses dengan dua akun

Ini adalah pengujian terpenting untuk aplikasi apa pun yang punya akun, dan yang paling sering dilewatkan.

Buat dua pengguna biasa, A dan B, serta (jika aplikasi Anda punya) satu admin.

Sebagai A, buat sebuah data. Login sebagai B. Apakah B bisa melihat, mengedit, atau menghapusnya? Seharusnya tidak, kecuali memang itu desainnya.
Sebagai A, salin URL salah satu data Anda. Login sebagai B dan buka URL itu secara langsung.
Sebagai pengguna biasa, buka halaman admin dengan mengetik URL-nya.
Logout sepenuhnya dan coba URL yang sama.

Jika Anda menemukan masalah di sini, jangan luncurkan sebelum diperbaiki. Pemeriksaan harus dilakukan di server, bukan hanya dengan menyembunyikan tombol. Daftar periksa keamanan untuk aplikasi yang dibuat dengan AI kami membahasnya lebih dalam.

Langkah 5: Uji di perangkat sungguhan

Buka aplikasi di ponsel sungguhan, bukan hanya di jendela browser yang sempit.

Bisakah Anda menekan setiap tombol tanpa memperbesar layar?
Apakah keyboard menutupi kolom yang sedang Anda ketik?
Apakah tabel dan konten lebar bisa di-scroll atau terbungkus, alih-alih mendorong halaman ke samping?
Apakah teks mudah dibaca tanpa dicubit?

Coba minimal satu iPhone (Safari) dan satu ponsel Android (Chrome) jika Anda bisa meminjamnya. Safari khususnya punya keunikan sendiri terkait tanggal, video, dan elemen dengan posisi tetap.

Langkah 6: Uji uang dan email dari awal hingga akhir

Segala sesuatu yang mengenakan biaya kartu atau mengirim email perlu dijalankan secara menyeluruh.

Pembayaran. Gunakan mode uji penyedia pembayaran Anda dan nomor kartu uji. Periksa pembayaran yang berhasil, kartu yang ditolak, dan checkout yang dibatalkan. Pastikan pesanan atau langganan muncul di aplikasi Anda setelah pembayaran, bukan hanya di dasbor penyedia. Jika aplikasi Anda mengandalkan webhook (pesan yang dikirim penyedia pembayaran ke server Anda), pastikan pesan itu sampai di aplikasi yang sudah dipublikasikan, bukan hanya di lingkungan pengembangan. Lalu, sebelum peluncuran, beralih ke kunci live dan lakukan satu pembelian nyata kecil yang Anda refund.

Email. Daftar dengan alamat sungguhan di dua atau tiga penyedia berbeda. Periksa apakah email sampai, tidak masuk spam, dan setiap tautan di dalamnya mengarah ke domain live, bukan alamat pratinjau.

Langkah 7: Periksa kecepatan dan error

Buka alat pengembang browser (klik kanan → Inspect) dan lihat tab Console di setiap halaman utama. Error merah layak diperbaiki meskipun tidak ada yang tampak rusak.
Muat situs di ponsel menggunakan data seluler, bukan Wi-Fi. Jika layar pertama membutuhkan beberapa detik, periksa ukuran gambar terlebih dahulu.
Jalankan audit gratis seperti Lighthouse di alat pengembang Chrome untuk gambaran cepat tentang performa dan aksesibilitas.

Langkah 8: Uji aplikasi yang sudah dipublikasikan, bukan hanya pratinjau

Pratinjau dan aplikasi yang dipublikasikan bukan lingkungan yang sama. Sebelum memberi tahu siapa pun tentang peluncuran, ulangi alur utama di URL live:

Apakah semua variabel lingkungan dan rahasia sudah diatur untuk aplikasi yang dipublikasikan?
Apakah memakai basis data yang benar, dengan data yang Anda harapkan?
Apakah redirect login dan tautan email memakai domain live?
Apakah muat ulang di halaman yang dalam termuat dengan benar?

Langkah 9: Amati orang lain menggunakannya

Beri satu atau dua orang sebuah tujuan ("pesan kelas yoga untuk Sabtu"), bukan instruksi. Amati, jangan bantu, dan catat di mana mereka ragu-ragu. Ini cara tercepat untuk menemukan kata-kata yang membingungkan dan tombol yang tersembunyi. Untuk versi yang lebih besar dari ini, lihat cara menjalankan beta test.

Ketika mereka menemukan bug, catat dengan baik: langkah-langkahnya, hasil yang diharapkan, dan hasil yang sebenarnya. Panduan kami tentang menulis laporan bug yang baik menunjukkan formatnya.

Menggunakan AI untuk membantu pengujian

Jika Anda membangun dengan AI, Anda bisa memintanya membantu merencanakan dan menjalankan pengujian:

Daftarkan alur pengguna utama di aplikasi ini dan, untuk masing-masing, kasus tepi yang paling mungkin rusak: keadaan kosong, input tidak valid, izin akses, dan muat ulang. Susun dalam daftar periksa yang bisa saya kerjakan.

Login sebagai dua pengguna uji yang berbeda dan periksa apakah pengguna B bisa melihat atau mengubah apa pun yang dibuat pengguna A, termasuk dengan membuka URL data A secara langsung. Laporkan apa yang Anda temukan sebelum memperbaiki apa pun.

Anggap laporan pengujian dari AI sebagai tahap pertama. Tetap klik sendiri alur uang dan izin akses.

Menguji di Mythex

Di Mythex, perintah /test menjalankan App Testing: agen mengendalikan browser terhadap pratinjau live Anda, mengklik halaman, mengambil tangkapan layar, dan melaporkan alur yang rusak di chat. Ini paling efektif untuk alur tertentu, seperti "uji pendaftaran dan booking kelas". Perbaiki yang ditemukan dengan /fix atau pesan biasa, lalu jalankan /test lagi. App Testing memakai pratinjau, jadi periksa sendiri alur utama di URL yang sudah dipublikasikan setelah publikasi. Lihat App Testing di dokumentasi, dan panduan kami tentang men-debug aplikasi yang dibuat dengan AI untuk saat sesuatu gagal.

Kesalahan umum

Hanya menguji sebagai diri sendiri. Akun admin Anda dengan banyak data menyembunyikan bug keadaan kosong dan izin akses.
Hanya menguji di laptop. Banyak pengunjung situs sekarang datang lewat ponsel.
Melewatkan akun kedua. Data yang bocor antarpengguna adalah bug paling serius yang bisa dimiliki aplikasi saat diluncurkan.
Terlalu percaya pada pratinjau. Aplikasi live punya pengaturan yang berbeda; uji juga.
Memperbaiki bug tanpa menguji ulang area sekitarnya. Perbaikan pada satu formulir bisa merusak formulir lain yang memakai kode yang sama.

Daftar periksa pra-peluncuran

Alur utama sudah dicatat dan diurutkan
Setiap alur lolos sebagai pengguna baru di jendela privat
Input kosong, tidak valid, sangat panjang, dan duplikat sudah ditangani
Muat ulang berfungsi di setiap halaman
Pengguna tidak bisa melihat atau mengubah data satu sama lain, bahkan lewat URL
Halaman admin diblokir untuk pengguna biasa dan pengunjung yang belum login
Berfungsi di iPhone dan ponsel Android sungguhan
Pembayaran diuji: berhasil, ditolak, dibatalkan, dan aplikasi diperbarui setelahnya
Email sampai, tidak masuk spam, dan tautannya mengarah ke domain live
Tidak ada error merah di console pada halaman utama
Alur utama diulang di URL yang sudah dipublikasikan
Setidaknya satu orang dari luar mencobanya sementara Anda mengamati

Pertanyaan

Seberapa banyak pengujian yang dibutuhkan aplikasi kecil sebelum diluncurkan?

Cukup untuk yakin bahwa alur utama berfungsi bagi pengguna baru di ponsel dan laptop, bahwa pengguna tidak bisa melihat data satu sama lain, dan bahwa apa pun yang melibatkan uang berfungsi dari awal hingga akhir. Untuk sebagian besar aplikasi kecil, itu hanya beberapa jam yang fokus, bukan berminggu-minggu.

Apakah MVP perlu pengujian otomatis?

Tidak selalu. Pengujian manual untuk alur inti menangkap sebagian besar bug yang menghambat peluncuran. Pengujian otomatis mulai bermanfaat ketika Anda sering mengubah aplikasi dan ingin segera tahu bahwa Anda tidak merusak sesuatu yang dulu berfungsi.

Sebaiknya saya menguji di pratinjau atau di aplikasi live?

Keduanya. Uji menyeluruh di pratinjau, lalu ulangi alur utama di aplikasi yang sudah dipublikasikan, karena variabel lingkungan yang belum diatur, basis data yang berbeda, atau pengaturan routing bisa membuat versi live berperilaku berbeda.

Siapa selain saya yang sebaiknya menguji aplikasi saya?

Setidaknya satu orang yang belum pernah melihatnya. Beri mereka tujuan, bukan instruksi, lalu amati tanpa membantu. Pembuat aplikasi tanpa sadar menghindari jalur-jalur yang bermasalah.