Gerçek ürünler doğası gereği çoklu kullanıcılıdır — ekipler, çalışma alanları, roller, davetler. Bu akışları dürüstçe test edebilmek için aynı anda birden fazla farklı ve erişilebilir gelen kutusuna ihtiyacınız var. Geçici bir gelen kutusu, sessizce bir test uzmanının cephanesindeki en kullanışlı araçlardan birine dönüşür — ve bunun spam'den saklanmakla hiçbir ilgisi yok.

Tek bir gelen kutusu neden yetmez

Kendi adresiniz sistemde zaten kayıtlı olduğu için yepyeni bir kullanıcıyı simüle edemezsiniz — üç farklı yeni kullanıcıyı aynı anda simüle etmek ise hiç mümkün değildir. Ekipler genellikle artı işaretli adresleme (plus-addressing) kullanan paylaşımlı bir QA Gmail hesabına yönelir (ör. [email protected]). Bu yöntem bir yere kadar işe yarar: birçok uygulama "+" etiketini kaldırır ya da reddeder, kabul edildiği durumlarda bile tüm mesajlar yine tek bir posta kutusuna düşer ve hangi "kullanıcının" neyi aldığını anlamak için bunları sonradan tek tek ayıklamanız gerekir.

Geçici gelen kutusu iş akışı

temp-email.ai/temp-mail üzerindeki her sekme, kendine ait benzersiz bir adrese sahip tamamen bağımsız bir gelen kutusudur. Birkaç sekme açtığınızda, gönderip alabileceğiniz gerçek kullanıcılara sahip olursunuz — hesap oluşturma yok, sonradan temizlemeniz gereken paylaşımlı bir posta kutusu yok. Her şey bir saat sonra kendiliğinden silinir, böylece kişisel e-postanıza bağlı bir sürü test hesabıyla baş başa kalmazsınız.

Test etmeye değer senaryolar

• Ekip ve çalışma alanı davetleri: her davetin doğru adrese, çalışan bir bağlantıyla ulaşması gerekir; daveti kabul etmek de kişiyi doğru çalışma alanına, doğru rolle yerleştirmelidir.
• Roller ve izinler: bir sahip (owner), bir yönetici (admin) ve salt okunur bir üyeyi üç ayrı kullanıcı olarak kaydedin, ardından her birinin rolünün izin verdiği şeyleri tam olarak görüp göremediğini — ve göremediği şeyleri gerçekten göremediğini doğrulayın (bkz. OWASP Authorization Cheat Sheet).
• Yinelenen hesap kontrolü: farklı adreslerle iki hesap kaydedin, ardından birini tekrar kullanmayı deneyip uygulamanın nasıl tepki verdiğine bakın — büyük/küçük harf farkı olan aynı adres dahil.
• Referans ve davet ödülü akışları: referans veren kişi ancak davet ettiği kişi kayıt olup e-postasını doğruladığında ödüllendirilmelidir; her iki tarafın da tetiklendiğini görebilmek için iki canlı gelen kutusuna ihtiyacınız vardır.
• Çoklu kiracı (multi-tenant) izolasyonu: iki ayrı organizasyonda hesap oluşturun ve bir kiracının verilerinin diğerinin e-postalarında veya bildirimlerinde asla görünmediğini doğrulayın (bu konu NIST'in çoklu kiracı güvenliği rehberinde de ele alınır).
• Eşzamanlı kayıtlar: aynı saniye içinde birden fazla kullanıcı kaydederek token üretimindeki yarış durumlarını (race condition) ve diğerlerinden çok sonra gelen doğrulama e-postalarını yakalayın.

E-posta geldiğinde nelere bakmalı

• Doğru alıcı: davet yalnızca hedeflenen adrese mi gitti?
• Doğru bağlantı: kabul/doğrulama URL'si, sabit kodlanmış bir üretim (production) bağlantısı yerine doğru ortamı işaret ediyor mu ve doğru çalışma alanı ile rol bağlamını taşıyor mu?
• Doğru sonuç durumu: kabul edildikten sonra kullanıcı doğru organizasyonda ve rolünün sahip olması gereken izinlerle tam olarak eşleşen bir konumda mı?
• Görüntüleme ve izolasyon: e-posta doğru şekilde görüntüleniyor mu (butonlar tıklanabilir, isim doğru şekilde doldurulmuş) ve yanlışlıkla başka bir kullanıcının verisine referans veriyor mu?

Bu yaklaşım en iyi keşif amaçlı testlerde ve bir sürümden önceki manuel regresyon turunda işe yarar — birkaç dakika içinde küçük, gerçekçi bir kullanıcı kadrosu oluşturup ürünü gerçek bir ekibin yapacağı gibi baştan sona deneyimleyebilirsiniz. İki dürüst not: bazı uygulamalar kayıt sırasında bilinen geçici e-posta alan adlarını engeller, bu tamamen o uygulamanın kendi politikasıdır; yayına almadan önce Gmail gibi gerçek bir posta kutusuyla son bir tur yapmakta fayda var, çünkü teslim edilebilirlik (deliverability) tuhaflıkları yalnızca gerçek sağlayıcılarla ortaya çıkar. Bu şekilde kullanıldığında geçici gelen kutuları, gerçek kullanıcılar bu hatalarla karşılaşmadan önce çoklu kullanıcı akışlarını eksiksiz test etmenin basit ve dürüst bir yoludur.