Hampir setiap aplikasi meminta alamat email, dan banyak fungsi penting bergantung padanya. Pendaftaran, verifikasi, pengaturan ulang kata sandi, magic link, undangan, preferensi notifikasi, dan pemulihan akun bergantung pada pesan yang benar-benar tiba. Memeriksa kode saja tidak cukup; Anda perlu mengirim email nyata ke akun nyata dan memeriksa hasilnya.
Tim QA cepat kehabisan alamat karena banyak alur hanya dapat memakai sebuah alamat sekali. Mengandalkan Gmail pribadi penguji gagal ketika formulir menolak alamat duplikat. Panduan ini menjelaskan persiapan akun untuk menguji verifikasi, autentikasi, dan skenario banyak pengguna.
Mengapa inbox nyata lebih baik daripada alamat palsu
Alamat seperti test@test.com hanya menguji jalur ideal sampai aplikasi mengirim email. Alamat itu tidak menunjukkan apakah tautan verifikasi berfungsi, token pengaturan ulang kedaluwarsa dengan benar, atau pesan tampil baik di klien nyata. Titik-titik inilah yang sering gagal di produksi.
Dengan inbox nyata, Anda dapat membuka tautan, menguji pengaturan ulang dari awal sampai akhir, memeriksa nama pengirim dan subjek, serta membandingkan tampilan Gmail dan Outlook. Pengujian permukaan berubah menjadi pengujian nyata.
Kapan akun uji khusus berguna
- Alur pendaftaran dan onboarding yang memerlukan alamat unik dan dapat diverifikasi pada setiap eksekusi
- Pengaturan ulang kata sandi dan autentikasi magic link yang mengharuskan penerimaan serta penggunaan email
- Fitur undangan dan kolaborasi yang meniru beberapa pengguna berbeda
- Notifikasi dan ringkasan yang perlu diverifikasi keterkirimannya
- Rangkaian regresi yang memerlukan akun baru setiap sprint agar kondisi lama tidak memengaruhi hasil
- Pengujian lintas penyedia untuk memastikan kedatangan dan tampilan di Gmail, Yahoo, dan Outlook
Akun uji sekali pakai atau persisten
Sebagian pengujian bersifat sekali pakai: buat akun, jalankan alur sekali, lalu pensiunkan. Pengujian lain membutuhkan akun persisten untuk mengulang skenario bertahap dengan kondisi yang diketahui. Menentukan jenisnya mencegah kumpulan akun menjadi kacau.
| Jenis akun | Digunakan untuk | Masa pakai |
|---|---|---|
| Sekali pakai | Pendaftaran dan verifikasi satu kali | Satu eksekusi pengujian |
| Persisten | Skenario regresi dengan kondisi diketahui | Minggu hingga bulan |
| Kumpulan bersama | Pengujian eksploratif manual | Dirotasi per sprint |
| Per penguji | Pekerjaan paralel tanpa benturan | Selama dibutuhkan penguji |
Rotasikan akun setiap sprint
Kebocoran kondisi antar eksekusi menimbulkan hasil tidak stabil dan keyakinan palsu. Buat batch baru pada awal sprint dan pensiunkan batch lama agar setiap siklus dimulai bersih.
Mengintegrasikan akun uji dengan pipeline otomatis
Jika rangkaian end-to-end berjalan pada setiap deployment, rangkaian itu membutuhkan akun tanpa intervensi manusia. Sediakan kumpulan lebih dahulu, berikan kredensial sebagai konfigurasi lingkungan, lalu biarkan rangkaian memilih akun. Isi ulang secara massal ketika menipis, bukan membuat akun saat pengujian berjalan.
Tim dengan akses API dapat menghubungkan penyediaan ke alat internal dan menjadikan pembaruan kumpulan sebagai langkah terjadwal. Tujuannya agar pengujian tidak menunggu pembuatan dan tidak berebut alamat bersama.
Menyiapkan kumpulan akun uji
- 1Perkirakan jumlah akun yang dipakai satu siklus lengkap dan tambahkan cadangan
- 2Buat batch melalui MailCreator dengan pola seperti qa-sprint12-001
- 3Tetapkan email pemulihan bersama agar akun terkunci dapat dipulihkan
- 4Ekspor CSV, verifikasi status setiap baris, dan impor kredensial ke pengelola rahasia yang disetujui
- 5Tetapkan peran sekali pakai atau persisten agar eksekusi tidak berbenturan
- 6Perbarui kumpulan setiap sprint dan pensiunkan akun lama
Jauhkan data pengujian dari spreadsheet bersama
Akun uji tetap merupakan kredensial nyata. Menyimpannya di Google Sheet terbuka menimbulkan celah keamanan. Gunakan pengelola kata sandi atau penyimpanan secret CI seperti kredensial lainnya.