Cara Memilih Akun Email Uji untuk QA

Apa Itu Akun Email Uji Coba untuk QA?

Akun email uji coba, atau alamat email uji coba untuk QA, adalah alamat yang digunakan tim Anda untuk menerima dan memeriksa email yang dikirim aplikasi Anda sendiri. Gunakan kotak masuk sementara untuk pemeriksaan pendaftaran dan OTP secara manual yang tidak sensitif. Pilih kotak surat perusahaan untuk pesan yang disimpan, balasan, atau lampiran, serta API kotak pasir SMTP atau kotak masuk yang dihosting ketika pengujian otomatis harus memeriksa email tanpa kehadiran orang.

Tmailor mengelola blog ini, jadi inilah posisinya. Tmailor adalah layanan email sementara gratis yang hanya menerima pesan, tersedia di web, Android, iOS, dan bot Telegram. Layanan ini cocok untuk kasus pertama: seseorang membuka kotak masuk, memicu pendaftaran, lalu membaca apa yang masuk. Untuk kasus terakhir, API Tmailor Temp Mail yang terpisah memungkinkan pengujian otomatis membuat alamat yang hanya menerima pesan dan membaca pesannya dari kode. Pesan tersimpan sekitar 24 jam sejak kedatangan, lampiran tidak diterima, dan alamat tersebut tidak dapat mengirim atau membalas. Jika Anda baru mengenal kotak masuk sekali pakai, mulailah dengan cara kerja email sementara.

• Tidak perlu ada email yang masuk (validasi formulir, fixture, unit test): gunakan domain contoh yang dicadangkan.
• Seseorang membaca email dan tidak ada isinya yang sensitif: kotak masuk sementara adalah pilihan tercepat.
• Data sensitif, balasan, lampiran, atau bukti yang harus Anda simpan: gunakan kotak surat yang disetujui dan dikendalikan perusahaan; tambahkan tag plus hanya jika sistem email dan aplikasi Anda mendukungnya.
• Tidak ada orang yang mengawasi gunakan penangkap SMTP jika Anda mengontrol pengaturan email keluar aplikasi, atau API kotak masuk yang dihosting jika aplikasi harus mengirim melalui penyedia normalnya.

Pengujian Email Manual vs Otomatis: Pohon Keputusan

Empat pertanyaan menentukan akun email uji coba mana yang dibutuhkan sebuah pemeriksaan: apakah email harus sampai sama sekali, apakah orang atau kode yang membacanya, apakah email itu membawa data sensitif, dan apakah Anda mengontrol ke mana aplikasi mengirim email keluarnya.

1. Apakah pengujian ini perlu ada email yang masuk? Pemeriksaan format, status UI, fixture, dan unit test biasanya tidak perlu. Gunakan alamat di example.com, example.org, atau example.net. Domain-domain tersebut dicadangkan untuk dokumentasi dan contoh, jadi tidak ada yang sampai ke orang nyata. Hindari mengarang domain acak, karena bisa jadi ada yang memilikinya.
2. Apakah seseorang akan membaca pesan selama pengujian? Smoke test, UAT manual, demo, dan sesi eksplorasi melibatkan manusia. Suite regresi dan pekerjaan CI biasanya tidak.
3. Jika seseorang membacanya, apakah ada isi yang sensitif? Data pelanggan asli, kredensial, data yang diatur regulasi, atau pesan yang harus Anda simpan sebagai bukti audit tidak boleh berada di kotak masuk sementara. Gunakan kotak surat perusahaan sebagai gantinya. Jika jawabannya tidak, kotak masuk sementara sudah cukup.
4. Jika kode yang membacanya, apakah lingkungan pengujian dapat mengirim emailnya ke server SMTP uji? Jika ya, penangkap SMTP menangkap setiap pesan tanpa mengirimkannya. Jika tidak, karena aplikasi harus mengirim melalui penyedia email normalnya, gunakan kotak masuk yang dihosting yang dibaca pengujian Anda melalui API.

Tabel berikut membandingkan kelima opsi secara berdampingan.

Alamat mana yang harus diterima atau ditolak oleh kolom email?

