Checklist email transaksional adalah daftar periksa yang mencegah kesalahan paling memalukan: surat yang tidak pernah dikirim, tautan yang tidak bisa dibuka, dan nama pengguna yang muncul sebagai penanda kosong di dalam surat. Surat-surat ini berbeda dari surat promosi karena penerimanya mengharapkannya, dan kegagalannya langsung menghambat orang menyelesaikan sesuatu. Halaman ini menyusun pemeriksaan yang layak dijalankan sebelum setiap rilis.
Apa yang termasuk surat transaksional
Surat transaksional adalah surat yang dikirim sebagai akibat langsung dari tindakan seseorang atau keadaan akunnya. Ia bukan pengumuman, dan penerimanya tidak memilih untuk berlangganan.
- Konfirmasi pendaftaran dan verifikasi alamat.
- Pengaturan ulang kata sandi dan pemberitahuan perubahan kata sandi.
- Pemberitahuan masuk dari perangkat baru.
- Konfirmasi pesanan, pengiriman, dan pembatalan.
- Faktur, tanda terima pembayaran, dan pemberitahuan kegagalan pembayaran.
- Peringatan masa berlaku langganan dan pemberitahuan batas pemakaian.
- Pemberitahuan perubahan syarat layanan yang berdampak pada akun.
Surat promosi punya aturan dan daftar periksa sendiri, terutama soal cara berhenti berlangganan. Karena sifatnya berbeda, jangan mencampur kedua jenis ini di dalam satu daftar pemeriksaan.
Batas antara keduanya juga tidak selalu tajam. Pemberitahuan fitur baru yang diselipkan ke dalam surat tanda terima membuat surat transaksional berubah sifat, dan aturan yang berlaku untuknya ikut berubah. Bila Anda memutuskan untuk menggabungkannya, keputusan itu sebaiknya diambil secara sadar, bukan karena templatnya sudah tersedia begitu saja.
Daftar periksa sebelum rilis
| Pemeriksaan | Yang dicari |
|---|---|
| Pemicu lengkap | Setiap tindakan yang seharusnya mengirim surat memang mengirimnya |
| Penerima benar | Surat pergi ke alamat yang tepat, bukan ke alamat lama atau alamat uji |
| Variabel terisi | Nama, nomor pesanan, dan jumlah uang muncul dengan nilai sungguhan |
| Tautan berfungsi | Setiap tautan bisa dibuka dan menuju halaman yang benar |
| Masa berlaku | Tautan dan kode punya batas waktu, dan pesan kedaluwarsanya jelas |
| Tampilan | Surat terbaca di layar kecil maupun besar |
| Bahasa | Teks memakai bahasa yang sesuai dengan pengguna |
| Waktu | Tanggal dan jam ditampilkan dengan format yang dipahami penerima |
| Kirim ulang | Permintaan ulang dibatasi dan tidak menumpuk surat |
| Jejak | Ada catatan bahwa surat terkirim, tanpa menyimpan isi sensitif |
Baris terakhir sering menimbulkan perdebatan. Tim ingin bisa menelusuri kegagalan, tetapi menyalin isi surat ke dalam catatan aplikasi berarti menyimpan tautan masuk dan kode verifikasi di tempat yang mungkin lebih longgar pengamanannya. Simpan penanda bahwa pengiriman berhasil, dan simpan isi lengkapnya hanya bila benar-benar diperlukan, untuk waktu yang singkat.
Pemicu yang sering terlupakan
Surat yang paling sering hilang bukanlah surat pendaftaran, melainkan surat yang dipicu oleh keadaan. Beberapa di antaranya mudah terlewat karena tidak ada tombol yang ditekan pengguna.
- Pemberitahuan pembayaran yang gagal, yang biasanya dipicu oleh sistem penagihan otomatis.
- Pengingat masa berlaku yang dijalankan oleh pekerjaan terjadwal.
- Pemberitahuan perubahan alamat surat, yang seharusnya dikirim ke alamat lama sebagai peringatan.
- Pemberitahuan ketika sebuah akun ditutup atau dinonaktifkan.
- Pemberitahuan ketika pemakaian mendekati batas paket.
Uji setiap pemicu dengan memicunya secara langsung, jangan menunggu jadwalnya tiba. Untuk pemicu yang bergantung pada waktu, sediakan cara menjalankannya lebih awal di lingkungan pengujian.
Cara menemukan pemicu yang belum terdaftar adalah dengan membaca kembali bagian kode yang memicu pengiriman surat, bukan dengan membaca dokumentasi fiturnya. Dokumentasi fitur menunjukkan apa yang bisa dilakukan pengguna, sedangkan titik pengiriman menunjukkan apa yang benar-benar dikirim oleh aplikasi.
Apakah isi surat juga perlu diuji, bukan hanya pengirimannya?
Ya, dan justru di situlah kesalahan yang paling sering lolos. Bahwa sebuah surat terkirim bukan berarti isinya benar. Variabel yang tidak terisi, tautan yang menunjuk ke lingkungan yang salah, dan penerima yang keliru adalah cacat yang tidak terlihat oleh pemeriksaan sepintas.
Ujilah isinya dengan cara yang sama seperti Anda menguji halaman web: periksa teks yang seharusnya ada, pastikan tidak ada penanda pengganti yang tertinggal, dan pastikan tautannya benar-benar bisa dibuka. Untuk surat yang memuat kode, cara mengambil dan memeriksanya diuraikan pada tulisan tentang kode OTP di pengujian otomatis.
Bolehkah surat yang sama dikirim dua kali?
Untuk sebagian surat, mengirim ulang adalah hal biasa dan tidak berbahaya: pengingat, pemberitahuan, dan ringkasan. Untuk sebagian lain, pengiriman ganda bisa merugikan: faktur yang tercatat dua kali, atau pemberitahuan pembayaran yang membuat pengguna mengira ia ditagih berulang.
Karena pengiriman surat bisa mengulang dengan sendirinya, aplikasi Anda harus menentukan mana surat yang boleh muncul lebih dari sekali. Bila sebuah surat tidak boleh ganda, pengulangan harus dikenali, misalnya dengan mencatat bahwa surat untuk peristiwa itu sudah pernah dibuat.
Satu hal yang sering terlewat adalah pengulangan yang datang dari proses berbeda. Sebuah peristiwa bisa tercatat dua kali karena pekerjaan terjadwal dan tindakan pengguna berjalan hampir bersamaan, dan penanda peristiwa adalah cara paling sederhana untuk menutup celah itu.
Mencobanya dengan kotak sementara situs ini
Untuk memeriksa seluruh daftar di atas, Anda memerlukan tujuan yang bisa dibuat dan dibuang berulang kali. Di email sementara di situs ini, Anda bisa membuat alamat baru untuk setiap pemeriksaan, memicu suratnya, lalu membaca isi dan kode yang terdeteksi tanpa menyiapkan kotak surat sungguhan.
Batasan yang perlu dipegang: alamat ini hanya untuk pengujian dan penerimaan pesan sementara, bukan untuk korespondensi resmi, dan tidak boleh dipakai untuk mengirimkan data pribadi orang lain.
Untuk pengembang: idempotensi, kegagalan kirim, dan log
Empat hal berikut menentukan apakah sistem surat Anda tahan terhadap keadaan yang tidak ideal.
Idempotensi. Tentukan satu penanda yang unik untuk setiap peristiwa yang memicu surat, lalu catat penanda itu. Bila peristiwa yang sama diproses dua kali, suratnya tidak dibuat dua kali. Cara ini menyelesaikan sebagian besar masalah pengiriman ganda tanpa perlu menebak-nebak.
Kegagalan kirim. Pengiriman bisa gagal sementara, dan kegagalan itu sebaiknya tidak membatalkan seluruh proses bisnis yang sedang berjalan. Antrikan suratnya, catat kegagalannya, dan ulangi pada waktu berikutnya dengan batas jumlah percobaan. Setelah batas itu tercapai, beri tanda agar ada yang memeriksanya.
Jalur masuk yang tidak mengganggu. Bila pendaftaran mensyaratkan verifikasi, putuskan apakah pengguna boleh memakai sebagian fitur sebelum verifikasinya selesai. Keputusan ini menentukan apa yang harus diuji ketika suratnya terlambat, dan itulah salah satu kasus pada pengujian verifikasi email.
Log. Catat penerima, jenis surat, waktu pengiriman, dan hasilnya, tetapi jangan mencatat tautan masuk atau kode verifikasi di dalam catatan biasa. Untuk pemeriksaan di dalam rantai integrasi, kebiasaan menyimpan surat mentah dan membatasinya diuraikan pada menangkap email pengujian di CI, dan prinsip yang sama berlaku untuk data uji lain yang dipakai oleh sistem Anda.
Langkah berikutnya
Ambil daftar periksa di atas, lalu jalankan sekali untuk setiap jenis surat yang Anda kirim. Catat mana yang belum punya pengujian otomatis, dan mulailah dari surat yang paling sering dipicu. Bila Anda perlu tujuan uji yang cepat dibuat, buka email sementara dan buat alamat pertama Anda.