Geliştiriciler ve Kalite Güvence Testleri için Geçici E-posta

Yazan CatchTempMail · Yayımlandı 2 Ağustos 2026

E-posta birçok ürün iş akışının bir parçasıdır.

Geliştiricilerin ve QA ekiplerinin sıklıkla kayıt mesajlarını, şifre sıfırlamalarını, sihirli bağlantıları, doğrulama kodlarını, e-posta değişikliği onaylarını ve bildirimleri test etmesi gerekir.

Geçici gelen kutuları bunun daha hızlı çalışmasını sağlar çünkü test uzmanları kişisel veya iş posta kutularını kirletmeden yeni adresler oluşturabilir.

Dikkatli kullanıldığında geçici e-posta pratik bir test aracıdır. Dikkatsizce kullanıldığında güvenilmez testler oluşturabilir, test verilerini açığa çıkarabilir veya hazırlama ile üretim arasındaki çizgiyi bulanıklaştırabilir.

Bu kılavuzda, önlenebilir güvenlik veya iş akışı sorunları yaratmadan geliştirme ve QA testleri için geçici e-postanın nasıl kullanılacağı açıklanmaktadır.

Geçici e-posta test için neden faydalıdır?

Birçok kullanıcı yolculuğu e-postaya bağlıdır.

Geçici gelen kutuları ekiplerin şunları test etmesine yardımcı olur:

• Hesap kaydı
• E-posta doğrulaması
• Şifre sıfırlamalar
• Sihirli bağlantı girişi
• Tek kullanımlık şifreler
• E-posta adresi değişiklikleri
• Cihaz onay mesajları
• Deneme katılımı
• Bildirim şablonları
• Abonelikten çıkma akışları
• Test ortamlarında işlem makbuzları

Her test kullanıcısı için yeni bir kalıcı posta kutusu oluşturmak yavaş bir işlemdir.

Aynı ekip gelen kutusunun yeniden kullanılması karışıklık yaratır ve test sonuçlarının ayrıştırılmasını zorlaştırır.

Geçici bir gelen kutusu, her test çalıştırmasına temiz bir hedef sağlar.

İyi geliştirme kullanım durumları

Geçici e-posta, posta kutusunun uzun vadeli bir değeri olmadığında işe yarar.

İyi örnekler şunları içerir:

• Kayıt formundaki manuel QA
• Yerel geliştirme testi
• Aşama ortamı testleri
• Silinecek demo hesapları
• Uçtan uca test çalışmaları
• Bir şablonun doğru şekilde oluşturulup oluşturulmadığını kontrol etme
• Sıfırlama bağlantısının oluşturulduğunun doğrulanması
• Tek kullanımlık kodun geldiğinin onaylanması

Gelen kutusu, dayanıklı bir kimlik olarak değil, tek kullanımlık test altyapısı olarak ele alınmalıdır.

Üretim hesabı bağımlılıklarından kaçının

Gerçek sistemleri kontrol eden üretim hesapları için geçici e-posta kullanmayın.

Şunlar için kaçının:

• Bulut sağlayıcı hesapları
• Alan adı kayıt kuruluşu hesapları
• Ödeme işlemcisi kontrol panelleri
• Üretim takip hizmetleri
• Kaynak kontrol hesapları
• Müşteri destek platformları
• Şifre yöneticileri
• Yönetici kullanıcılar

Bu hesapların güvenilir kurtarmaya, güvenlik uyarılarına, fatura bildirimlerine ve uzun vadeli erişime ihtiyacı vardır.

Bunun yerine, yönetilen bir şirket posta kutusu veya kalıcı bir takma ad kullanın.

Test ve üretim verilerini ayrı tutun

Geçici gelen kutuları gerçek müşteri verilerini almamalıdır.

E-posta özelliklerini test ederken sentetik kullanıcıları ve hassas olmayan donanımları kullanın.

Göndermekten kaçının:

• Gerçek müşteri adları
• Kişisel adresler
• Ödeme verileri
• Tıbbi veya mali veriler
• Özel dosyalar
• Üretim sırları
• Gerçek hesaplar için kimlik doğrulama belirteçleri

