Tiket Senin pagi: menguji alur pendaftaran sampai pembayaran seperti yang dialami pengguna sungguhan

Bayangkan sebuah tiket dukungan dengan judul hanya empat kata: sudah bayar, tidak terjadi apa-apa, tolong. Tiket itu masuk pukul 8.52 di hari Senin — waktu paling buruk untuk mulai mempelajari hal baru tentang alur penagihan Anda sendiri. Kalau Anda sudah cukup lama menangani produk berbayar, versi lain dari cerita ini pasti terasa familier.

Pelanggan itu tidak melakukan hal aneh. Mendaftar Minggu malam, teralihkan sebelum sempat membuka email verifikasi, kembali keesokan paginya, langsung menuju halaman harga, lalu membayar. Transaksinya berhasil. Setelah itu tidak ada apa-apa — tanpa tanda terima, tanpa peningkatan paket, tanpa pesan selamat datang. Dari sudut pandang produk, ini adalah pendaftaran setengah jadi yang kebetulan sudah membayar.

Semua tes hijau. Pendaftaran sudah diuji. Pengiriman email sudah diuji. Alur checkout diuji dengan sangat teliti oleh orang-orang yang benar-benar peduli. Bug-nya bersembunyi di satu-satunya tempat yang tidak dimiliki siapa pun: job pembuat tanda terima membaca sebuah field yang hanya terisi ketika seseorang mengeklik tautan verifikasi, dan pelanggan ini membayar sebelum mengeklik. Urutan kejadian yang sangat wajar baginya, dan tidak pernah dijalankan oleh satu pun tes di suite, karena semua tes dimulai dari pengguna yang sudah terverifikasi.

Begitulah sifat sambungan antarsistem. Tim pendaftaran memiliki pendaftaran. Tim penagihan memiliki penagihan. Ruang di antara keduanya menjadi milik siapa pun yang kebetulan melintasinya — dan jika tidak ada yang melakukannya dengan sengaja, orang pertama yang melintas adalah pelanggan yang membayar, pada Senin pagi.

Alasan Anda tidak pernah menemukannya: Anda tidak bisa menjadi orang baru

Ini bagian yang tidak nyaman. Bahkan setelah Anda tahu ada bug semacam itu, mereproduksinya tetap merepotkan — karena Anda tidak bisa dengan mudah menjadi pengguna baru. Alamat email Anda sudah ada di tabel pengguna. Ia juga menjadi catatan pelanggan di penyedia pembayaran, kontak di alat pemasaran, satu baris di analitik, dan anggota dua kohort feature flag yang sudah Anda lupakan. Browser Anda membawa sesi lama, kartu tersimpan, serta tooltip onboarding yang Anda tutup kuartal lalu.

Ketika Anda menguji pendaftaran dengan alamat sendiri, Anda menempuh jalur yang tidak akan pernah dilalui pelanggan sungguhan. Anda melewati persis bagian tempat mereka tersendat, dan tidak pernah melihat tampilan kosong, tawaran upsell pertama kali, atau email selamat datang yang diam-diam berhenti terkirim sejak Maret.

Menjadi benar-benar baru butuh dua hal sekaligus: identitas yang belum pernah dilihat sistem, dan browser yang belum pernah bertemu sistem. Keduanya hanya butuh sekitar satu menit persiapan. Lewatkan salah satunya, dan sesi pengujian itu tidak akan memberi tahu apa pun.

Menyiapkan panggung

Kotak masuk email sementara menyelesaikan separuh soal identitas — alamat yang tidak ada di mana pun dalam stack Anda, siap dalam sedetik, dan masih bisa dibaca ketika tanda terima muncul dua puluh menit kemudian. Sisanya hanya soal disiplin terhadap state:

