QA için Test E-posta Hesabı Nasıl Seçilir

QA için Test E-posta Hesabı Nedir?

Test e-posta hesabı ya da QA için test e-posta adresi, ekibinizin kendi uygulamanızın gönderdiği e-postaları almak ve incelemek için kullandığı adrestir. Manuel ve hassas olmayan kayıt ile OTP kontrolleri için geçici bir gelen kutusu kullanın. Saklanan mesajlar, yanıtlar veya ekler için şirket posta kutusunu, otomatik testlerin e-postaları bir kişi olmadan incelemesi gerektiğinde ise SMTP sandbox veya barındırılan gelen kutusu API'sini seçin.

Bu blogu Tmailor yönetiyor, dolayısıyla burada tam da bu konuya değiniyoruz. Tmailor; web, Android, iOS ve bir Telegram botu üzerinden sunulan, ücretsiz ve yalnızca alıcı olarak çalışan bir geçici posta hizmetidir. İlk duruma uygundur: bir kişi gelen kutusunu açar, bir kayıt başlatır ve geleni okur. Son durum içinse ayrı Tmailor Temp Mail API, otomatik testlerin yalnızca alıcı adresler oluşturmasına ve mesajlarını koddan okumasına olanak tanır. Mesajlar varıştan itibaren yaklaşık 24 saat kalır, ekler alınmaz ve adres gönderemez veya yanıtlayamaz. Tek kullanımlık gelen kutularında yeniseniz, geçici postaların nasıl çalıştığıyla ile başlayın.

• E-posta gelmesine gerek yok (form doğrulama, armatürler, birim testleri): ayrılmış örnek alan adı kullanın.
• Bir kişi e-postayı okur ve içindeki hiçbir şey hassas değildir: geçici gelen kutusu en hızlı seçenektir.
• Saklamanız gereken hassas veriler, yanıtlar, ekler veya kanıtlar: onaylı, şirket kontrolündeki bir posta kutusu kullanın; plus etiketlerini yalnızca posta sisteminiz ve uygulamanız destekliyorsa ekleyin.
• İzleyen kişi yok: uygulamanın giden posta ayarlarını kontrol ediyorsanız SMTP yakalayıcısı, uygulama normal sağlayıcısı üzerinden göndermek zorundaysa barındırılan gelen kutusu API'si kullanın.

Manuel ve Otomatik E-posta Testi: Bir Karar Ağacı

Bir testin hangi test e-posta hesabına ihtiyaç duyduğunu dört soru belirler: bir e-postanın ulaşması gerekip gerekmediği, onu bir kişinin mi yoksa kodun mu okuduğu, hassas veri taşıyıp taşımadığı ve uygulamanın giden postasını nereye göndereceğini sizin kontrol edip etmediğiniz.

1. Testin gelmesi için bir e-postaya gerek var mı? Biçim kontrolleri, arayüz durumları, armatürler ve birim testleri genellikle gerektirmez. example.com, example.org veya example.net adreslerini kullanın. Bu alan adları dokümantasyon ve örnekler için ayrılmıştır, yani gerçek bir kişiye hiçbir şey ulaşmaz. Rastgele alan adları uydurmaktan kaçının, çünkü birileri bunlara sahip olabilir.
2. Test sırasında mesajı bir kişi mi okuyacak? Duman testleri, manuel UAT, demolar ve keşif oturumlarında döngüde bir insan vardır. Regresyon paketleri ve CI işlerinde genellikle yoktur.
3. Bir kişi okuyacaksa, içindeki herhangi bir şey hassas mı? Gerçek müşteri kayıtları, kimlik bilgileri, düzenlemeye tabi veriler veya denetim kanıtı olarak saklamanız gereken mesajlar geçici bir gelen kutusuna girmemelidir. Bunun yerine şirket posta kutusu kullanın. Cevap hayırsa, geçici gelen kutusu yeterlidir.
4. Kod okuyacaksa, test ortamı postasını bir test SMTP sunucusuna gönderebiliyor mu? Evetse, bir SMTP yakalayıcısı her mesajı teslim etmeden yakalar. Hayırsa, yani uygulama normal e-posta sağlayıcısı üzerinden göndermek zorundaysa, testlerinizin bir API üzerinden okuduğu barındırılan bir gelen kutusu kullanın.

