Pengujian verifikasi email adalah bagian pekerjaan yang sering dianggap selesai begitu satu tautan aktivasi berhasil dibuka. Padahal jalur itu justru yang paling jarang gagal. Yang membuat pengguna marah adalah tautan yang kedaluwarsa, surat yang tidak pernah datang, dan tombol yang diklik dua kali. Halaman ini menyusun kasus uji yang perlu ada sebelum alur verifikasi dianggap layak rilis.
Di titik mana aplikasi mengirim verifikasi
Sebelum menyusun kasus uji, daftarkan dulu semua tempat aplikasi mengirim surat verifikasi. Daftar ini biasanya lebih panjang dari dugaan orang yang pertama kali menulisnya.
- Pendaftaran akun baru, untuk memastikan alamatnya benar-benar bisa diakses.
- Penggantian alamat surat, yang sering memerlukan verifikasi pada alamat lama dan alamat baru sekaligus.
- Pengaturan ulang kata sandi, yang dikirim ke alamat terdaftar.
- Masuk dari perangkat baru, sebagai langkah keamanan tambahan.
- Perubahan data sensitif, misalnya nomor telepon atau rekening penarikan dana.
- Undangan dari akun lain, ketika pemilik akun mengundang rekan kerja.
Setiap titik itu menghasilkan surat dengan tautan atau kode yang berbeda, dan setiap titik itu perlu diperiksa sendiri.
Mengapa menguji jalur normal saja tidak cukup
Jalur normal hanya membuktikan bahwa sistem bisa berhasil ketika semuanya berjalan lancar. Ia tidak memberi tahu apa yang terjadi ketika jaringan sibuk, ketika pengguna mengklik dua kali karena mengira tautannya tidak bekerja, atau ketika tautan dibuka di peramban yang berbeda dari tempat pendaftaran dilakukan. Justru di situasi-situasi itu cacat paling mahal muncul, karena pengguna tidak punya cara lain untuk menyelesaikan pendaftarannya.
Ada alasan kedua yang lebih halus. Verifikasi bukan sekadar halaman sukses, melainkan sebuah status yang tersimpan di sistem. Karena itu pengujian harus memeriksa statusnya, bukan hanya tampilan layarnya. Pengguna yang melihat pesan berhasil tetapi statusnya tetap belum terverifikasi akan menemukan masalahnya jauh kemudian, ketika ia mencoba memakai fitur yang terkunci.
Daftar kasus yang wajib dicoba
| Kasus | Yang harus diperiksa |
|---|---|
| Tautan normal | Status berubah menjadi terverifikasi dan hanya sekali |
| Tautan kedaluwarsa | Pesan jelas dan ada cara meminta tautan baru |
| Tautan dibuka dua kali | Tidak ada perubahan ganda, tidak ada galat yang membingungkan |
| Permintaan tautan berulang | Tautan lama tidak lagi berlaku, atau keduanya berlaku dengan aman |
| Peramban berbeda | Verifikasi berhasil tanpa bergantung pada sesi pendaftaran |
| Dua akun, satu alamat | Perilaku ditentukan dan konsisten |
| Surat tidak sampai | Ada jalur bantuan dan tombol kirim ulang yang dibatasi |
| Alamat diubah saat menunggu | Status tidak berakhir di akun yang salah |
Poin terakhir sering luput. Bila pengguna mengganti alamat suratnya sementara verifikasi lama masih menunggu jawaban, surat yang datang terlambat untuk alamat lama tidak boleh mengaktifkan akun dengan alamat baru.
Cara memakai tabel ini bukan dengan menjalankan seluruh barisnya setiap kali rilis. Pilih baris yang paling dekat dengan perubahan yang sedang dikerjakan, lalu tambahkan satu baris yang paling sering gagal di sistem Anda. Yang penting, setiap baris punya hasil yang diperiksa, bukan sekadar langkah yang dijalankan; pengujian yang membuka sebuah tautan tanpa memeriksa status akunnya tidak membuktikan apa pun.
Apa yang terjadi kalau suratnya tidak pernah sampai?
Ini jalur yang paling sering diabaikan, padahal kejadiannya biasa. Surat bisa tertahan oleh penyaring, alamatnya salah ketik, atau pengirimnya sedang bermasalah. Aplikasi yang baik menangani situasi ini dengan tiga hal: memberi tahu pengguna bahwa surat mungkin perlu beberapa saat, menyediakan tombol kirim ulang dengan batas agar tidak disalahgunakan, dan menyediakan jalur bantuan bila surat tetap tidak datang.
Direkomendasikan juga agar halaman menunggu tidak menggantung tanpa penjelasan. Pengguna yang tidak tahu apa yang sedang terjadi akan menekan tombol kirim ulang berkali-kali, lalu menerima banyak surat sekaligus dan bingung mana yang harus dibuka.
Perhatikan juga nada pesannya. Pengguna yang sedang menunggu surat biasanya sudah gelisah, jadi pesan yang menyalahkan alamatnya atau menyuruhnya memeriksa folder sampah berkali-kali hanya menambah kebingungan. Sebutkan langkah yang benar-benar bisa ia lakukan, dan jelaskan bahwa pengiriman surat kadang memang memerlukan waktu.
Bisakah satu alamat dipakai untuk dua akun?
Jawabannya bergantung pada keputusan produk Anda, tetapi apa pun keputusannya harus dipilih dengan sadar dan diuji. Bila satu alamat hanya boleh memiliki satu akun, sistem perlu menolak pendaftaran kedua dengan pesan yang jelas, bukan gagal diam-diam. Bila satu alamat boleh memiliki beberapa akun, verifikasi untuk satu akun tidak boleh mengaktifkan akun yang lain.
Kasus ini sering muncul di lingkungan kerja, ketika satu alamat bersama dipakai oleh beberapa orang. Ia juga sering muncul ketika pengguna mengganti alamat suratnya lalu membuat akun baru dengan alamat lamanya.
Keputusan ini juga memengaruhi cara Anda menyimpan data. Bila satu alamat boleh memiliki beberapa akun, tabel pengguna Anda tidak bisa menjadikan alamat sebagai penanda yang unik, dan setiap pencarian berdasarkan alamat harus siap mengembalikan lebih dari satu hasil. Bila aturannya sebaliknya, tegakkan di tingkat penyimpanan, bukan hanya di dalam pemeriksaan pada formulir pendaftaran.
Mencoba alurnya dengan kotak sementara
Untuk menguji seluruh kasus di atas, Anda memerlukan alamat yang bisa diisi dan dibuang berkali-kali. Di email sementara di situs ini, Anda bisa membuat alamat baru untuk setiap kasus, menerima suratnya, dan melihat kode yang terdeteksi tanpa perlu menyiapkan kotak surat sungguhan lebih dulu.
Kotak ini hanya cocok untuk pengujian dan penerimaan pesan sementara; jangan memakainya sebagai alamat tetap atau sebagai tanda pengenal yang mewakili seseorang.
Untuk pengembang: token sekali pakai dan mesin status
Empat hal berikut layak dipastikan sebelum alur verifikasi dinyatakan selesai.
Pertama, masa berlaku token. Token verifikasi sebaiknya punya batas umur yang jelas, dan pemeriksaannya dilakukan di sisi server, bukan di sisi tampilan. Token yang masih bisa dipakai berhari-hari setelah dikirim memperbesar risiko bila suratnya diteruskan ke orang lain.
Kedua, mesin status. Tuliskan status yang mungkin dimiliki sebuah akun, misalnya belum terverifikasi, sedang menunggu penggantian alamat, dan sudah terverifikasi. Setiap status harus punya aturan tentang tautan mana yang masih boleh mengubahnya. Tanpa daftar seperti ini, alur yang rumit akan cepat membingungkan.
Ketiga, idempotensi. Pastikan tautan yang sama dibuka dua kali menghasilkan satu perubahan status saja, dan klik yang datang bersamaan tidak menimbulkan dua proses yang berlomba. Uji dengan mengirim dua permintaan hampir bersamaan, karena pengguna yang tidak sabar memang melakukan hal itu.
Keempat, jangan hanya menguji jalur berhasil. Sertakan minimal satu kasus untuk tautan kedaluwarsa, satu untuk tautan yang sudah dipakai, dan satu untuk permintaan kirim ulang. Bila alur verifikasi Anda memakai kode, bukan tautan, kasus pengujiannya diuraikan pada tulisan tentang kode OTP di pengujian otomatis.
Langkah berikutnya
Ambil daftar titik pengiriman yang Anda susun di awal, lalu beri setiap titik minimal tiga kasus: berhasil, kedaluwarsa, dan diulang. Setelah itu, periksa isi suratnya sendiri dengan daftar periksa surat transaksional, agar teks, tautan, dan variabel di dalamnya juga ikut teruji.