OWASP'nin software testing guide'si güvenliğe duyarlı iş akışlarının disiplinli bir şekilde test edilmesini vurgular. E-posta doğrulama ve şifre sıfırlama akışları bu kategoriye girer.

E-posta yolculuğunun tamamını test edin

İyi bir e-posta testi teslimattan daha fazlasını kontrol eder.

Her akış için şunları doğrulayın:

*Mesaj geldi

• Gönderenin kimliği bekleniyor
• Konu gayet açık
• Bağlantı doğru ortama gidiyor
• Belirtecin süresi doluyor
• Jeton tekrar kullanılamaz
• Kullanıcı yararlı bir başarı veya hata durumu görür
• Akış mobil ve masaüstünde çalışır
• Mesaj hassas verileri sızdırmıyor

Parola kurtarma için, özellikle tek kullanımlık belirteçler, son kullanma tarihi ve hesap numaralandırmasından kaçınma konularında OWASP'nin forgot password guidance'sini inceleyin.

Ortama özgü alan adlarını kullanın

Yaygın bir test hatası, üretim etki alanlarına hazırlama bağlantıları veya hazırlama kullanıcılarına üretim bağlantıları göndermektir.Geçici gelen kutuları bunu yakalamanıza yardımcı olabilir.

Bağlantıların beklenen ortama işaret edip etmediğini kontrol edin:```text staging.example.com

example.com

Test adreslerini bilinçli olarak tasarlayın

Rastgele adresler, manuel keşif testleri için kullanışlıdır.

Yapılandırılmış adresler otomatik testler için yararlı olabilir.

Örneğin:```text signup-test-2026-08-02@example.net reset-test-2026-08-02@example.net

Testler paralel olarak yürütülüyorsa mesajların çakışmaması için her çalıştırmanın benzersiz bir adres aldığından emin olun.

## Dikkatlice otomatikleştirin

Geçici gelen kutuları, otomatik uçtan uca testler için uygundur, ancak e-posta, zamanlama ve güvenilirlik sorunlarına neden olur.

Aşağıdakileri sağlayan testler oluşturun:

* Makul bir zaman aşımı süresine sahip anket
* Posta gelmediğinde açıkça başarısız olunması
* Mesajları alıcıya ve beklenen akışa göre eşleştirin
* Yalnızca mesaj sırasına güvenmekten kaçının
* Mümkün olduğunda oluşturulan hesapları temizleyin
* Üretim kullanıcılarını kullanmayın
* Sırları test günlüklerine sabit kodlamayın

E-posta, hassas verilerin toplandığı bir yer değil, testteki bir sinyal olmalıdır.

## Negatif vakaları test edin

Güvenliğe duyarlı e-posta akışları geçersiz davranışları reddetmelidir.

Şunu test edin:

* Süresi dolmuş bağlantılar başarısız oluyor
* Yeniden kullanılan bağlantılar başarısız oluyor
* Kodlar tahmin edilemez
* Jetonlar doğru hesaba bağlıdır
* E-posta değiştirme bağlantıları yanlış kullanıcıyı güncellemez
* Şifre sıfırlama, bir adresin mevcut olup olmadığını göstermez
* Eski oturumlar politikaya göre yönetilir

Geçici gelen kutuları bu senaryolar için yeni kullanıcılar oluşturmayı kolaylaştırır.

## Teslim edilebilirlik farklılıklarına dikkat edin

Geçici bir gelen kutusuna gelen bir mesajın her yere ulaşacağını kanıtlamaz.

Farklı sağlayıcılar farklı spam filtreleme, kimlik doğrulama kontrolleri, görüntü işleme ve bağlantı tarama uygular.

Geniş kapsamlı lansman güveni için ayrıca büyük posta kutusu sağlayıcılarıyla test edin ve şunları inceleyin:

*SPF
*DKIM
*DMARC
* Sıçrama yönetimi
* Pazarlama postalarına yönelik abonelikten çıkma başlıkları
* Düz metin geri dönüşü
* Erişilebilirlik

Google'nin [email sender guidelines](https://support.google.com/a/answer/81126)'si, kimlik doğrulama ve teslimat beklentileri için yararlı bir referanstır.

## Ekiplere güvenlik uyarılarını göz ardı etmeleri konusunda eğitim vermeyin

