"Email telah tiba" bukan hasil tes yang memadai.
Sebuah pesan pendaftaran dapat sampai ke kotak masuk dengan penerima yang salah, tautan kedaluwarsa, tata letak seluler yang rusak, nama host produksi, atau baris subjek yang tidak masuk akal dalam bahasa lain. Pengujian email yang baik mengikuti seluruh alur pengguna dan meninggalkan cukup bukti untuk mendiagnosis kegagalan.
Kotak masuk sementara berguna di sini karena setiap run dapat dimulai dengan alamat bersih. Kotak masuk harus dapat dibuang; hasil tes tidak boleh begitu.
Bangun matriks kecil yang disengaja
Mulailah dengan alur yang dapat memblokir pengguna:
- verifikasi akun baru;
- reset kata sandi;
- undangan tim atau ruang kerja;
- konfirmasi perubahan email;
- tautan masuk atau kode satu kali;
- peringatan keamanan setelah tindakan sensitif.
Untuk setiap alur, uji jalur bahagia, satu kredensial yang kedaluwarsa atau digunakan kembali, dan satu kesalahan sisi penerima. Itu menangkap lebih banyak cacat nyata dibanding mengirim puluhan pesan jalur bahagia yang identik.
Gunakan satu kotak masuk per skenario
Menggunakan kembali satu alamat menciptakan ambiguitas. Pesan reset lama dapat disalahartikan sebagai yang terbaru, dan tes paralel dapat mengonsumsi tautan satu sama lain.
Hasilkan alamat unik untuk setiap kasus tes atau run tes. Catat bersama nomor build, lingkungan, lokal, dan skenario. Jika tes gagal, alamat menjadi bagian dari bukti dan dapat diperiksa sebelum retensi berakhir.
Jangan gunakan alamat pelanggan nyata di staging. Itu berisiko menghasilkan pesan yang tidak diinginkan, mencemari analitik, dan menyulitkan pembersihan otomatis.
Asersi amplop sebelum isi
Sebelum mengklik apa pun, verifikasi:
- Pesan dikirim ke alamat tepat yang dibuat untuk tes ini.
- Domain pengirim adalah yang diharapkan untuk lingkungan tersebut.
- Subjek mengidentifikasi tindakan tanpa mengungkap data sensitif.
- Hanya jumlah pesan yang dimaksud yang tiba.
- Stempel waktu lebih lambat daripada tindakan yang memicunya.
Pemeriksaan ini menangkap masalah perutean dan duplikasi sebelum parser isi menyembunyikannya.
Uji konten sebagaimana dilihat pengguna
Buka pesan pada viewport sempit dan lebar. Periksa bahwa aksi utama terlihat, fallback teks biasa dapat dipahami, dan alamat atau URL panjang tidak merusak tata letak.
Untuk alur berbasis kode, verifikasi bahwa kode terbaru berfungsi sekali dan gagal setelah digunakan. Untuk alur berbasis tautan, konfirmasi host dan lingkungan sebelum membukanya. Pesan staging yang mengarah ke produksi menjadi penghalang rilis meskipun tautan secara teknis berfungsi.
Juga periksa detail yang kurang menarik: perilaku balas-ke, kontak dukungan, kata-kata kedaluwarsa, lokal, dan nama akun atau ruang kerja yang ditampilkan dalam pesan.
Kasus negatif yang berharga
Tes negatif yang berguna meliputi:
- meminta kode kedua dan mengonfirmasi yang pertama dibatalkan;
- membuka tautan yang kedaluwarsa;
- membuka tautan yang sama dua kali;
- mengubah status akun sebelum menggunakan pesan;
- mengundang alamat yang sudah dimiliki anggota;
- memasukkan alamat yang tidak didukung atau tidak valid;
- menunda pengiriman cukup lama hingga melewati batas kedaluwarsa.
Tes ini mengungkap kondisi balapan dan pesan kesalahan yang menyesatkan yang tidak akan ditemukan oleh pemeriksaan kotak masuk sederhana.
Pisahkan kegagalan produk dari penundaan pengiriman
Ketika pesan hilang, simpan stempel waktu untuk tindakan pengguna, antrean aplikasi, serah terima penyedia, dan kedatangan kotak masuk ketika sinyal tersebut tersedia. Tangkapan layar kotak masuk kosong hanya membuktikan bahwa pesan tidak terlihat pada saat itu.
Gunakan urutan diagnostik dalam Verifikasi Email Tidak Tiba: Temukan Langkah yang Rusak sebelum mengajukan isu “email rusak” yang samar.
Apa yang harus diotomatisasi
Otomatiskan kontrak yang stabil:
- menghasilkan alamat unik;
- memicu aksi produk;
- melakukan polling dengan batas waktu dan penundaan kembali;
- mencocokkan pengirim dan subjek yang diharapkan;
- membaca pesan terbaru yang cocok;
- memvalidasi kode atau tautan terhadap produk;
- menyimpan bukti kegagalan yang berguna;
- membersihkan.
Pertahankan tinjauan visual, kualitas salinan, dan perilaku klien yang tidak biasa dalam proses manual terfokus. Otomatisasi baik untuk pengulangan, bukan selera.
Otomatisasi API Kotak Masuk Sementara yang Andal mencakup sisi API, termasuk polling dan pembersihan.
Laporan kegagalan yang berguna
Laporan yang dapat ditindaklanjuti pengembang berisi skenario, lingkungan, alamat, waktu pemicu, pengirim yang diharapkan, pesan yang diamati, waktu polling terakhir, status respons, dan tangkapan layar atau kutipan isi yang disanitasi. Jangan pernah melampirkan rahasia aktif atau tautan verifikasi yang dapat digunakan kembali ke isu publik.
Tujuannya bukan membuktikan bahwa email tidak dapat diandalkan. Tujuannya adalah mengidentifikasi kontrak mana yang gagal dan meninggalkan jalur yang dapat direproduksi untuk perbaikan.