Tablo, beş seçeneği yan yana karşılaştırıyor.

Bir e-posta alanı hangi adresleri kabul etmeli veya reddetmeli?

Form doğrulamasını mesaj teslimatından ayrı olarak test edin. Geçerli görünen ama hiç teslim edilmeyen bir durum için user@example.com gibi ayrılmış bir adres kullanın; artı etiketli bir adres ve alt alan adı içeren bir adres ekleyin; ayrıca yerel kısmı eksik veya alan adı eksik gibi hatalı biçimli durumlar ekleyin. Beklenen sonuçları, üretim sisteminizin gerçekten kullandığı doğrulayıcıyla uyumlu tutun.

Geçici gelen kutusu ne zaman yeterlidir

Geçici gelen kutusu, bir kişi aynı anda tek bir akışı kontrol ederken ve mesaj bir gün sonra kaybolması sorun olmayacak içerikten oluşuyorsa yeterlidir. Bu, tek kullanımlık e-postanın QA'deki klasik kullanımıdır: bir formu elle test etmek için bir e-posta adresine ihtiyacınız vardır, uzun ömürlü bir hesaba değil. Tipik durumlar arasında kayıt formunun sürüm öncesi duman testi, yeni bir karşılama e-postası üzerinde manuel UAT geçişi, hesap oluşturmanın satış demosu veya tuhaf girdiler deneyip uygulamanın ne gönderdiğini izlediğiniz keşif oturumu yer alır.

Cazip yanı hızıdır. BT'den talep edilecek bir hesap yoktur ve temizlenecek ortak bir posta kutusu yoktur. Karşılığında kontrol kaybı vardır: kısa bir mesaj penceresi, ek yok ve kodu değil bir kişinin okuduğu bir gelen kutusu elde edersiniz.

SMTP yakalayıcısına veya barındırılan gelen kutusu API'sine ne zaman ihtiyacınız olur

Testler gözetimsiz çalışmaya başladığında gelen kutusunun kod tarafından okunabilir olması gerekir. Bu ihtiyacı karşılayan iki araç ailesi vardır ve bunlar farklı sorunları çözer.

SMTP yakalayıcıları ve sandbox'lar uygulamanızın giden posta sunucusunu test ortamında değiştirir ve her mesajı teslim etmek yerine incelemek üzere saklar.

• Mailpit, kendiniz çalıştırdığınız ücretsiz ve açık kaynaklı bir araçtır. Varsayılan olarak postayı yakalar ve entegrasyon testleri için bir web arayüzü ile REST API sunar.
• MailHog da aynı şekilde çalışır ama daha eskidir. Mailpit'in bakımcıları onun artık bakım görmediğini belirtiyor, bu yüzden benimsemeden önce durumunu kontrol edin.
• Mailtrap Email Sandbox, aynı fikrin SMTP ve API erişimi sunan barındırılan bir sürümüdür. Mailtrap'ın üretim gönderim ürününden ayrıdır.
• Ethereal, ağırlıklı olarak Nodemailer ile kullanılan ücretsiz bir sahte SMTP hizmetidir. Mesajlar önizleme için yakalanır ve hiçbir zaman teslim edilmez.

Barındırılan gelen kutusu API'leri, testlere satıcının alan adları üzerinde gerçek adresler verir; böylece uygulamanız postayı normal sağlayıcısı üzerinden gönderir ve test sonucu bir API üzerinden okur. Tmailor'un kendi Temp Mail API'si bu şekilde çalışır ve Python, Node.js ve PHP için resmi SDK'lar sunar.