• Profil browser yang bersih, bukan sekadar jendela penyamaran. Mode incognito mengurus cookie, tetapi profil terpisah juga berarti tanpa ekstensi dan tanpa kartu yang terisi otomatis — keduanya diam-diam mengubah perilaku halaman checkout.
• Alamat yang belum pernah dilihat produk ini, sehingga Anda membuat catatan baru alih-alih bertabrakan dengan catatan lama.
• Identitas pembayaran yang baru juga. Memakai ulang pelanggan uji berarti memakai ulang kartu tersimpan dan riwayat fakturnya, yaitu persis kondisi yang tidak dimiliki pembeli pertama kali.
• Nama dan perusahaan yang berbeda. Data yang terlihat seperti data uji memicu validasi berbeda dibanding data yang terlihat seperti milik orang sungguhan.
• Lingkungan staging, diarahkan ke penyedia pembayaran dalam mode uji. Jangan pernah produksi, jangan pernah kartu asli.

Langkah 1: Daftar, dan benar-benar baca emailnya

Tempel alamatnya lalu kirim. Pesannya seharusnya masuk dalam beberapa detik — kalau butuh tiga puluh detik, catat itu, sebab pengguna yang menatap layar "cek kotak masuk Anda" selama setengah menit adalah pengguna yang mulai meragukan Anda. Lalu bacalah dengan benar, bukan sekadar memburu tombolnya:

• Waktu tiba. Ukur. Ini metrik yang memburuk saat beban tinggi, dan tidak ada yang menyadarinya sampai hari peluncuran.
• Siapa pengirimnya. Nama merek yang mudah dibaca, atau hostname no-reply? Apakah balasan sampai ke manusia atau lenyap begitu saja?
• Tautannya, klik dua kali. Sekali untuk verifikasi. Sekali lagi untuk memastikan token hanya sekali pakai dan percobaan kedua ditolak dengan sopan alih-alih melempar error 500.
• Kedaluwarsa. Biarkan satu tautan tidak terpakai melewati masa berlakunya, lalu pastikan ia ditolak dengan pesan yang menjelaskan cara mendapatkan tautan baru.
• Huruf besar-kecil. Daftar lagi dengan kapitalisasi berbeda. Domain tidak membedakan huruf besar-kecil sesuai RFC 5321, dan hampir semua produk memperlakukan bagian lokal dengan cara yang sama, jadi ini tidak boleh menghasilkan akun kedua.
• Kondisi belum terverifikasi — inilah kondisi dari skenario pembuka. Sebelum mengeklik apa pun, lihat apa saja yang sudah diizinkan aplikasi. Bisakah Anda mengundang rekan tim? Bisakah Anda membayar? Kadang itu memang disengaja. Kadang itu adalah tiket Senin pagi yang sedang menunggu waktunya.

Kalau verifikasi adalah perhatian utama Anda, topik itu layak mendapat sesi tersendiri — kami membahas token dan kasus tepi lebih dalam di bagaimana pengembang menguji alur verifikasi email.

Langkah 2: Bagian sunyi sebelum uang berpindah

Di antara verifikasi dan pembayaran ada sekelompok kecil pesan otomatis — selamat datang, pengingat onboarding, "selesaikan pengaturan akun Anda". Ini adalah email yang paling jarang diuji di sebagian besar produk, karena yang mengirimnya adalah job latar belakang, bukan tombol yang diklik seseorang saat pengujian.

Biarkan kotak masuk terbuka dan amati. Email selamat datang ganda, pengingat yang menyala sembilan puluh detik setelah pendaftaran, atau sapaan dengan nama yang tidak pernah Anda ketik — semuanya cacat nyata, dan semuanya tidak terlihat kecuali ada manusia yang membaca kotak surat itu.

Langkah 3: Tahap pembayaran — selalu di sandbox

Sekarang bagian yang dihindari banyak orang, karena menyentuh pembayaran terasa berbahaya. Ia hanya berbahaya di lingkungan yang salah. Setiap penyedia serius menyediakan sandbox justru untuk keperluan ini: Stripe menerbitkan satu set lengkap kartu uji, dan PayPal menyediakan akun sandbox yang berperilaku seperti aslinya tanpa memindahkan sepeser pun.