Dahili test mesajları genellikle tuhaf bağlantılar, hazırlık alanları veya eksik markalama içerir.

Bu, yanlışlıkla insanları şüpheli mesajlara tıklama konusunda eğitebilir.

Test mesajlarının kapsamını açıkça test ortamlarına göre ayarlayın ve gerçek kimlik bilgilerini bu ortamların dışında tutun.

Bir test uzmanı beklenmedik bir doğrulama e-postası alırsa, bunu normal bir gelen kutusunda olduğu gibi incelemelidir.

Kullanıcıya yönelik rehberlik için [How to Identify Phishing Verification Emails](/en/guides/identify-phishing-verification-emails/)'ye bakın.

[[qa-inbox-management-image]]

## Pratik QA kontrol listesi

Testte geçici e-postayı kullanmadan önce şunları onaylayın:

* Çevre üretim dışıdır veya kontrol edilmektedir
* Test adresi benzersizdir
* Gelen kutusu hassas verileri almayacak
* Bağlantılar beklenen ortama işaret ediyor
* Jetonların süresi dolar ve tekrar kullanılamaz
* Günlükler gizli değerler içermez
* Test kullanıcıları temizlenebilir
* Sonuç tam bir teslim edilebilirlik testi olarak değerlendirilmez

## Bunun yerine kalıcı bir test posta kutusu ne zaman kullanılmalı?

Aşağıdakilere ihtiyacınız olduğunda dayanıklı bir test posta kutusu kullanın:

* Uzun süreli test hesapları
* Regresyon geçmişi
* Satıcı desteği yanıtları
* Faturalama veya makbuz testi
* Çok günlük iş akışları
* Sürümler arasında hesap kurtarma
* Denetlenebilirlik ile paylaşılan ekip erişimi

Tek kullanımlık test kimlikleri için geçici gelen kutuları en iyisidir.

Yönetilen test hesaplarının yerini almazlar.

## Tekrarlanabilir bir e-posta testi iş akışı oluşturun

Geçici gelen kutuları, ekip bunları tutarlı bir şekilde kullandığında en kullanışlıdır.

Basit bir iş akışı şöyle görünebilir:

1. Yeni bir test adresi oluşturun.
2. Kullanıcı yolculuğunu hedef ortamda başlatın.
3. Beklenen mesajı bekleyin.
4. Göndereni, içeriği ve bağlantıları inceleyin.
5. Eylemi tamamlayın.
6. Uygulama durumunun doğru şekilde değiştirildiğini doğrulayın.
7. Test kullanıcısını temizleyin.

Her test uzmanının aynı şeyleri kontrol etmesi için iş akışı belgelenmelidir.Tekrarlanabilir bir süreç olmadığında ekipler genellikle yalnızca bir mesajın gelip gelmediğini test eder.

Bu yeterli değil.

Önemli soru, e-postanın ürün akışını başarılı ve güvenli bir şekilde tamamlayıp tamamlamadığıdır.

## Test senaryolarını kullanıcı hikayelerine bağlı tutun

E-posta testleri kullanıcı sonuçlarıyla eşleşmelidir.

Örneğin:

* Yeni bir kullanıcı bir adresi doğrulayabilir ve katılıma devam edebilir
* Geri dönen bir kullanıcı, unutulan bir şifreyi sıfırlayabilir
* E-posta adreslerini değiştiren kullanıcının yeni adresi onaylaması gerekir
* Sihirli bir bağlantı yalnızca amaçlanan hesapta oturum açar
* Süresi dolmuş bir sıfırlama bağlantısı açık bir hata üretir
* Bir bildirim özel verileri yanlış alıcıya göstermez

Geçici gelen kutuları test kullanıcılarının oluşturulmasına yardımcı olur, ancak testin yine de ürün düzeyinde bir onaya ihtiyacı vardır.

E-posta işleminden sonra iş akışının doğru şekilde çalıştığını kanıtlayan veritabanını, kullanıcı arayüzü durumunu, denetim olayını veya API yanıtını kontrol edin.

## Hesap numaralandırma davranışını test edin