• Mailosaur, Cypress, Playwright ve Selenium gibi çerçevelerle çalışan test e-posta adresleri, bir API ve istemci kütüphaneleri sunar. Ayrıca SMS kodlarını da kapsar.
• MailSlurp, API ve SDK'ları aracılığıyla talep üzerine gelen kutuları oluşturur. Testler bir mesajı bekleyebilir, ardından kodları, bağlantıları ve ekleri çıkarabilir.

Satıcı özellikleri ve planları değişebilir; bu yüzden bir test paketini birine bağlamadan önce her resmi sitedeki güncel ayrıntıları doğrulayın.

Şirket Posta Kutusu Artı Etiketlerle Ne Zaman Daha İyi Bir Seçimdir

Artı etiketler, tek bir şirket posta kutusunun birçok adres varyasyonunu kabul etmesini sağlar. Şirket alan adınızdaki qa+signup veya qa+reset adresine gelen postalar qa posta kutusuna düşer ve burada etikete göre filtreleyebilirsiniz. Google Workspace bunu destekler; Microsoft ise Exchange Online'da artı adreslemenin, bir yönetici kapatmadığı sürece varsayılan olarak açık olduğunu belgeler.

Bir akış gerçek müşteri verisi taşıdığında, bir günden uzun sürdüğünde, yanıt veya ek gerektirdiğinde ya da bir denetçinin isteyebileceği kanıt ürettiğinde bu yolu kullanın. Sınırları aklınızda tutun. Etiketler ayrı gelen kutuları değil, tek bir posta kutusunun varyasyonlarıdır; bu yüzden paralel testler birbirinin mesajlarını okuyabilir. Bazı kayıt formları artı işaretini reddeder, bazı uygulamalar ise etiketli varyantları aynı hesap olarak görür. Her iki davranış da kendi başına bir test senaryosunu hak eder.

Geçici Gelen Kutusuyla Manuel Kayıt Testi Nasıl Yapılır

Test için geçici e-posta kullanan manuel bir kayıt testi üç şeye ihtiyaç duyar: yeni bir adres, test ettiğiniz derleme ve gelen kutunun dışında gelenleri kaydedeceğiniz bir yer. Yalnızca sahibi olduğunuz veya test etmeye yetkili olduğunuz sistemlere karşı çalıştırın.

1. Bir gelen kutusu açın. Web'de ücretsiz geçici bir gelen kutusu oluşturun, Tmailor uygulamasını veya Telegram botunu kullanarak adresi kopyalayın. Masaüstünde, Tmailor tarayıcı uzantısı bunu test derlemenizin e-posta alanına da doldurabilir.
2. Test derlemenizde kaydolun. Adresi staging veya QA ortamınızda kullanın ve formu gönderdiğiniz saati not edin.
3. E-postayı bekleyin. Hangi mesajın geldiğini, gönderen adını ve From adresini, konuyu ve ne kadar sürdüğünü kontrol edin.
4. Adımı tamamlayın. Bağlantıya tıklayın veya kodu girin. Hesabın durumunun yalnızca bir kez değiştiğini ve aynı bağlantının tekrar kullanılmasının açık bir mesajla başarısız olduğunu doğrulayın.
5. Kanıtları başka bir yerde kaydedin. Bağlantıyı, kodu, zaman damgalarını ve bir ekran görüntüsünü test senaryonuza kopyalayın. Mesajlar varıştan itibaren yaklaşık 24 saat kalır; bu yüzden gelen kutusu test kaydınız değildir.
6. Yeniden test edecekseniz access token'ı kaydedin. Token, aynı adresi daha sonra yeniden açar; örneğin şifre sıfırlamayı tekrar çalıştırmak için. Süresi dolmuş mesajları geri getirmez ve kaybolan bir token kurtarılamaz.