Gunakan itu. Jangan pernah mengetik nomor kartu asli di lingkungan pengujian — bukan milik Anda, apalagi milik rekan kerja atau pelanggan. Data kartu asli menarik mesin yang sedang Anda pakai ke dalam cakupan PCI DSS, dan server staging adalah tempat terakhir yang pantas untuk itu. Nomor uji ada supaya hal ini tidak pernah perlu jadi bahan pertimbangan.

Nilainya justru ada pada penolakan untuk berhenti di jalur mulus. Checkout yang hanya berfungsi ketika semuanya berjalan lancar sebenarnya belum benar-benar diuji:

• Keberhasilan yang bersih. Pembayaran disetujui, paket benar-benar aktif, pengguna mendarat di tempat yang bermakna alih-alih dasbor kosong.
• Penolakan biasa. Apakah pengguna mendapat penjelasan yang jelas dan data formulirnya tetap tersimpan, atau justru stack trace dan keranjang kosong?
• Saldo tidak mencukupi. Berbeda dari penolakan umum, dan pantas mendapat kalimat sendiri.
• Tantangan 3-D Secure. Autentikasi pelanggan yang kuat bersifat wajib di banyak pasar. Selesaikan sekali — lalu jalankan lagi dan tinggalkan di tengah jalan. Tantangan yang ditinggalkan tidak boleh menyisakan langganan setengah jadi.
• Kartu kedaluwarsa dan CVC salah. Dua jalur error yang gemar runtuh menjadi satu pesan tak berguna.
• Kirim ganda. Klik bayar dua kali dengan cepat. Satu tagihan, bukan dua. Ini bug termahal di daftar ini kalau sampai lolos.
• Tombol kembali. Bayar, tekan kembali, kirim ulang. Pertanyaan yang sama lewat pintu berbeda.
• Mata uang dan pajak. Kalau Anda menagih tiap wilayah berbeda, jalankan dua. Pajak dihitung di satu tempat dan ditampilkan di tiga tempat, dan ketiganya lama-lama tidak sinkron.

Kalau Anda memakai Stripe, nomor-nomor di bawah ini mencakup seluruh daftar tadi dan menghemat waktu Anda dari mengorek dokumentasi di tengah pengujian. Pasangkan salah satunya dengan tanggal kedaluwarsa di masa depan dan CVC tiga digit apa pun:

• 4242 4242 4242 4242 — keberhasilan yang bersih. Patokan dasar Anda.
• 4000 0000 0000 0002 — penolakan umum.
• 4000 0000 0000 9995 — saldo tidak mencukupi, yang seharusnya terbaca berbeda bagi pengguna dibanding penolakan umum.
• 4000 0000 0000 0069 — kartu kedaluwarsa.
• 4000 0000 0000 0127 — CVC salah.
• 4000 0025 0000 3155 — memaksa tantangan autentikasi 3-D Secure. Jalankan dua kali: sekali sampai selesai, sekali ditinggalkan di tengah jalan.

Penyedia lain menerbitkan set yang setara, jadi keenam skenario yang sama tetap berlaku — hanya nomornya yang berubah. Ada baiknya sesekali memeriksanya kembali di dokumentasi pengujian terbaru, karena penyedia memang kadang merevisinya.

Langkah 4: Tanda terima adalah bagian dari produk

Begitu pembayaran berhasil, kotak masuk menjadi layar paling menarik dalam pengujian. Tanda terima dibangun paling akhir dan dilupakan paling awal, padahal bagi pelanggan inilah artefak yang membuktikan semuanya benar-benar terjadi — berkas yang ia teruskan ke bagian keuangan, lampiran pada klaim penggantian biaya.

