Tujuan Pengujian

• Memastikan alur signup berjalan konsisten dari input hingga akun aktif.
• Memastikan OTP terkirim, diterima, dan divalidasi dengan aturan yang benar.
• Memastikan resend, timeout, dan rate limit bekerja serta jelas di UI.
• Memastikan sistem aman dari penyalahgunaan: brute force, spam resend, enumerasi akun.
• Memastikan pesan kesalahan, state UI, dan navigasi tidak membingungkan pengguna.

Persiapan Sebelum Testing

1) Data Uji dan Variasi Akun

• Email baru: belum pernah terdaftar.
• Email existing: sudah terdaftar dan terverifikasi.
• Email existing belum verifikasi: akun dibuat tetapi verifikasi belum selesai.
• Email yang diblok: domain disposable tertentu (untuk menguji blok domain).
• Akun dengan lock sementara: setelah percobaan OTP gagal berulang.

2) Set Konfigurasi yang Perlu Diketahui QA

• TTL OTP (berapa menit OTP berlaku).
• Batas resend (mis. minimal jeda 30–60 detik, max N kali per jam).
• Batas percobaan verifikasi (mis. 5 kali salah lalu lock).
• Aturan format OTP (panjang, angka saja atau alfanumerik).
• Apakah ada fallback channel (SMS/WhatsApp) atau email saja.
• Apakah verifikasi memakai code atau magic link (atau keduanya).

3) Observability Minimal untuk QA

Idealnya QA punya cara memverifikasi status pengiriman: log email provider, event pengiriman, atau setidaknya ID transaksi (message id) yang bisa ditanyakan ke tim backend. Tanpa ini, bug deliverability sering terlihat seperti “tidak reproducible” padahal sebenarnya konsisten di layer email.

Checklist: Signup Form (Front-end)

Validasi Input

• Email format invalid: tanpa @, domain kosong, spasi di awal/akhir, karakter aneh.
• Email dengan huruf besar-kecil: apakah sistem melakukan normalisasi (case-insensitive)?
• Email dengan tanda plus (alias) seperti name+test@domain.com: diterima atau ditolak?
• Password rule: panjang minimum, kompleksitas, blok kata umum, dan pesan error yang jelas.
• Konfirmasi password: mismatch, copy-paste, dan state tombol submit.
• Checkbox wajib (terms/privacy): tidak bisa lanjut jika belum setuju.

Perilaku UI Saat Submit

• State loading muncul dan mencegah double submit.
• Tombol submit disable selama request berjalan.
• Jika request gagal (500/timeout), ada pesan yang bisa dipahami dan opsi retry.
• Jika internet putus di tengah, UI pulih dengan benar tanpa state nyangkut.

Keamanan Dasar dari Sisi UI

• Tidak membocorkan apakah email sudah terdaftar lewat pesan yang terlalu spesifik (menghindari enumerasi).
• Jika email sudah terdaftar, copy-nya tetap aman: misalnya “Jika email ini terdaftar, kami akan mengirim instruksi…”
• CAPTCHA atau challenge (jika ada) tampil di kondisi yang tepat dan tidak merusak alur.

Checklist: Pengiriman OTP (Backend + Deliverability)

Trigger Pengiriman

• OTP dikirim tepat setelah signup sukses atau setelah user menekan “Kirim kode”?
• OTP tidak terkirim dua kali karena user refresh atau klik tombol cepat.
• Jika user menutup tab dan kembali, status pengiriman tetap konsisten.

Konten Email OTP

• Subject jelas dan mudah dicari di inbox disposable.
• Kode OTP mudah dibaca: pemisah angka, tidak ambigu (mis. 0 vs O jika alfanumerik).
• Pesan menyebutkan masa berlaku OTP dan instruksi jika bukan user yang meminta.
• Jika ada link verifikasi: link valid, domain benar, tidak terpotong oleh client.
• Tidak ada data sensitif di email selain kode/tautan yang dibutuhkan.

Deliverability dan Kecepatan

• Waktu tiba email: cepat di kondisi normal, dan tetap masuk meski ada delay.
• Jika email terlambat melebihi TTL OTP, sistem punya respons UX yang jelas.
• Jika domain disposable diblok, error handling jelas: user disarankan memakai email lain.
• Jika inbox disposable menampilkan email dengan polling interval, QA menunggu dengan pola yang sama di setiap uji.