Parola sıfırlama ve doğrulama akışları, bir e-posta adresinin bir hesaba ait olup olmadığını yanlışlıkla ortaya çıkarabilir.

Örneğin, bir sıfırlama sayfasında şunu söyleyebilirsiniz:```text
No account exists for this address

Bunun yerine birçok sistem, bir hesap mevcutsa talimatların gönderileceğini söylemek gibi tarafsız bir yanıt gösterir.

Hem mevcut hem de mevcut olmayan adresleri test etmek için geçici gelen kutularını kullanın.

Uygulamanın şunları kontrol edin:

• Tutarlı bir şekilde yanıt verir
• Gereksiz yere hesabın varlığını ortaya çıkarmaz
• Yalnızca uygun olduğunda posta gönderir
• Oran limitlerini uygular
• Kötüye kullanım sinyallerini günlüğe kaydeder

Bu, halka açık kimlik doğrulama akışları için önemlidir.

Hız sınırlarını ve yeniden gönderme davranışını test edin

Doğrulama e-postaları genellikle yeniden gönder düğmeleri içerir.

Bu düğmeler kontrol edilmediği takdirde kötüye kullanım ve teslim edilebilirlik sorunları yaratabilir.

Bir kullanıcı aşağıdaki durumlarda ne olacağını test edin:

• Hızlı bir şekilde birçok doğrulama e-postası ister
• Tekrar tekrar sıfırlama bağlantısı ister
• Aynı IP adresinden birden fazla geçici adres kullanır
• Bir jeton zaten kullanıldıktan sonra kodları ister
• Eski ve yeni bağlantılara sıra dışı tıklamalar

Sistem öngörülebilir olmalıdır.

Gelen kutularına taşmamalı, sınırsız geçerli belirteçler oluşturmamalı veya hangi mesajın güncel olduğunu belirsizleştirmemelidir.

Uç durumları test etmek için geçici gelen kutularını kullanın

Yeni tek kullanımlık adresler olağandışı durumlar için faydalıdır.

Örnekler şunları içerir:

• Uzun e-posta adresleri
• Artı adresleme
• Büyük harfler
• Alt alanlar
• Destekleniyorsa uluslararasılaştırılmış alanlar
• Son zamanlarda değiştirilen adresler
• Silinen kullanıcılar
• Hiçbir zaman kabul etmeyen davet edilen kullanıcılar
• Bir kez doğrulayıp ardından başka bir kod talep eden kullanıcılar

Her e-posta adresinin ilk test hesabı gibi davrandığını varsaymayın.

Giriş doğrulama ve aşağı akışlı posta sistemleri şaşırtıcı şekillerde başarısız olabilir.

Günlüklerdeki ve ekran görüntülerindeki belirteçleri koruyun

E-posta testi sıklıkla belirteçler, bağlantılar ve kodlar üretir.

Bu değerler hesaba erişim izni verebilir.

Bunları aşağıdaki durumlarda açığa çıkarmaktan kaçının:

• CI günlükleri
• Ekran görüntüleri
• Test raporları
• Sohbet mesajları
• Sorun izleyicileri
• Tarayıcı geçmişi
• Paylaşılan kayıtlar

Bir test başarısız olduğunda, yeniden kullanılabilir belirteçleri sızdırmadan sorunun hatalarını ayıklamak için yeterli bağlamı yakalayın.

Günlüklerin URLs içermesi gerekiyorsa belirteç parametrelerini düzenlemeyi düşünün.

E-posta sağlayıcıları ve satıcılarıyla koordinasyon sağlayın

Uygulamanız bir e-posta satıcısı kullanıyorsa, geçici gelen kutusu testi tek doğrulama olmamalıdır.

Ayrıca aşağıdaki gibi satıcı özelliklerini de inceleyin:

• Webhook teslim etkinlikleri
• Sıçrama yönetimi
• Bastırma listeleri
• Şablon versiyonlama
• Korumalı alan modu
• Özel gönderme alanları
• Kimlik doğrulama kayıtları
• Oran limitleri

Geçici gelen kutuları alıcı tarafı davranışını doğrular.

Satıcı günlükleri gönderen tarafının davranışını doğrular.

Her iki görüş de faydalıdır.

Analitikleri kirletmekten kaçının

Test kayıtları ürün metriklerini etkileyebilir.

Aşamalandırmada geçici e-posta kullanılıyorsa bu önemli olmayabilir.

Testler üretime dokunuyorsa analizlerin test trafiğini gerçek kullanıcılardan ayırabildiğinden emin olun.

Test hesaplarını etiketlemeyi, bilinen test alanlarını hariç tutmayı veya manuel QA'yı özel bir ortamda tutmayı düşünün.

Geçici test kullanıcılarının dönüşüm oranlarını, etkinleştirme metriklerini, kampanya ilişkilendirmesini veya kayıp analizini çarpıtmasına izin vermeyin.

Yayınlanmadan önce geliştirici kontrol listesi

E-postaya bağlı bir akışı göndermeden önce şunları doğrulayın:

• Her bağlantı doğru ortama işaret eder
• Jetonlar tek kullanımlıktır
• Jetonların süresi planlandığı tarihte sona erer
• Eski jetonlar değiştirildikten sonra başarısız oluyor
• E-posta değişiklik akışları hem eski hem de yeni adresleri korur
• Yeniden gönderme davranışı hız sınırlıdır
• Hata mesajları hesabın varlığını sızdırmaz
• Şablonlar uzak görüntüler olmadan okunabilir
• Kritik mesajlar gereksiz izlemeyi önler
• Test kullanıcıları üretim kullanıcılarıyla karıştırılmazGeçici gelen kutuları bu kontrollerin çoğunu destekleyebilir ancak güvenlik incelemesinin yerini almazlar.

Örnek test matrisi

Bu tür matris, ekiplerin yalnızca mutlu yolu test etmekten kaçınmasına yardımcı olur.

İnsan kalite güvencesini ve otomatik testleri uyumlu tutun

Manuel test cihazları ve otomatik testler aynı ürün varsayımlarını kullanmalıdır.

Otomasyon, insan kalite denetiminin kafa karıştırıcı veya riskli olarak değerlendireceği bir mesajı kabul ederse ekip gerçek bir kullanılabilirlik sorununu gözden kaçırabilir.

Örneğin, bir test, bir bağlantı mevcut olduğu için başarılı olabilirken, bir insan testçi, e-postanın kullanıcının onu neden aldığını açıklamadığını fark eder.

Aşağıdakiler için e-posta akışlarını inceleyin:

• Net amaç
• Beklenen gönderenin kimliği
• Doğru hesap bağlamı
• Güvenli bağlantı davranışı
• Yararlı hata yönetimi
• Gereksiz hassas veri yok

Geçici gelen kutuları akışın tekrarlanmasını kolaylaştırır ancak ekibin yine de e-postanın kullanıcı için anlamlı olup olmadığına karar vermesi gerekir.

Bilinen sınırlamaları belgeleyin

Her test kurulumunun sınırları vardır.

Geçici gelen kutusu testinin neyi kanıtlamadığını belgeleyin.

Örneğin:

• Gmail, Outlook veya Apple Mail filtrelemeyi temsil etmeyebilir
• Uzun vadede teslim edilebilirliği kanıtlamayabilir
• Tüm mobil istemcileri test etmeyebilir
• Kurumsal e-posta ağ geçidi davranışını açığa çıkarmayabilir
• Üretim gönderme itibarını yansıtmayabilir

Bu sınırları yazmak, yanlış güvenin önlenmesine yardımcı olur.

Geçici e-posta, e-posta kalite programının tamamı değil, hızlı bir test aracıdır.

Sonuç olarak

Geçici e-posta, kaydolma, doğrulama, parola sıfırlama ve sihirli bağlantı testi için güçlü bir seçimdir.

Geliştiricilerin ve QA ekiplerinin hızlı bir şekilde temiz test kimlikleri oluşturmasına yardımcı olur.

Üretim yönetiminden, gerçek müşteri verilerinden ve uzun vadeli kurtarma gerektiren hesaplardan uzak tutun.

Net ortam sınırları ve güvenli test verileriyle birlikte kullanılan Catch Temp Mail, kalıcı ekip gelen kutularını karıştırmadan e-posta iş akışlarının test edilmesini kolaylaştırabilir.