QA Ekipleri Kayıt ve Çoklu Kullanıcı Senaryolarını Geçici Gelen Kutularıyla Nasıl Test Eder

Herhangi bir QA mühendisine en sinir bozucu hataların nerede gizlendiğini sorun, hepsi aynı şeyi söyler: tek bir kullanıcının mutlu yolunda değil, kullanıcıların arasındaki boşlukta. İki kişi tam olarak aynı anda kayıt olur. Bir davet e-postası yanlış kişiye gider. Bir yönetici ile salt okunur bir üye aynı sayfayı açar ve içlerinden biri görmemesi gereken bir şeyi görür. Bunların hiçbiri, kendi e-posta adresinizle tek başınıza test ederken yeniden üretilemez; çünkü veritabanında siz her zaman yalnızca tek bir kullanıcısınız.

Gerçek ürünler doğası gereği çoklu kullanıcılıdır — ekipler, çalışma alanları, roller, davetler, referanslar, kiracılar. 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. İşte tam bu noktada geçici bir gelen kutusu, sessizce bir test uzmanının çantasındaki en kullanışlı araçlardan birine dönüşür — ve bu kullanımın spam'den saklanmakla hiçbir ilgisi yoktur.

Tek bir gerçek gelen kutusu (ya da paylaşımlı bir QA Gmail'i) neden yetmez

Kendi adresinizle ilgili sorun basittir: adres sistemde zaten var. Kaydınız zaten veritabanındayken "daha önce hiç görülmemiş, yepyeni bir kullanıcı" simüle edemezsiniz ve kesinlikle aynı anda üç farklı yeni kullanıcı olamazsınız. Ekipler bu yüzden sık sık paylaşımlı bir QA Gmail hesabına yönelir ve artı işaretli adreslemeye (plus-addressing) dayanır — [email protected], [email protected] ve benzeri. Bu, çalıştığı sürece çalışır: pek çok uygulama + etiketini kaldırır ya da normalize eder, bazıları düpedüz reddeder ve kabul edildiğinde bile tüm mesajlar yine tek bir posta kutusuna düşer; sonra da hangi "kullanıcının" neyi aldığını çözmek için bunları tek tek ayıklamanız gerekir.

Gerçek anlamda çoklu kullanıcı testi için, gerçekten ayrı olan gelen kutuları istersiniz — ayrı adresler, ayrı posta kutuları, paylaşılan durum yok. Birkaç sekme açarak elde ettiğiniz şey tam olarak budur.

Geçici gelen kutuları QA'nın neresine oturur

temp mail üzerindeki her sekme, kendine ait benzersiz bir adrese sahip tamamen bağımsız bir gelen kutusudur. Üç sekme açın ve gönderip alabileceğiniz üç gerçek kullanıcınız olsun — hesap oluşturma yok, sonradan temizlemeniz gereken paylaşımlı bir posta kutusu yok ve her adres sıfırdan üretildiği için dünkü test koşusundan kalan hiçbir artık durum bugünkü sonuçları bulandırmaz. İşiniz bittiğinde her şey bir saat sonra kendiliğinden silinir, böylece kişisel e-postanıza bağlı bir test hesapları mezarlığı biriktirmezsiniz.

Gerçekten test etmeye değer çoklu kullanıcı senaryoları

Yan yana duran birden fazla canlı gelen kutusuna sahip olmanın karşılığını verdiği akışlar — sürümden önce kimse kolayca yeniden üretemediği için üretimde sessizce bozulanlar — şunlar:

• Ekip ve çalışma alanı davetleri: kullanıcı A bir çalışma alanı oluşturur ve B ile C'yi davet eder. Her davetin, çalışan, güvenli bir şekilde üretilmiş bir bağlantıyla doğru adrese ulaşması gerekir ve kabul edilmesi her kişiyi doğru çalışma alanına, doğru rolle yerleştirmelidir. Üç gelen kutusunu aynı anda izlerseniz yanlış yönlendirilmiş bir daveti anında fark edersiniz.
• 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. İzin hataları, gerçekten daha düşük yetkili kullanıcı olarak, ideal olarak da daha yüksek yetkiliyle aynı anda oturum açana kadar görünmezdir. Burada nelerin araştırılacağı için OWASP Authorization Cheat Sheet iyi bir kontrol listesidir.
• Yinelenen hesap kontrolü: farklı adreslerle iki hesap kaydedin, ardından birini tekrar kullanmayı deneyin. Uygulama, yinelenen kaydı beklediğiniz gibi tespit ediyor mu? Peki ya büyük/küçük harf farkı olan aynı adres ya da sonuna kaçak bir nokta eklenmiş hâli? Taze adresler bu sınır durumlarını kurmayı son derece kolaylaştırır.
• Referans ve davet ödülü akışları: referans veren kişi genellikle ancak davet ettiği kişi kayıt olup doğrulama yaptıktan sonra kredilendirilir. Her iki tarafın da tetiklendiğini görmek için iki gerçek gelen kutusuna ihtiyacınız var — davetin çıkışı ve ikinci kullanıcı akışı tamamladığında ödülün gelişi (ya da doğru şekilde gelmeyişi).
• Çoklu kiracı (multi-tenant) izolasyonu: iki ayrı organizasyonda hesap oluşturun ve bir kiracının verilerinin diğerinin ekranlarına, bildirimlerine veya e-postalarına asla sızmadığını doğrulayın — NIST'in bulut çoklu kiracılık rehberinin özellikle işaret ettiği türden bir hata. Yanlış gelen kutusundaki başıboş bir adres, çoğu zaman bir veri izolasyonu hatasının ilk görünür işaretidir.
• Eşzamanlı kayıtlar: aynı saniye içinde birden fazla kullanıcı kaydederek token üretimindeki yarış durumlarını (race condition), benzersizlik kısıtı çakışmalarını ve bazı doğrulama e-postalarının diğerlerinden çok daha geç gelmesine yol açan kuyruk gecikmelerini açığa çıkarın.
• Koltuk ve plan sınırları: bir planı farklı kullanıcılarla koltuk üst sınırına kadar doldurun, ardından bir tane daha eklemeyi deneyin. Sınır tutmalı — ve fazladan gelen kullanıcının karşılaştığı hata bir 500 değil, açık ve net olmalı.
• Bildirim dağıtımı: bir hesapta bir eylemi tetikleyin ve doğru takım arkadaşlarının — yalnızca onların — bildirim e-postasını aldığını doğrulayın. İstemeden herkese ya da hiç kimseye e-posta göndermek çok kolaydır.

İşi yönetilebilir tutan bir iş akışı

Pratik püf noktası, her sekmeyi testinizdeki adı olan bir karakter gibi ele almaktır. Kullanıcı başına bir sekme açın ve hangisinin hangisi olduğuna — Sahip, Yönetici, Üye — baştan karar verin, ardından her adresi kendi kayıt formuna kopyalayın. Sekmeleri bir bakışta görebileceğiniz şekilde dizin. Teslimat pratikte anlık olduğu için, daveti gönderdiğiniz anda geldiğini görürsünüz; bu da neden-sonucu, paylaşımlı bir gelen kutusunu sürekli yoklamanın asla başaramayacağı bir netlikte ortaya koyar.

Hangi rastgele adresin hangi role karşılık geldiğini test adımlarınızın yanına not edin — adresler seçilmez, üretilir; bu yüzden kısa bir not sonradan yaşanacak kafa karışıklığını önler. Ve kazancınız şu: bir e-posta yanlış sekmede belirdiği anda, o bir destek talebine dönüşmeden çok önce, bir yönlendirme veya izolasyon hatasını oracıkta yakalamış olursunuz.

E-posta geldiğinde nelere bakmalı

E-postayı almak işin yalnızca yarısıdır. Bir mesaj geldiğinde, onu gerçekten doğrulamak için birkaç saniye ayırın:

• Doğru alıcı: davet, davet edilen adrese mi gitti — ve başka hiçbir yere gitmedi mi?
• Doğru bağlantı: kabul veya doğrulama URL'si, sabit kodlanmış bir üretim bağlantısı yerine doğru ortamı işaret ediyor ve doğru çalışma alanı ile rol bağlamını taşıyor mu?
• Doğru sonuç durumu: kabul ettikten sonra yeni kullanıcı, rolünün sahip olması gereken izinlerle tam olarak, doğru organizasyonda mı?
• Görüntüleme: e-posta gerçek bir gelen kutusunda doğru görünüyor mu — butonlar tıklanabilir, alıcının adı doldurulmuş, artakalan bir "Hi {{firstName}}" yer tutucusu yok mu?
• İzolasyon: bir kullanıcının e-postası hiç yanlışlıkla başka bir kullanıcının verisine atıfta bulunuyor mu? Bu, peşine düşülmeye değer bir tehlike işaretidir.
• Zamanlama: her şey birkaç saniye içinde gelmeli. Tutarlı bir gecikme, gerçek kullanıcılarınızın da hissedeceği bir kuyruk veya DNS sorununa işaret eder.

Temiz test verisi, hem de bedava

Hafife alınan bir avantaj: her geçici adres boş başlar ve bir saat sonra kaybolur, böylece her koşu bilinen, temiz bir durumdan başlar. "Kesinlikle boş gelen kutusu, yepyeni kullanıcı"dan başlayan bir test, geçen haftanın artıklarının sonucu çarpıtıp çarpıtmadığını merak etmeden gerçekten güvenip yeniden çalıştırabileceğiniz bir testtir. Tekrarlanabilirlik, iyi bir QA'nın yarısıdır ve burada hiçbir temizlik yapmadan onu elde edersiniz.

Keşif amaçlı ve sürüm öncesi regresyon turları için ideal

Bu yaklaşım asıl olarak keşif amaçlı testlerde ve bir sürümden önceki manuel regresyon turunda parlar. Birkaç dakika içinde gerçekçi, küçük bir kullanıcı kadrosu — bir sahip, birkaç üye, dışarıdan bir davetli — kurabilir ve ürünü tam da gerçek bir ekibin yapacağı gibi baştan sona gezerken e-postaların tetiklenişini izleyebilirsiniz. Bu, beş gerçek posta kutusu tahsis etmeden "uygulamayı aynı anda beş farklı kişi olarak kullanmaya" en yakın şeydir. Tek kullanıcılı kısımları da test ediyorsanız, e-posta doğrulamasını test etme ve parola sıfırlama akışları hakkındaki rehberlerimiz bununla doğal olarak eşleşir.

Sınırlar konusunda dürüst olunması gereken yer

Dürüst olmakta fayda olan birkaç nokta var, çünkü aksini varsaymak yalnızca vaktinizi harcar. Bazı uygulamalar kayıt sırasında bilinen geçici e-posta alan adlarını engeller — kayıt formunuz adresi reddediyorsa, bu uygulamanın kendi politikasıdır ve o belirli testler için bunun yerine izin listesine alınmış bir dahili alan adına ihtiyacınız olabilir. Bu ayrıca manuel, keşif amaçlı bir iş akışıdır: bir API çağırmıyor, bir tarayıcıyı yönetiyorsunuz; dolayısıyla CI'daki otomatik uçtan uca e-posta testlerinin yerini almaz, onları tamamlar. Ve yayına almadan önce Gmail veya Outlook gibi gerçek bir posta kutusuyla son bir tur atın — teslim edilebilirlik tuhaflıkları ve spam klasörü davranışı yalnızca gerçek sağlayıcılara karşı ortaya çıkar.

Kısaca

Tek gelen kutusuyla test etmek, tek kullanıcılı hataları bulur. Gerçekten üretime ulaşanlar ise kullanıcılar arasındaki boşluklarda yaşar — davetler, roller, kiracılar, sınırlar ve yarışlar. Geçici gelen kutuları, tek bir test uzmanının bir ekibin tamamını aynı anda oynamasına, üstelik her koşuda temiz bir durumdan başlamasına olanak tanır; bunun için gereken süre ise birkaç sekme açmaktan biraz fazlasıdır. temp-email.ai adresine gidin, kullanıcı başına bir sekme açın ve gerçekten önemli olan senaryoları test etmeye başlayın.