Bir oturumda aynı anda birkaç persona gerektiğinde, örneğin ücretsiz kullanıcı, deneme kullanıcısı ve davet edilmiş bir ekip arkadaşı, çoklu gelen kutusu görünümü tek bir tarayıcı sekmesinde beş adede kadar adresi yan yana tutar. Her persona kendi adresine sahip olur, böylece hangi e-postanın hangi hesaba ait olduğunu görebilirsiniz.

Bu görünüm hâlâ manueldir. Gelen kutuları kod tarafından sağlanmaz, bir kişi tarafından tarayıcıda oluşturulur; bu yüzden paralel denetimsiz çalışmalar için barındırılan gelen kutusu API'sinin yerini almaz.

Her Test İçin Tek Gelen Kutusu mu, Tek Adres mi?

Tek bir ortak gelen kutusu hızlı bir ön kontrol için yeterlidir, ancak hızla karman çorman olur. Birkaç test aynı anda çalışmaya başladığında benzer konu satırları hangi e-postanın hangi betiğe ait olduğunu ayırt etmeyi zorlaştırır ve hata ayıklama tahmin oyununa dönüşür.

Her test senaryosu için ayrı bir adres bunu çözer. Günlükler, ekran görüntüleri ve e-postalar birbirini tutar ve eksik bir mesaj hepsine değil, tek bir senaryoya işaret eder. Birden fazla geçici posta gelen kutusu çalıştırma rehberi bu iş akışını daha ayrıntılı ele alır.

Bazı yolculuklar aynı adresi günler sonra yeniden gerektirir; örneğin ücretli plana geçen bir deneme ya da aboneliğini bıraktıktan sonra geri dönen bir kullanıcı gibi. Yeniden kullanılabilir geçici posta adresi, adresi Access Token üzerinden erişilebilir tutar, ancak posta ile erişilebilir olmaz. Her adım ilerlerken ihtiyacınız olan bağlantıları ve kodları depolayın ve eski mesajlara bağlı olan adımları şirket posta kutusuna taşıyın. Bir test kullanıcısı kişilik adresleri oluşturmadan önce ücretsiz bir Tmailor hesabına hesabına giriş yaparsa, her biri Oluşturulan E-postalar altında kaydedilir; böylece kaybedilen token artık kaybedilen adres anlamına gelmez.

Kayıt ve İlk Kullanım E-postalarında Neler Kontrol Edilmeli?

Önce yolculuğun gönderebileceği her e-postanın bir listesini çıkarın, ardından her testin neyi doğrulaması gerektiğine karar verin. Ekipler genellikle ek e-postaları ancak test sırasında, bir büyüme deneyi ya da kimsenin not etmediği bir güvenlik değişikliği eklendikten sonra ortaya çıktıklarında fark eder.

Tipik Bir Kayıt Yolculuğundaki E-postalar

• Doğrulama bağlantısı veya tek kullanımlık kod
• Hoş geldin e-postası ve varsa hızlı başlangıç dizisi
• Magic-link ile giriş
• Şifre sıfırlama
• E-posta adresi değişikliği, hem eski hem de yeni adrese gönderilir
• Yeni cihaz veya yeni konum güvenlik uyarısı
• Hiç tamamlanmamış kayıtlar için hatırlatıcılar

Her biri için tetikleyiciyi, beklenen zamanlamayı ve plan, bölge veya dil gibi bunu değiştiren koşulları yazın. İzin verilen teslimat penceresini evrensel bir eşik varsayarak değil, ürününüzün belgelenmiş gereksinimine göre belirleyin; anında gönderilen bir doğrulama mesajı ile planlanmış bir karşılama dizisi farklı beklentiler gerektirir. Bu beklentiler netleştiğinde, her testin karşılaştırabileceği somut bir ölçüt olur.

Her Test E-postasında Neyi Doğrulamalı