• Jumlahnya sama dengan halaman checkout. Terdengar sepele, dan lebih sering meleset dari yang Anda kira begitu diskon, proporsi, dan konversi mata uang ikut bermain.
• Pajak dirinci dengan benar untuk wilayah yang Anda uji.
• Nama paket adalah nama yang dikenal pelanggan, bukan plan_pro_v2_2024.
• Nomor faktur, tanggal, dan detail perusahaan tercantum dan bisa dibaca manusia.
• PDF atau tautan faktur terhosting bisa dibuka oleh orang yang tidak login. Orang keuangan yang menerima kiriman itu tidak punya akun.
• Setiap tautan mengarah ke alamat publik. Lingkungan staging sangat bersemangat menyelundupkan URL localhost ke dalam email.

Langkah 5: Perpanjangan dan pembayaran gagal, tanpa menunggu sebulan

Bug langganan bersembunyi di masa depan, dan itulah sebabnya mereka bertahan begitu lama. Tagihan perpanjangan, peringatan kartu akan kedaluwarsa, rangkaian penagihan tunggakan, pemberitahuan pembatalan terakhir — semuanya terjadi berminggu-minggu setelah rilis, dan saat itu tidak ada lagi yang mengawasi kotak masuk.

Anda tidak perlu menunggu. Test clock milik Stripe memajukan pelanggan uji melewati siklus penagihan hanya dalam hitungan detik, dan kebanyakan penyedia punya padanannya. Arahkan itu ke kotak masuk sekali pakai, dan surat-menyurat penagihan setahun penuh tiba dalam beberapa menit:

• Tanda terima perpanjangan terkirim pada hari yang tepat dengan jumlah yang tepat.
• Pemberitahuan tagihan mendatang, kalau Anda mengirimnya, tiba cukup awal untuk berguna.
• Rangkaian penagihan tunggakan meningkat secara masuk akal saat kartu terus gagal — dan berhenti begitu pembayaran berhasil. Orang yang sudah membayar tidak boleh menerima peringatan ketiga yang bernada marah.
• Pemberitahuan penurunan paket dan penguncian sesuai dengan apa yang sebenarnya masih bisa dilakukan akun tersebut.

Langkah 6: Batalkan, lalu kembalikan dananya

Tempuh sampai ujung. Batalkan langganan, lalu periksa apakah konfirmasinya berkata jujur soal apakah akses tetap berjalan sampai akhir periode berbayar atau langsung berhenti — satu kalimat itu menghasilkan lebih banyak tiket lanjutan yang marah daripada kalimat mana pun dalam urusan penagihan. Setelah itu lakukan pengembalian dana dari sisi penyedia dan pastikan nota kredit atau konfirmasi refund benar-benar sampai ke pelanggan, bukan sekadar uang yang berpindah diam-diam di dasbor yang tidak bisa mereka lihat.

Pemeriksaan yang dijalankan pada setiap pesan

Apa pun yang memicunya, setiap email melewati pemeriksaan singkat yang sama. Hanya hitungan detik, begitu ini jadi kebiasaan:

• Email itu sampai, dan masuk ke kotak masuk, bukan dibuang diam-diam.
• Tidak ada yang tampil sebagai placeholder mentah. Token yang belum tergantikan pada sapaan adalah bug paling memalukan di artikel ini, dan ia terus-menerus lolos ke produksi.
• Versi teks biasa tersedia dan terbaca dengan baik. Banyak klien email dan pembaca layar memakainya alih-alih versi HTML.
• Tautan bersifat absolut dan publik.
• Email pemasaran memuat tautan berhenti berlangganan yang berfungsi, termasuk header sekali klik dari RFC 8058, yang kini praktis wajib bagi pengirim massal menurut pedoman pengirim Google. Tanda terima transaksional tidak seharusnya memuatnya.
• Autentikasi lolos. Kalau email uji terkirim dengan buruk, cari tahu sekarang — kenapa email transaksional masuk spam membahas penyebabnya.

Kenapa kotak masuk sekali pakai cocok untuk siklus ini