Checklist: OTP Verification Screen (UX & State)

Input OTP

• OTP panjang sesuai aturan: tidak boleh kurang/lebih.
• Auto-advance per digit (jika UI split) bekerja; backspace juga logis.
• Paste full OTP bekerja (satu kali paste mengisi semua kotak).
• Input non-digit ditolak (jika OTP numeric).
• Pesan error muncul di tempat yang tepat, tidak “menggeser” layout terlalu agresif.

State yang Harus Dites

• OTP benar: user masuk ke state “verified” dan akun aktif sesuai harapan.
• OTP salah: counter attempt bertambah, pesan error tidak bocorkan detail berlebihan.
• OTP kadaluarsa: UI minta resend dan menjelaskan bahwa kode lama tidak berlaku.
• OTP sudah dipakai: jika user submit ulang kode yang sama, responsnya konsisten.
• Rate limited: user diberi tahu kapan bisa coba lagi, bukan sekadar “error”.

Navigasi dan Refresh

• Back ke halaman signup: apa yang terjadi? Apakah akun sudah terbentuk “pending”?
• Refresh halaman verifikasi: state tetap atau hilang? Apakah ini sesuai desain?
• Open di tab baru: apakah kode/verifikasi tetap valid dan tidak “mengunci” sesi secara aneh?

Checklist: Resend OTP

Aturan Resend

• Jeda waktu resend terlihat jelas (countdown). Tidak bisa spam klik.
• Jumlah maksimal resend per periode bekerja.
• Jika resend dilakukan, kode lama otomatis invalid (atau sesuai kebijakan) dan UI memberi petunjuk.
• Jika user menerima dua email (lama dan baru), sistem hanya menerima kode yang valid.

Edge Case Resend yang Sering Terlewat

• User menekan resend berkali-kali lalu mencoba kode yang datang paling akhir: harus sukses.
• User mencoba kode yang datang paling cepat tetapi ternyata “bukan yang terbaru”: harus ditolak dengan pesan yang ramah.
• Jika provider email delay, urutan kedatangan bisa terbalik. Sistem tetap harus memegang aturan validitas yang jelas.

Checklist: Keamanan dan Abuse Prevention

Proteksi Brute Force OTP

• Batas percobaan OTP salah dan lock sementara bekerja.
• Setelah lock, UI menampilkan pesan yang benar dan tidak membingungkan.
• Jika lock berakhir, user bisa mencoba lagi tanpa harus daftar ulang.

Proteksi Enumerasi Akun

• Pesan error saat email sudah terdaftar tidak membeberkan status akun secara gamblang.
• Endpoint terkait OTP tidak mengungkap apakah email ada/tidak lewat response berbeda yang mencolok.
• Jika ada link verifikasi, token tidak mudah ditebak, panjang memadai, dan punya expiry.

Proteksi Spam Resend

• Rate limit per IP dan per email (idealnya keduanya) berjalan.
• Jika user memakai disposable email yang sama dari banyak IP, sistem tetap punya guardrail.
• Jika ada CAPTCHA adaptif, pemicu dan reset state-nya jelas.

Checklist: Magic Link vs OTP Kode (Jika Keduanya Ada)

Beberapa produk menyediakan dua jalur: memasukkan kode OTP atau klik tautan verifikasi. Jika begitu, QA perlu memastikan keduanya konsisten.

• Klik link mengaktifkan akun dan tidak meminta OTP lagi (kecuali memang desainnya begitu).
• Jika link sudah dipakai, klik ulang menghasilkan pesan “sudah diverifikasi” atau diarahkan dengan aman.
• Jika OTP digunakan lebih dulu, link lama seharusnya tidak membuka celah verifikasi ulang yang membingungkan.
• Link aman dari open redirect dan domain benar.
• Jika user membuka link di perangkat berbeda, pengalaman login/verify tetap masuk akal.

Checklist: Error Handling yang Wajib Ada