• Gönderen ve alıcı: Gönderen adı ve adresi, Reply-To ve tam olarak To adresi.
• Konu ve gövde: hem HTML hem de düz metin sürümleri; doğru isimler, plan ayrıntıları ve dille birlikte.
• Bağlantılar: hedef ve doğru ortama işaret edip etmediği. Prodüksiyona bağlantı veren bir test ortamı e-postası gerçek bir hatadır.
• Kodlar: biçim, uzunluk, son kullanma metni ve belirtilen son kullanma süresinin sunucunun uyguladığıyla eşleşip eşleşmediği.
• Zamanlama: mesajın tetikleyiciden sonra ulaşmasının ne kadar sürdüğü.
• Ekler: bir akış PDF veya fatura gönderiyorsa bunu bir şirket posta kutusunda veya bir test aracında test edin. Tmailor ekleri almaz.

Görüntüleme konusunda bir uyarı. Geçici gelen kutusu, bir web görüntüleyicisinin HTML'nizi nasıl gösterdiğini gösterir. Aynı e-postanın Gmail, Outlook, Apple Mail, koyu mod veya küçük bir telefon ekranında nasıl göründüğünü söylemez; bunlar önemliyse ayrı görüntüleme kontrolleri planlayın.

E-posta Değişikliği ve Hesap Kurtarma Akışları

Kurtarma akışları, kayıt akışlarından daha sessiz biçimlerde bozulur. Bir e-posta değişikliğinin yeni adrese onay, eski adrese bildirim gönderdiğini; kullanılmış bir sıfırlama bağlantısının yeniden kullanılamadığını; daha yeni bir bağlantı gönderildikten sonra eski sıfırlama bağlantısının çalışmayı durdurduğunu ve ikinci bir cihazda açılan bağlantının kullanıcıyı makul bir duruma getirdiğini kontrol edin. OTP akışları ayrı bir risk incelemesini hak eder; QA ve UAT için OTP risk kontrol listesi metrikleri, yeniden gönderme aralıklarını ve sahipliği kapsar.

OTP ve Doğrulama Uç Durumları Nasıl Test Edilir

OTP ve doğrulama akışlarını gecikmeli teslimat, yeniden gönderme, süresi dolmuş ve yanlış kodlar ile başka bir cihazda açılan bağlantılara karşı test edin. Her durum hem sunucu sonucunu hem de kullanıcıya gösterilen mesajı kontrol etmelidir. Bu testleri yalnızca sahip olduğunuz veya test etmeye yetkili olduğunuz sistemlerde yapın. İyi OTP testleri akışı kasıtlı olarak bozar:

• Yavaş ulaşma: gelen kutusunu kontrol etmeden önce bekleyin ve arayüzün neler olduğunu açıkladığını ve yeniden gönderme için net bir yol sunduğunu doğrulayın.
• Yeniden gönderme davranışı: ikinci bir kod isteyin ve birincinin geçersiz kılınıp kılınmadığını yoksa hâlâ kabul edilip edilmediğini kontrol edin.
• Süre dolumu: belirtilen ömrü geçtikten sonra bir kod girin ve hata mesajının gerçekleşenle eşleştiğini doğrulayın.
• Yanlış kod: deneme sınırının ve bekleme süresi metninin bir kişi için anlamlı olduğunu doğrulayın.
• Cihazlar arası sihirli bağlantılar: bir dizüstü bilgisayarda bağlantı isteyin, telefonda açın ve kullanıcının nereye vardığını kontrol edin.

Hangi kodların geçici gelen kutusuna ulaşıp hangilerinin ulaşmadığına dair daha geniş bir bakış için şu rehbere bakın: OTP kodları için geçici posta rehberine bakınız.

Ürününüz tek kullanımlık e-posta alan adlarını bilerek reddediyorsa, bu yolu doğrudan test edin. Reddetme mesajının net olduğunu ve gerçek ya da şirket kontrolündeki bir adresin yine de kayıt sürecini tamamladığını doğrulayın. Kendi ürününüzde veya başkasının ürününde engeli aşmak için başka geçici alan adları arasında dönüp durmayın. Engelin çalıştığını doğrulamak testtir; engeli aşmak değildir. Şu açıklama açıklama, web sitelerinin neden geçici posta alan adlarını engellediğine bu filtrelerin arkasındaki nedenleri ele alıyor.