Yang membuat semua ini praktis adalah kotak masuknya bersifat sekali pakai tanpa berumur terlalu pendek sampai tidak berguna. Pesan tiba secara real-time, jadi Anda melihat setiap pesan mendarat persis saat sistem mengirimnya, dan hubungan sebab-akibat tetap jelas. Alamatnya bertahan satu jam, yang dengan longgar mencakup pendaftaran, checkout, jalan memutar 3-D Secure, dan satu siklus penagihan yang dipercepat — kotak masuk sepuluh menit biasanya justru kedaluwarsa tepat saat tanda terima akan datang.

Dan tidak ada yang perlu dibereskan setelahnya. Tidak ada akun uji yang menumpuk di alamat asli Anda, tidak ada kotak surat QA bersama tempat sesi enam orang saling tumpang tindih, tidak perlu menebak apakah pesan di layar milik sesi hari ini atau sesi Kamis lalu. Percobaan berikutnya benar-benar dimulai dari nol, dan itulah inti seluruhnya. Kalau Anda ingin tahu detail apa yang terjadi pada semuanya di akhir jam itu, kami menuliskannya di apa yang terjadi setelah satu jam.

Apa yang sebenarnya tertangkap dengan cara ini

Sesi seperti ini secara konsisten memunculkan satu keluarga cacat tertentu — yaitu cacat yang hidup di antara sistem, bukan di dalamnya:

• Tanda terima yang tidak pernah terkirim karena job hilir membutuhkan field yang justru diisi oleh langkah yang tidak berhubungan. (Halo, Senin.)
• Tagihan ganda akibat satu klik kedua yang tidak sabar.
• Email selamat datang yang terkirim dua kali, atau tidak sama sekali, bagi orang yang membayar sebelum verifikasi.
• Pembayaran berhasil sementara paket diam-diam gagal aktif, sehingga pelanggan yang sudah membayar tetap berada di tingkat gratis.
• Tantangan 3-D Secure yang ditinggalkan meninggalkan setengah langganan yang terlantar.
• URL staging yang nyangkut di email dan hanya berjarak satu flag konfigurasi dari sampai ke pelanggan.
• Rangkaian penagihan yang masih mengejar orang yang sudah membayar.

Satu peringatan, disampaikan terus terang

Ini adalah teknik untuk menguji perangkat lunak yang menjadi tanggung jawab Anda, di lingkungan yang Anda kendalikan, terhadap sandbox pembayaran. Ini bukan cara memanen masa uji coba gratis, menghindari paywall, atau memproduksi akun di layanan orang lain. Itu penyalahgunaan, itulah alasan penyedia email sekali pakai berakhir diblokir, dan bukan untuk itu alat ini dibuat.

Batasannya berlaku ke arah sebaliknya juga: kotak masuk sekali pakai memang sengaja dibuat sementara, jadi jangan pernah menautkannya ke akun yang perlu Anda pertahankan. Kalau Anda tidak bisa memulihkannya tanpa kotak surat itu, gunakan alamat asli. Alias versus alamat sementara adalah bacaan yang tepat kalau Anda ragu berada di sisi mana dari garis itu.

Jadikan ritual, bukan aksi kepahlawanan

Tim yang berhasil menangkap hal-hal semacam ini bukanlah tim dengan rencana pengujian paling rumit. Mereka adalah tim yang menempuh seluruh jalur sebagai orang asing sebelum apa pun yang penting dirilis — kotak masuk baru, profil bersih, daftar, verifikasi, bayar dengan kartu uji, baca setiap pesan, batalkan, refund. Setengah jam, sepenuhnya manual, dan tetap terus menemukan hal-hal yang secara struktural tidak mungkin ditemukan suite otomatis, karena suite itu dibangun di atas asumsi yang sama dengan kodenya.

Masukkan ke kalender — dua minggu sekali, atau sebelum setiap rilis yang menyentuh pendaftaran atau penagihan. Sesi pertama hampir selalu memunculkan sesuatu yang belum disadari siapa pun, dan tiket Senin pagi berhenti menjadi hal yang menimpa Anda. Ambil email sekali pakai yang baru lalu telusuri seluruh jalurnya.