• Email tidak masuk: UI memberi opsi resend, cek folder, dan ganti email.
• Server error saat verifikasi: UI tidak menghapus input OTP tanpa alasan.
• Timeout jaringan: user bisa retry tanpa membuat OTP baru tanpa sadar.
• Format OTP salah: pesan spesifik, mis. “kode harus 6 digit”.
• OTP kadaluarsa: jelaskan bahwa user perlu minta kode baru.
• Domain disposable diblok: sampaikan dengan bahasa netral, bukan menyalahkan user.

Checklist: Cross-Device dan Cross-Browser

• Mobile Safari / Chrome / Firefox: input OTP, paste, keyboard numeric, dan auto-focus.
• Desktop: copy-paste OTP dari inbox disposable, tidak ada karakter tersembunyi.
• Dark mode / light mode: keterbacaan kode dan error state.
• Mode incognito: cookie/session behavior tidak merusak flow.
• Refresh dan back-forward cache: state halaman OTP tetap konsisten.

Checklist: Logging dan Diagnostik untuk Tim Dev

QA sering butuh bukti yang rapi saat melaporkan bug. Berikut hal yang sebaiknya dicatat agar dev cepat memahami masalahnya.

• Timestamp: kapan request signup dibuat, kapan OTP diminta, kapan email diterima.
• Alamat email disposable yang dipakai dan domain-nya.
• Apakah terjadi resend dan berapa kali.
• Response error (status code, message) tanpa membocorkan info sensitif.
• Jika ada: message id dari provider email atau event id pengiriman.
• Browser/device, jaringan (wifi/seluler), dan kondisi latency bila terlihat.

Skenario Uji End-to-End yang Direkomendasikan

Skenario A: Happy Path (Sekali Kirim, Sekali Verifikasi)

1. Buat akun baru dengan disposable email.
2. Pastikan UI pindah ke layar verifikasi.
3. Pastikan email OTP masuk dan kodenya terbaca.
4. Masukkan OTP dan pastikan akun menjadi aktif.
5. Login ulang untuk memastikan status benar-benar “verified”.

Skenario B: OTP Salah Lalu Benar

1. Masukkan OTP yang salah satu kali.
2. Pastikan error muncul dan attempt bertambah.
3. Masukkan OTP yang benar.
4. Pastikan sukses tanpa state error tertinggal.

Skenario C: Kadaluarsa + Resend

1. Minta OTP lalu tunggu sampai kadaluarsa.
2. Masukkan OTP lama dan pastikan ditolak sebagai expired.
3. Tekan resend, tunggu OTP baru, dan pastikan OTP baru berhasil.
4. Pastikan OTP lama tetap tidak valid.

Skenario D: Resend Berulang + Urutan Email Terbalik

1. Tekan resend dua atau tiga kali sesuai batas.
2. Jika email datang tidak berurutan, coba submit kode yang bukan terakhir.
3. Pastikan hanya kode yang valid diterima dan messaging-nya ramah.

Skenario E: Rate Limit dan Lock

1. Masukkan OTP salah berkali-kali sampai lock.
2. Pastikan UI menampilkan cooldown/lock dengan jelas.
3. Setelah lock habis, pastikan user bisa meminta OTP baru dan verifikasi.

Troubleshooting Cepat Saat Email OTP Tidak Masuk

• Cek blok domain: beberapa layanan menolak domain disposable yang populer.
• Delay provider: tunggu beberapa saat dan gunakan polling manual jika inbox tidak auto-refresh.
• Resend dengan jeda: lakukan sesuai countdown; jangan spam klik karena bisa memicu rate limit.
• Uji domain lain: jika tersedia, gunakan alamat disposable dengan domain berbeda.
• Bandingkan environment: staging vs production sering beda konfigurasi email provider.
• Ambil bukti: timestamp dan status request membantu dev melacak event pengiriman.

Penutup: Disposable Email Itu Alat, Checklist Itu Kuncinya

Testing signup + OTP dengan disposable email adalah cara cepat untuk mengulang skenario tanpa mengotori email utama. Namun kualitas QA tidak ditentukan oleh “berhasil menerima OTP sekali”, melainkan oleh konsistensi Anda menguji state sulit: resend, delay, kadaluarsa, rate limit, dan error handling yang sering terjadi di dunia nyata.

Gunakan checklist ini sebagai template. Setiap kali ada perubahan aturan OTP, UI verifikasi, atau provider email, jalankan ulang skenario end-to-end agar regression tidak lolos ke produksi.