Uji validasi formulir secara terpisah dari pengiriman pesan. Gunakan alamat yang dicadangkan seperti user@example.com untuk kasus yang tampak valid tetapi tidak pernah terkirim, sertakan alamat dengan tag plus dan satu dengan subdomain, serta tambahkan kasus tidak valid seperti bagian lokal yang hilang atau domain yang hilang. Pastikan hasil yang diharapkan selaras dengan validator yang benar-benar digunakan sistem produksi Anda.

Kapan Kotak Masuk Sementara Sudah Cukup

Kotak masuk sementara cukup ketika seseorang memeriksa satu alur dalam satu waktu dan pesannya tidak berisi apa pun yang akan Anda sesalkan jika hilang setelah sehari. Itulah penggunaan klasik email sekali pakai untuk QA: Anda membutuhkan alamat email untuk menguji formulir secara manual, bukan akun yang bertahan lama. Kasus yang umum adalah smoke test pra-rilis pada formulir pendaftaran, UAT manual pada email onboarding baru, demo penjualan pembuatan akun, atau sesi eksploratif saat Anda mencoba input aneh dan mengamati apa yang dikirim aplikasi.

Daya tariknya adalah kecepatan. Tidak ada akun yang harus diminta ke IT dan tidak ada kotak surat bersama yang harus dibersihkan. Konsekuensinya adalah kontrol: Anda hanya mendapat jendela pesan singkat, tanpa lampiran, dan kotak masuk yang dibaca orang, bukan kode.

Kapan Anda Memerlukan SMTP Catcher atau API Kotak Masuk Terkelola

Setelah tes berjalan tanpa pengawasan, kotak masuk harus dapat dibaca oleh kode. Dua kelompok alat memenuhi kebutuhan itu, dan keduanya menyelesaikan masalah yang berbeda.

SMTP catcher dan sandbox menggantikan server email keluar aplikasi Anda di lingkungan pengujian dan menyimpan setiap pesan untuk diperiksa alih-alih mengirimkannya.

• Mailpit adalah alat gratis dan open-source yang Anda jalankan sendiri. Alat ini menangkap email secara default dan menyediakan UI web serta REST API untuk pengujian integrasi.
• MailHog bekerja dengan cara yang sama tetapi lebih lama. Pengelola Mailpit menyebutnya tidak lagi dipelihara, jadi periksa statusnya sebelum mengadopsinya.
• Mailtrap Email Sandbox adalah versi hosted dari ide yang sama, dengan akses SMTP dan API. Layanan ini terpisah dari produk pengiriman produksi Mailtrap.
• Ethereal adalah layanan SMTP palsu gratis yang terutama digunakan bersama Nodemailer. Pesan ditangkap untuk pratinjau dan tidak pernah dikirimkan.

API kotak masuk yang dihosting memberi pengujian alamat nyata pada domain vendor, sehingga aplikasi Anda mengirim email melalui penyedia normalnya dan pengujian membaca hasilnya melalui API. API Temp Mail milik Tmailor sendiri bekerja dengan cara ini, dengan SDK resmi untuk Python, Node.js, dan PHP.

• Mailosaur menawarkan alamat email pengujian, API, dan pustaka klien yang bekerja dengan framework seperti Cypress, Playwright, dan Selenium. Layanan ini juga mencakup kode SMS.
• MailSlurp membuat kotak masuk sesuai permintaan melalui API dan SDK-nya. Pengujian dapat menunggu pesan, lalu mengambil kode, tautan, dan lampiran.

Fitur dan paket vendor berubah, jadi pastikan detail terkini di setiap situs resmi sebelum Anda mengikatkan suite pengujian pada salah satunya.

Kapan Kotak Surat Perusahaan dengan Tag Plus Menjadi Pilihan yang Lebih Baik

Tag plus memungkinkan satu kotak surat perusahaan menerima banyak variasi alamat. Email ke qa+signup atau qa+reset di domain perusahaan Anda akan masuk ke kotak surat qa, tempat Anda dapat memfilternya berdasarkan tag. Google Workspace mendukung ini, dan Microsoft mendokumentasikan bahwa plus addressing di Exchange Online aktif secara default kecuali admin menonaktifkannya.