E-posta testleri gözetimsiz çalıştığında ne değişir

Kimse izlemiyorken testin, koddan okuyabileceği bir gelen kutusuna ihtiyacı vardır. Bu da bir SMTP yakalayıcısının API'si ya da barındırılan bir gelen kutusu API'si anlamına gelir. Tmailor web gelen kutusu bu araç değildir, ama Tmailor Temp Mail API'si öyledir: testler yalnızca alım yapabilen adresler oluşturabilir, mesajları listeleyip okuyabilir ve API'nin bulduğu tek seferlik kodu veya doğrulama bağlantısını alabilir. Bir MCP sunucusu, Claude, Cursor veya VS Code Copilot gibi yapay zeka ajanlarının sahip olduğunuz ya da test etmenize izin verilen kayıt akışları için aynı şeyi yapmasını sağlar.

Hangi aracı seçerseniz seçin, gözetimsiz e-posta testlerini istikrarlı tutan birkaç alışkanlık:

• Her test çalıştırmasına kendi adresini ve bir korelasyon kimliği verin; böylece önceki bir çalıştırmadan gelen gecikmiş bir e-posta yanlış doğrulamayı karşılayamaz.
• Genel test zaman aşımından ayrı olarak, e-postanın gelmesini beklemek için makul bir geri çekilmeyle çalışan özel bir bekleme kullanın ve her mesajın ne kadar sürdüğünü kaydedin.
• "En son e-postayı" okumak yerine mesajı alıcı ve konuya göre tam olarak eşleştirin.
• Kodları ve sihirli bağlantıları CI günlüklerinde maskeleyin, çünkü günlükler genellikle gelen kutusundan daha uzun ömürlüdür.

Ayrıca bir geçme sınavının ne kanıtladığını net gösterin. "Uygulama e-postayı oluşturup ileti," "barındırılan bir test alan adı e-postayı kamu e-posta altyapısı üzerinden aldı" ve "Gmail e-postayı gelen kutusuna koydu, spam değil" üç farklı gerçek. Bir SMTP yakalayıcısı ilkini kanıtlar, barındırılan gelen kutusu API'si ilk ikisini kanıtlar, hiçbiri üçüncüsünü kanıtlamaz. GitHub Actions, GitLab CI ve CircleCI boru hattı kurulumu için CI /CD pipeline'larında e-posta testi rehberine bakınız.

Test verilerini güvende tutun ve kurallara uyun

Geçici test gelen kutularında sentetik kimlikler ve hassas olmayan içerikler kullanın ve kayıt testlerini yalnızca sahip olduğunuz veya değerlendirmeye yetkili olduğunuz sistemlere karşı yapın. QA hesaplarını üretim analitiğinden uzak tutun, hız sınırlarına uyun ve düzenlemeye tabi verileri, kimlik bilgilerini, ekleri ve saklanan kanıtları onaylı şirket kontrolündeki sistemlere taşıyın.

