Mail doğrulama akışı testi, bir kullanıcının adresini yazdığı andan doğrulamanın tamamlandığı ana kadar geçen her yolun denenmesidir. Çoğu ekip yalnızca mutlu yolu çalıştırır; oysa gerçek kullanıcılar eski bağlantıya tıklar, formu iki kez gönderir ve aynı adresi farklı hesaplarda kullanır. Bu yazıda bu yolların her birinin nasıl sınanacağını ve doğrulamanın arkasındaki durumun nasıl kurgulanması gerektiğini bulacaksınız.
Doğrulama akışı hangi adımlardan oluşur?
Her doğrulama akışı aynı iskelete oturur. Önce kullanıcı adresini girer, sistem bu adrese bir bağlantı ya da kod gönderir. Kullanıcı bağlantıyı açar ve sistem bu bağlantının gerçekten kendi ürettiği bir istek olduğunu doğrular. Sonra kaydın durumu değişir ve artık doğrulanmış sayılır. Aynı iskelet üç ayrı yerde karşımıza çıkar: yeni kayıt, hesabın adresini değiştirme ve parola sıfırlama. Üçü de benzer görünse de farklı riskler taşır; örneğin adres değiştirmede iki ayrı adresin onayı gerekebilir, parola sıfırlamada ise doğrulama doğrudan hesap güvenliğine dokunur.
Bu akışın en önemli parçası, gönderilen bağlantının tek kullanımlık ve süreli olmasıdır. Bağlantı, kaydın kimliğini ve o anın koşullarını taşır; kullanıldığında geçersiz hâle gelmeli, süresi dolduğunda ise kabul edilmemelidir. Bu iki kural birlikte çalışmadığında, doğrulama bir güvenlik önlemi olmaktan çıkıp yalnızca bir formaliteye dönüşür.
Akışı yalnızca mutlu yol üzerinden anlatmak, gerçek kullanıcı davranışını gözden kaçırır. Kullanıcılar sekmeyi kapatır, postayı sonra açar, formu yanlışlıkla iki kez gönderir ve adreslerini yanlış yazar. Bu davranışların hepsi doğrulama akışının bir parçasıdır; akışın tasarımı, bu durumlarda kullanıcıyı çıkmaza sokmamalıdır. İyi bir doğrulama akışı, kullanıcıya her adımda ne olduğunu söyler ve devam etmenin bir yolunu bırakır: posta gelmediyse yeniden gönderme, bağlantı eskidiyse yeni bağlantı isteme, adres yanlış yazıldıysa düzeltme.
Hangi senaryolar mutlaka denenmeli?
Doğrulama akışı için asgari test kümesi şu başlıkları içermelidir:
| Senaryo | Beklenen davranış |
|---|---|
| Doğru bağlantı ilk kez açılır | Kayıt doğrulanır, durum değişir |
| Aynı bağlantı ikinci kez açılır | Reddedilir ya da zaten doğrulanmış bilgisi gösterilir |
| Süresi dolmuş bağlantı açılır | Açık bir hata ve yeni bağlantı isteme yolu sunulur |
| Bağlantı başka bir tarayıcıda açılır | Sonuç oturuma değil jetonun kendisine bağlıdır |
| Posta hiç ulaşmaz | Kullanıcı yeniden gönderme yolunu bulabilir |
| Adres değiştirme sırasında eski bağlantı açılır | Değişiklik tamamlanmaz, tutarsız durum oluşmaz |
| Aynı adres iki hesapta denenir | Kural nettir: ya reddedilir ya da her iki hesap ayrı kalır |
Bu tablonun en çok atlanan satırı son satırdır. Aynı adresle iki hesap açılabiliyorsa, kullanıcı parola sıfırlama yaptığında hangi hesabı geri aldığını bilemez; iki hesap da aynı posta kutusuna bağlı kalır. Bu kuralın üründe bilinçli olarak seçilmesi ve testte bu seçimin doğrulanması gerekir. Bu adresler yalnızca kayıt akışlarını sınamak için verilir; gerçek kimlik doğrulamasında geçerli sayılmaz.
Süresi dolmuş bağlantıya tıklanırsa ne olmalı?
Kullanıcı eski bir postayı açtığında iki şeyden biri olmalıdır: ya akış yeni bir bağlantı isteme ekranına yönlendirilmeli, ya da durumu açıkça anlatan bir hata gösterilmelidir. Beyaz ekran, sessiz yönlendirme veya “başarılı” mesajı vermek en kötü sonuçlardır; kullanıcı doğrulandığını sanıp sonra hesabına giremediğinde sorunun kaynağını bulamaz.
Süre bitiminin test edilmesi genellikle zordur, çünkü beklemek istemezsiniz. Bunun yerine süre, üretim kodunda okunabilir bir değer olarak tutulmalı ve test ortamında bu değerin kısa bir karşılığı kullanılmalıdır. Testin kendisi sabit bir süre beklememeli; jetonun geçersiz olduğu bir durumu doğrudan kurabilmelidir. Böylece hem hızlı hem de gerçekçi bir kontrol yapılır. Buradaki ayrım önemlidir: test ettiğiniz şey sürenin uzunluğu değil, süresi geçmiş bir jetonun doğru şekilde reddedilmesidir.
Aynı bağlantı iki kez açılırsa?
Tek kullanımlık bir jeton, ikinci açılışta kabul edilmemelidir. Ancak burada bir incelik vardır: kullanıcı bağlantıya iki kez tıklamış olabilir ya da posta istemcisi bağlantıyı önizlerken arka planda açmış olabilir. Bu yüzden ikinci açılışta gösterilecek ekran, kullanıcıyı korkutmamalı; “bu bağlantı zaten kullanıldı, hesabınız doğrulanmış görünüyor” gibi yönlendirici bir mesaj en doğrusudur.
Bunun testi iki ayrı biçimde yapılmalıdır: aynı jetonu sırayla iki kez kullanmak ve iki isteği neredeyse aynı anda göndermek. Eşzamanlı deneme, yalnızca ikinci isteği engelleyen ama arada güncelleme yapmayan bir kodun hatasını ortaya çıkarır. Doğru davranış, jetonun geçersiz kılınması ile kaydın durum değişikliğinin tek bir işlem gibi davranmasıdır; aksi hâlde aynı anda gelen iki istek iki farklı sonuç üretir.
Aynı adres iki hesapta kullanılırsa?
Bu sorunun cevabı ürüne göre değişir ama tutarlı olmak zorundadır. İki yaklaşım vardır: adresi tek hesaba bağlamak ve ikinci kaydı reddetmek, ya da aynı adresi birden fazla hesapta kabul etmek. İkincisinde parola sıfırlama akışının hangi hesabı hedeflediği ayrıca çözülmelidir; aksi hâlde kullanıcı bir hesabı için istediği sıfırlama bağlantısıyla diğer hesabına erişebilir.
İlk yaklaşımın testi kolaydır: aynı adresle ikinci kayıt denenir ve beklenen hata mesajı doğrulanır. İkinci yaklaşımın testi ise daha geniştir; sıfırlama bağlantısının hangi hesabı işaret ettiği, oturumun hangi hesaba geçtiği ve iki hesabın ayrı ayrı yönetilebildiği gösterilmelidir.
Geliştiriciler için: durum makinesi ve jeton tasarımı
Doğrulama akışını bir durum makinesi olarak yazmak, testleri de basitleştirir. Kaydın en az üç durumu olmalıdır: doğrulanmamış, doğrulanmış ve adres değişikliği bekleyen. Her geçişin hangi olayla tetiklendiğini ve geçişin hangi durumlardan yasak olduğunu açıkça tanımlamak, “aynı anda iki bağlantı” ve “değişiklik sırasında eski bağlantı” gibi karışık senaryoların kendiliğinden doğru sonuçlanmasını sağlar.
Jeton tarafında üç nokta kritiktir. Birincisi, jetonun tek kullanımlık olması ve kullanıldığı anda geçersiz kılınmasıdır. İkincisi, jetonun yalnızca hangi kayda ait olduğunu değil, hangi işlem için üretildiğini de taşımasıdır; kayıt ve parola sıfırlama jetonları birbirinin yerine geçmemelidir. Üçüncüsü, doğrulama isteğinin oturuma değil jetonun kendisine bağlı olmasıdır; kullanıcı bağlantıyı farklı bir tarayıcıda açtığında akış yine çalışmalıdır.
Test tarafında ise en sık yapılan hata, yalnızca mutlu yolu denemektir. Doğrulama akışının değeri, tam olarak mutlu yolun dışındaki durumlarda ortaya çıkar. Bu yüzden “posta gelmedi”, “bağlantı eskidi”, “iki kez tıklandı” ve “adres zaten kayıtlı” yollarının her biri için ayrı bir test yazılmalıdır. Postaları okumak için her senaryoya kendi geçici adresini vermek, bu testlerin birbirine karışmasını engeller; arka planda çalışan akışı anlamak için geçici mail nasıl çalışır yazısı yararlı olur.
Sonraki adımlar
Doğrulama akışını gözden geçirmenin en verimli yolu, akışı kâğıda bir durum listesi olarak çizmek ve her geçiş için bir test yazmaktır. Ardından, mutlu yolun dışındaki senaryoları kendi ortamınızda deneyin. Akışta kullanıcıya gösterilen her mesajın hangi durumda çıktığı da testin beklentileri arasında yer almalıdır. geçici e-posta aracında her senaryo için ayrı bir adres üretebilir, gelen postayı açık gelen kutusundan izleyebilirsiniz. Doğrulama kodunu otomatik okumaya geçtiğinizde uçtan uca testlerde OTP yazısı, gönderilen postaların içeriğini denetlemek istediğinizde ise işlem maili test listesi yol gösterir.
Bu akışta kullanılan adresler yalnızca doğrulama adımlarını sınamak içindir; kişisel bir hesabın kalıcı adresi yerine geçmez.