Website e-commerce belum siap hanya karena halaman produk dan tombol bayar sudah tampil. Yang perlu dibuktikan adalah satu rangkaian utuh: pelanggan memilih item yang benar, melihat total yang sesuai, menyelesaikan pembayaran, dan menerima status pesanan yang dapat ditindaklanjuti tim operasional.
Gunakan checklist ini bersama ruang lingkup proyek. Alur tanpa pengiriman, produk digital, atau pembelian grosir dapat membutuhkan skenario berbeda. Jangan menandai fungsi yang belum diuji sebagai lulus hanya karena tampilan depannya terlihat benar.
Siapkan Lingkungan dan Data Uji
Lakukan pengujian transaksi di staging dengan data simulasi dan mode sandbox yang didukung penyedia pembayaran. Pastikan uji tidak memicu pemotongan stok nyata, pengiriman barang, invoice bisnis, atau notifikasi kepada pelanggan sungguhan. Periksa efek setiap integrasi sebelum menjalankan skenario.
Dokumentasi Testing Orders dari WooCommerce mengingatkan bahwa pesanan uji dapat memicu email dan masuk ke analitik. Karena itu, mode pembayaran uji saja belum cukup untuk mengisolasi seluruh dampak operasional.
1. Cocokkan Produk, Varian, dan Keranjang
Pilih produk dengan beberapa varian, produk yang tidak tersedia, serta produk dengan satuan penjualan khusus jika ada. Periksa apakah foto, kode, harga, jumlah, dan pilihan varian tetap konsisten saat item masuk ke keranjang.
Uji perubahan jumlah dan penghapusan item. Total harus dihitung ulang sesuai aturan yang disetujui. Jika stok tidak disinkronkan secara langsung, website perlu menjelaskan mekanisme konfirmasi ketersediaan agar pelanggan tidak diberi kepastian yang belum dapat dibuktikan.
2. Periksa Alamat dan Komponen Total
Gunakan beberapa tujuan pengiriman, termasuk tujuan yang tidak dilayani jika pembatasan wilayah berlaku. Tinjau berat, dimensi, ongkir, diskon, dan komponen biaya lain sesuai konfigurasi bisnis. Uji juga ketika layanan ongkir tidak memberikan respons.
Perilaku gagal harus jelas: pelanggan dapat memperbaiki alamat, mencoba kembali, atau menggunakan jalur kontak. Hindari membiarkan checkout menampilkan ongkir nol yang dapat dianggap sebagai pengiriman gratis ketika sebenarnya perhitungan gagal.
3. Uji Status Pembayaran, Bukan Hanya Halaman Sukses
Siapkan skenario pembayaran berhasil, tertunda, gagal, dibatalkan, dan kedaluwarsa sejauh didukung integrasi. Cocokkan status pada penyedia pembayaran dengan catatan pesanan di website. Membuka halaman “terima kasih” tidak dengan sendirinya membuktikan pembayaran diterima.
Periksa pula ketika pelanggan menutup browser lalu kembali. Tim perlu tahu pesanan mana yang masih menunggu pembayaran dan mana yang sudah dapat diproses. Panduan implementasi API yang lebih teknis tersedia pada artikel integrasi payment gateway Layana.ID; checklist ini berfokus pada hasil yang harus dapat diamati pembeli dan operator.
4. Ikuti Pesanan sampai Tim Operasional
Pastikan tim yang berwenang dapat menemukan item, alamat, status, dan informasi yang diperlukan untuk pemenuhan pesanan. Uji notifikasi pada penerima simulasi, lalu cocokkan isinya dengan catatan website. Status pesanan dan status pembayaran perlu dibedakan ketika alurnya memang berbeda.
Jika pembatalan, refund, atau retur termasuk ruang lingkup, uji cara pengajuan, persetujuan, perubahan status, serta efeknya pada stok dan laporan. Jika belum termasuk, catat sebagai batas cakupan dan jelaskan proses manual yang akan digunakan.
5. Periksa Pengalaman Mobile dan Jalur Pemulihan
Coba alur dari perangkat atau viewport sempit sampai checkout. Periksa label input, pesan kesalahan, tombol yang tertutup elemen mengambang, dan kemampuan kembali ke keranjang tanpa kehilangan pilihan. Uji navigasi keyboard untuk formulir serta tindakan utama.
Pengujian alur ini tidak menggantikan audit keamanan atau uji beban. Kebutuhan tersebut perlu ditentukan tersendiri berdasarkan data yang dikelola, integrasi, dan perkiraan pemakaian.
Catat Bukti dan Keputusan Peluncuran
Setiap skenario sebaiknya memuat ID, lingkungan, data uji, hasil yang diharapkan, hasil aktual, bukti, dan PIC. Contoh: EC-03, pembayaran sandbox kedaluwarsa; hasil yang diharapkan “belum boleh dipenuhi”; bukti berupa status pesanan dan catatan penyedia pembayaran.
Tutup temuan yang dapat menyebabkan total salah, pembayaran tidak tercatat, atau pesanan diproses keliru sebelum rilis. Bedakan hasil staging dari verifikasi konfigurasi produksi. Pengujian yang menimbulkan transaksi nyata perlu perencanaan dan otorisasi tersendiri.
Bahas skenario penerimaan ini saat menyusun proyek website e-commerce bersama Layana.ID. Tentukan fitur yang diuji, pihak yang memberi persetujuan, dan dukungan setelah peluncuran dalam penawaran; jumlah skenario bergantung pada alur yang disepakati.