• Geçici gelen kutusunda gerçek veri olmaz. Gerçek müşteri kayıtlarını, kimlik bilgilerini, API anahtarlarını veya düzenlemeye tabi verileri asla geçici bir e-posta adresine yönlendirmeyin. Açıkça sahte isimlere sahip sentetik kullanıcılar kullanın.
• Yalnızca test etmenize izin verilen şeyi test edin. Kayıt testlerini kendi ürününüze veya test etmeye yetkili olduğunuz bir sisteme karşı yapın ve o hizmetin hız sınırlarına ve koşullarına uyun. Üçüncü taraf sitelerde toplu hesap oluşturmak için geçici e-posta kullanmayın. Hacim ve yük testleri, bir SMTP yakalayıcısı veya barındırılan bir gelen kutusu API'siyle kendi hazırlık ortamınıza aittir.
• QA trafiğini üretim rakamlarının dışında tutun. Test hesaplarını açıkça etiketleyin ve bunları analitik ile büyüme panolarından hariç tutun. Üretim gönderim alan adınızdan büyük hacimlerde test postası göndermekten kaçının; buradaki geri dönüşler ve şikayetler itibarına zarar verebilir.
• Politikayı yazıya dökün. Hangi akışların geçici gelen kutusu kullanabileceğini, hangilerinin şirket posta kutusuna ihtiyaç duyduğunu, test verilerinin ne kadar süre saklandığını ve kimlerin erişimi olduğunu belirtin. Sınırlar zaten kağıt üzerinde olduğunda güvenlik ve uyum incelemeleri daha hızlı ilerler.

Güvenlik ekibi bir sağlayıcının verileri nasıl işlediğini sorduğunda, neleri topladığına, mesajları ne kadar süre tuttuğuna ve erişimin nasıl işlediğine bakın. Şu genel bakış Geçici posta ve çevrimiçi gizliliğe bu soruları kullanıcı tarafından ele alıyor. Hangi akışların tek kullanımlık gelen kutuları kullanabileceğine dair karar yine de kendi hukuk, gizlilik ve güvenlik ekiplerinize aittir.

Planlanması Gereken Sınırlar

Tmailor web gelen kutusu, hassas olmayan gelen e-postaların kısa manuel kontrollerine uygundur (otomasyon için Temp Mail API'si vardır). Seçmeden önce, iş akışının dışa dönük işlemler, ekler, uzun ömürlü kanıtlar veya kalıcı adres kurtarma gerektirip gerektirmediğine karar verin. Bu gereksinimlerden herhangi biri şirket kontrolündeki bir posta kutusu veya uzman bir test aracı gerektirir; aşağıdaki kontrol listesi nedenini açıklıyor.

• Tmailor yalnızca alım yapar. Gelen kayıt, doğrulama ve OTP postalarını kontrol edebilir, ancak yanıt akışlarını veya adresten gönderilen herhangi bir şeyi kontrol edemez.
• Tmailor ekleri almaz; bu nedenle fatura, sözleşme veya belge teslimi e-postaları için şirket posta kutusu ya da bir test aracı gerekir.
• Mesajlar, geldikten yaklaşık 24 saat sonra kalır. Daha uzun bir inceleme için gerekecek bağlantıları, kodları ve zaman damgalarını dışa aktarın.
• Bir access token, süresi dolmuş mesajları değil, adresi yeniden açar; kaybedilen bir token ise geri alınamaz.
• Web gelen kutusunu bir kişi okur. Gözetimsiz gelen kutusu okuması için bir SMTP yakalayıcı veya Tmailor Temp Mail API gibi barındırılan bir gelen kutusu API'si gerekir.
• Bazı hizmetler tek kullanımlık e-posta alan adlarını engeller. Test ettiğiniz bir akış bunu bilerek yapıyorsa, bunu gerçek veya şirket kontrolündeki bir adresle doğrulayın.

Doğru Test Gelen Kutusunu Seçmek

Gelen kutusunu, testin neyi kanıtlaması gerektiğine göre seçin. Teslimat gerekmediğinde ayrılmış bir örnek alan adı, manuel ve hassas olmayan kontroller için geçici bir gelen kutusu, saklanması gereken veya hassas akışlar için şirket posta kutusu, giden ayarları kontrol ettiğinizde bir SMTP yakalayıcı ve gözetimsiz uçtan uca testler için barındırılan bir gelen kutusu API'si kullanın.

Manuel durumlar için, geçici gelen kutusunu açın ve bir sonraki yayına alacağınız kayıt akışıyla başlayın. Geçici postanın QA dışında da birçok pratik kullanımı de.