Gunakan jalur ini ketika suatu alur membawa data pelanggan nyata, berjalan lebih dari sehari, membutuhkan balasan atau lampiran, atau menghasilkan bukti yang mungkin diminta auditor. Ingatlah batasannya. Tag adalah variasi dari satu kotak surat, bukan kotak masuk terpisah, sehingga pengujian paralel dapat membaca pesan satu sama lain. Beberapa formulir pendaftaran menolak tanda plus, dan beberapa aplikasi memperlakukan varian bertag sebagai akun yang sama. Kedua perilaku ini layak dijadikan kasus uji tersendiri.

Cara Menjalankan Pengujian Pendaftaran Manual dengan Kotak Masuk Sementara

Pengujian pendaftaran manual yang menggunakan email sementara untuk pengujian membutuhkan tiga hal: alamat baru, build yang sedang Anda uji, dan tempat di luar kotak masuk untuk mencatat apa yang tiba. Jalankan hanya terhadap sistem yang Anda miliki atau yang Anda berwenang untuk uji.

1. Buka kotak masuk. Buat kotak masuk sementara gratis di web, atau gunakan aplikasi Tmailor atau bot Telegram, lalu salin alamatnya. Di desktop, ekstensi browser Tmailor juga dapat mengisinya ke kolom email pada build pengujian Anda.
2. Daftarlah pada build pengujian Anda. Gunakan alamat tersebut di lingkungan staging atau QA Anda dan catat waktu Anda mengirimkan formulir.
3. Pantau email yang masuk. Periksa pesan mana yang tiba, nama pengirim dan alamat From, subjek, serta berapa lama waktu yang dibutuhkan.
4. Selesaikan langkahnya. Klik tautan atau masukkan kodenya. Pastikan status akun berubah sekali dan bahwa penggunaan ulang tautan yang sama gagal dengan pesan yang jelas.
5. Catat bukti di tempat lain. Salin tautan, kode, timestamp, dan tangkapan layar ke dalam kasus uji Anda. Pesan hanya bertahan sekitar 24 jam sejak kedatangan, jadi kotak masuk bukan catatan pengujian Anda.
6. Simpan Access Token jika Anda akan menguji ulang. Token tersebut membuka kembali alamat yang sama di kemudian hari, misalnya untuk menjalankan ulang reset kata sandi. Token ini tidak memulihkan pesan yang sudah kedaluwarsa, dan token yang hilang tidak dapat dipulihkan.

Ketika satu sesi membutuhkan beberapa persona sekaligus, seperti pengguna gratis, pengguna uji coba, dan rekan tim yang diundang, tampilan kotak masuk ganda menyimpan hingga lima alamat berdampingan dalam satu tab browser. Setiap persona mendapat alamatnya sendiri, sehingga Anda dapat melihat email mana yang milik akun mana.

Tampilan ini masih manual. Kotak masuk dibuat oleh seseorang di browser, bukan disediakan oleh kode, sehingga tidak menggantikan API kotak masuk yang dihosting untuk eksekusi paralel tanpa pengawasan.

Satu Kotak Masuk atau Satu Alamat per Pengujian?

Satu kotak masuk bersama memang cukup untuk pemeriksaan cepat, tetapi cepat pula menjadi berantakan. Begitu beberapa pengujian berjalan bersamaan, baris subjek yang mirip membuat sulit menentukan email mana milik skrip mana, dan proses debugging pun berubah menjadi tebak-tebakan.

Satu alamat per kasus uji menyelesaikan masalah itu. Log, tangkapan layar, dan email menjadi selaras, dan pesan yang hilang menunjuk ke satu skenario, bukan ke semuanya. Panduan tentang beberapa kotak masuk email sementara membahas alur kerja tersebut secara lebih rinci.

Beberapa alur membutuhkan alamat yang sama lagi beberapa hari kemudian, misalnya uji coba yang berlanjut menjadi berbayar atau pengguna yang kembali setelah berhenti berlangganan. Alamat email sementara yang dapat digunakan ulang menjaga alamat tetap tersedia melalui Access Token-nya, tetapi tidak menjaga emailnya. Simpan tautan dan kode yang Anda butuhkan saat setiap langkah berjalan, dan pindahkan langkah apa pun yang bergantung pada pesan lama ke kotak surat perusahaan. Jika penguji masuk ke akun Tmailor gratis sebelum membuat alamat persona, setiap alamat disimpan di bawah Created Emails, sehingga token yang hilang tidak lagi berarti alamat yang hilang.

Apa yang Perlu Diperiksa dalam Email Pendaftaran dan Onboarding

Mulailah dengan mendata setiap email yang dapat dikirim oleh alur tersebut, lalu tentukan apa yang harus diperiksa oleh setiap pengujian. Tim sering baru menemukan email tambahan saat muncul di tengah pengujian, setelah eksperimen pertumbuhan atau perubahan keamanan menambahkan email yang tidak tercatat siapa pun.

Email dalam Alur Pendaftaran yang Umum

• Tautan verifikasi atau kode sekali pakai
• Email selamat datang dan rangkaian panduan awal apa pun
• Masuk dengan tautan ajaib
• Reset kata sandi
• Perubahan alamat email, dikirim ke alamat lama dan alamat baru
• Peringatan keamanan perangkat baru atau lokasi baru
• Pengingat untuk pendaftaran yang tidak pernah diselesaikan

Untuk masing-masing email, catat pemicunya, waktu yang diharapkan, dan kondisi yang mengubahnya, seperti paket, wilayah, atau bahasa. Tetapkan jendela pengiriman yang diizinkan berdasarkan persyaratan produk yang terdokumentasi, bukan dengan mengasumsikan ambang batas universal; pesan verifikasi yang langsung terkirim dan rangkaian sambutan yang terjadwal membutuhkan ekspektasi yang berbeda. Setelah ekspektasi itu ada, setiap pengujian memiliki hal konkret untuk diperiksa.

Apa yang Harus Diperiksa di Setiap Email Uji

• Pengirim dan penerima: nama dan alamat pengirim, Reply-To, serta alamat To yang tepat.
• Subjek dan isi: versi HTML maupun teks biasa, dengan nama, detail paket, dan bahasa yang benar.
• Tautan: tujuannya dan apakah mengarah ke lingkungan yang tepat. Email staging yang tertaut ke produksi adalah bug nyata.
• Kode: format, panjang, teks masa berlaku, dan apakah masa berlaku yang dinyatakan sesuai dengan yang diterapkan server.
• Waktu: berapa lama pesan tiba setelah pemicu.
• Lampiran: jika suatu alur mengirim PDF atau faktur, ujilah di kotak surat perusahaan atau alat pengujian. Tmailor tidak menerima lampiran.

Satu peringatan soal rendering. Kotak masuk sementara hanya menunjukkan bagaimana satu penampil web menampilkan HTML Anda. Ini tidak memberi tahu Anda bagaimana email yang sama terlihat di Gmail, Outlook, Apple Mail, mode gelap, atau layar ponsel kecil, jadi rencanakan pemeriksaan rendering terpisah jika hal itu penting.

Alur Perubahan Email dan Pemulihan Akun

Alur pemulihan rusak dengan cara yang lebih senyap dibandingkan pendaftaran. Periksa bahwa perubahan email mengirimkan konfirmasi ke alamat baru dan pemberitahuan ke alamat lama, bahwa tautan reset yang sudah dipakai tidak dapat dipakai ulang, bahwa tautan reset lama berhenti berfungsi setelah tautan yang lebih baru dikirim, dan bahwa tautan yang dibuka di perangkat kedua membawa pengguna ke kondisi yang wajar. Alur OTP layak mendapat tinjauan risiko tersendiri; daftar periksa risiko OTP untuk QA dan UAT mencakup metrik, jendela pengiriman ulang, dan kepemilikan.

Cara Menguji Kasus Khusus OTP dan Verifikasi

Uji alur OTP dan verifikasi terhadap pengiriman yang tertunda, pengiriman ulang, kode yang kedaluwarsa dan salah, serta tautan yang dibuka di perangkat lain. Setiap kasus harus memeriksa hasil di server sekaligus pesan yang ditampilkan kepada pengguna. Jalankan pengujian ini hanya pada sistem yang Anda miliki atau yang Anda berwenang untuk uji. Pengujian OTP yang baik sengaja memutus alur:

• Kedatangan lambat: tunggu sebelum memeriksa kotak masuk dan pastikan UI menjelaskan apa yang sedang terjadi serta menawarkan cara yang jelas untuk mengirim ulang.
• Perilaku pengiriman ulang: minta kode kedua dan periksa apakah kode pertama dibatalkan atau masih diterima.
• Masa berlaku: masukkan kode setelah masa berlakunya habis dan pastikan pesan kesalahan sesuai dengan yang terjadi.
• Kode salah: pastikan batas percobaan dan teks masa tunggu masuk akal bagi orang awam.
• Tautan ajaib lintas perangkat: minta tautan di laptop, buka di ponsel, dan periksa ke mana pengguna berakhir.

Untuk gambaran lebih luas tentang kode mana yang sampai ke kotak masuk sementara dan mana yang tidak, lihat panduan ini tentang email sementara untuk kode OTP.

Jika produk Anda sengaja menolak domain email sekali pakai, uji jalur tersebut secara langsung. Pastikan pesan penolakannya jelas dan bahwa alamat asli atau yang dikendalikan perusahaan tetap berhasil menyelesaikan pendaftaran. Jangan berganti-ganti ke domain sementara lain untuk melewati pemblokiran, baik pada produk Anda sendiri maupun produk orang lain. Memastikan pemblokiran berfungsi adalah tujuannya; mengakalinya bukan. Penjelasan tentang situs web memblokir domain email sementara ini membahas alasan di balik filter tersebut.

Apa yang Berubah Saat Tes Email Berjalan Tanpa Pengawasan

Saat tidak ada orang yang mengawasi, tes memerlukan kotak masuk yang dapat dibaca melalui kode. Artinya API penangkap SMTP atau API kotak masuk yang dihosting. Kotak masuk web Tmailor bukan alat itu, tetapi API Tmailor Temp Mail adalah: tes dapat membuat alamat khusus penerimaan, menampilkan dan membaca pesan, serta mendapatkan kode sekali pakai atau tautan verifikasi yang ditemukan API. Server MCP memungkinkan agen AI seperti Claude, Cursor, atau VS Code Copilot melakukan hal yang sama untuk alur pendaftaran yang Anda miliki atau yang diizinkan untuk diuji.

Beberapa kebiasaan menjaga tes email tanpa pengawasan tetap stabil, apa pun alat yang Anda pilih:

• Beri setiap uji coba alamatnya sendiri dan ID korelasi, sehingga email yang terlambat dari uji coba sebelumnya tidak dapat memenuhi asersi yang salah.
• Gunakan penantian khusus untuk kedatangan email dengan backoff yang wajar, terpisah dari timeout keseluruhan tes, dan catat berapa lama setiap pesan tiba.
• Cocokkan pesan yang tepat berdasarkan penerima dan subjek, bukan dengan membaca "email terbaru."
• Samarkan kode dan tautan ajaib di log CI, karena log sering kali bertahan lebih lama daripada kotak masuk.

Jelaskan juga apa yang dibuktikan oleh tes yang lulus. "Aplikasi menghasilkan dan mengirimkan email," "domain uji yang dihosting menerimanya melalui infrastruktur email publik," dan "Gmail menempatkannya di kotak masuk, bukan spam" adalah tiga fakta yang berbeda. Penangkap SMTP membuktikan yang pertama, API kotak masuk yang dihosting membuktikan dua yang pertama, dan keduanya tidak membuktikan yang ketiga. Untuk penyiapan pipeline di GitHub Actions, GitLab CI, dan CircleCI, lihat panduan pengujian email di pipeline CI/CD.

Jaga Keamanan Data Uji dan Tetap Patuhi Aturan

Gunakan identitas sintetis dan konten non-sensitif di kotak masuk uji sementara, dan jalankan tes pendaftaran hanya terhadap sistem yang Anda miliki atau yang Anda berwenang untuk menilainya. Jauhkan akun QA dari analitik produksi, patuhi batas laju, dan pindahkan data yang diatur, kredensial, lampiran, serta bukti yang disimpan ke sistem yang dikendalikan perusahaan yang telah disetujui.

• Tidak boleh ada data nyata di kotak masuk sementara. Jangan pernah mengarahkan catatan pelanggan asli, kredensial, kunci API, atau data yang diatur ke alamat email sementara. Gunakan pengguna sintetis dengan nama yang jelas-jelas palsu.
• Uji hanya yang boleh Anda uji. Jalankan tes pendaftaran terhadap produk Anda sendiri atau sistem yang Anda berwenang untuk diuji, dan patuhi batas laju serta ketentuan layanan tersebut. Jangan gunakan email sementara untuk membuat akun secara massal di situs pihak ketiga. Pengujian volume dan beban sebaiknya dilakukan di lingkungan staging Anda sendiri, dengan penangkap SMTP atau API kotak masuk yang dihosting.
• Jauhkan lalu lintas QA dari angka produksi. Beri label yang jelas pada akun uji dan kecualikan akun tersebut dari analitik serta dasbor pertumbuhan. Hindari mengirim email uji dalam volume besar dari domain pengiriman produksi Anda, karena bounce dan keluhan dapat merusak reputasinya.
• Tuliskan kebijakannya. Nyatakan alur mana yang boleh menggunakan kotak masuk sementara, mana yang memerlukan kotak surat perusahaan, berapa lama data uji disimpan, dan siapa yang memiliki akses. Tinjauan keamanan dan kepatuhan berjalan lebih cepat bila batasannya sudah tertulis.

Saat tim keamanan bertanya bagaimana penyedia menangani data, perhatikan apa yang dikumpulkannya, berapa lama pesan disimpan, dan bagaimana aksesnya bekerja. Ikhtisar tentang email sementara dan privasi online ini membahas pertanyaan-pertanyaan tersebut dari sisi pengguna. Keputusan tentang alur mana yang boleh menggunakan kotak masuk sekali pakai tetap menjadi wewenang tim hukum, privasi, dan keamanan Anda sendiri.

Batasan yang Perlu Direncanakan

Kotak masuk web Tmailor cocok untuk pemeriksaan manual singkat atas email masuk yang tidak sensitif (otomatisasi adalah fungsi API Temp Mail). Sebelum memilihnya, tentukan apakah alur kerja memerlukan tindakan keluar, lampiran, bukti yang tahan lama, atau pemulihan alamat yang tahan lama. Salah satu persyaratan tersebut memerlukan kotak surat yang dikendalikan perusahaan atau alat pengujian khusus; daftar periksa di bawah ini menjelaskan alasannya.

• Tmailor hanya menerima. Layanan ini dapat memeriksa email pendaftaran, verifikasi, dan OTP yang masuk, tetapi tidak dapat memeriksa alur balasan atau apa pun yang dikirim dari alamat tersebut.
• Tmailor tidak menerima lampiran, sehingga email faktur, kontrak, atau pengiriman dokumen memerlukan kotak surat perusahaan atau alat pengujian.
• Pesan tersimpan sekitar 24 jam sejak kedatangannya. Ekspor tautan, kode, dan stempel waktu yang akan dibutuhkan untuk investigasi yang lebih panjang.
• Access Token membuka kembali alamat, bukan pesan yang sudah kedaluwarsa, dan token yang hilang tidak dapat dipulihkan.
• Kotak masuk web dibaca oleh orang. Pembacaan kotak masuk tanpa pengawasan memerlukan SMTP catcher atau API kotak masuk terkelola, seperti Tmailor Temp Mail API.
• Beberapa layanan memblokir domain email sekali pakai. Jika alur yang Anda uji sengaja melakukan ini, validasikan dengan alamat nyata atau alamat yang dikendalikan perusahaan.

Memilih Kotak Masuk Pengujian yang Tepat

Pilih kotak masuk sesuai dengan apa yang harus dibuktikan oleh pengujian. Gunakan domain contoh yang dicadangkan saat pengiriman tidak diperlukan, kotak masuk sementara untuk pemeriksaan manual yang tidak sensitif, kotak surat perusahaan untuk alur yang perlu disimpan atau bersifat sensitif, SMTP catcher saat Anda mengontrol pengaturan email keluar, dan API kotak masuk terkelola untuk pengujian end-to-end tanpa pengawasan.

Untuk kasus manual, buka kotak masuk sementara dan mulai dengan alur pendaftaran yang akan Anda rilis berikutnya. Email sementara juga memiliki banyak banyak kegunaan praktis selain QA.