Tek Kullanımlık E-posta ile Kayıt + OTP Akışları Testi: QA Kontrol Listesi

1) Test kapsamı ve ön koşullar

Hedeflenen akışlar

• Yeni kullanıcı kaydı: e-posta + şifre, sosyal login sonrası e-posta bağlama veya e-posta ile “magic link/OTP”.
• OTP doğrulama: e-posta OTP (kod) ve/veya link tabanlı doğrulama.
• Oturum ve hesap güvenliği: cihaz/oturum yönetimi, brute force ve rate limit davranışı.
• Geri kazanım akışları: şifre sıfırlama, e-posta değişimi, hesap kilidi açma.

Test ortamı önerileri

• Log ve izleme: OTP oluşturma/teslimat/kullanım olayları (event) ayrı ayrı loglansın (PII maskeleme ile).
• Mail sağlayıcıları: en az 2 farklı disposable e-posta sağlayıcısı + 1 normal e-posta sağlayıcısı ile çapraz test.
• Saat senkronu: OTP süre aşımı testleri için sunucu saatinin doğru olduğundan emin olun.
• Test verisi: farklı ülke formatları, farklı tarayıcılar, zayıf bağlantı (throttling) profilleri.

Temel başarı kriterleri

• OTP doğru şekilde üretiliyor, kullanıcıya ulaşıyor, tek kullanımlık ve süreli çalışıyor.
• Yanlış denemeler kontrol altında; limitler net; hata mesajları güvenli ve anlaşılır.
• Akış boyunca kullanıcı deneyimi tutarlı; geri dönüş yolları açık; state kaybolmuyor.
• Disposable e-posta özelinde: bloklama varsa doğru gerekçe ve alternatif yönlendirme var.

2) Signup formu: doğrulamalar ve UX

Alan doğrulamaları

• E-posta formatı: RFC uyumlu temel kontroller; boşluk, büyük/küçük harf, unicode/punycode varyasyonları.
• Şifre politikası: minimum uzunluk, karakter seti, sızıntı kontrolü (opsiyonel), kopyala/yapıştır davranışı.
• Hata mesajları: “Bu e-posta kayıtlı” gibi bilgilerde enumeration riski var mı? Mesajlar güvenli mi?
• Buton durumları: yükleniyor/disabled/tekrar dene; çift tıklama ile çift kayıt oluşuyor mu?

Disposable e-posta algılama (varsa)

• Disposable domain tespiti açık/kapalı durumları test edilsin.
• Bloklama uygulanıyorsa:
  • Mesaj net ama saldırgana yardımcı olmayan tonda mı?
  • Alternatif öneri var mı (ör. “kalıcı bir e-posta kullanın”)?
  • Yanlış pozitif oranı gözlemleniyor mu (meşru domain yanlış bloklanıyor mu)?
• Bloklama yoksa: akış en az normal e-posta kadar sorunsuz mu?

UI durum yönetimi

• Sayfa yenileme/geri tuşu sonrası kullanıcı girdiği e-posta kayboluyor mu?
• Mobilde uygulama arka plana gidip gelince doğrulama ekranı bozuluyor mu?
• Çok adımlı akışta (signup → otp): state tek kaynakta mı tutuluyor?

3) OTP üretimi: güvenlik ve mantık kontrolleri

OTP özellikleri

• Tek kullanımlık: aynı kod ikinci kez kullanılamamalı.
• Süreli: belirlenen TTL sonrası kod geçersiz olmalı.
• Bağlılık: OTP kullanıcı + amaç + kanal ile ilişkilendirilmeli (signup OTP’si reset OTP’siyle karışmamalı).
• Format: 6 hane vs 8 hane; sayısal/alfanümerik; kopyalama kolaylığı.

Sunucu tarafı edge case’ler

• Aynı e-posta için çoklu OTP üretimi: önceki kodlar otomatik iptal mi oluyor?
• Paralel istekler: iki farklı cihazdan OTP isteyince tutarlılık korunuyor mu?
• OTP doğrulandıktan sonra: hesap durumu doğru güncelleniyor mu (verified flag)?
• OTP doğrulaması “idempotent” mi? Aynı doğrulama isteği tekrar gelirse güvenli mi?

Rate limit ve brute force koruması

• Resend limit: belirli aralıklarla yeniden gönderim sınırı var mı?
• Verify attempt limit: yanlış kod denemeleri bir eşikten sonra kilitleniyor mu?
• IP/cihaz bazlı limit: tek IP’den çok sayıda signup/otp denemesi kısıtlanıyor mu?
• Geri bildirim: limit aşımı mesajları kullanıcıyı yönlendiriyor mu (bekleme süresi, tekrar dene)?

4) E-posta teslimatı: gerçek dünya testleri

Disposable e-posta ile OTP testinin en kritik kısmı, “kod üretildi” değil “kullanıcı gerçekten aldı” kısmıdır. Bu bölümde teslimat ve gecikme senaryolarını bilerek zorlayın.

Teslimat kontrolleri

• OTP e-postasının konu satırı, gönderici adı ve içerik düzeni beklenen formatta mı?
• Spam/Promotions klasörüne düşme durumu gözlemleniyor mu?
• Disposable sağlayıcıların gecikme/düşürme davranışı var mı?
• E-posta içeriği hem HTML hem düz metin olarak doğru mu (fallback)?

Gecikme ve zaman aşımı senaryoları

• OTP geç gelirse kullanıcıya “kodu tekrar gönder” seçeneği mantıklı bir zamanda sunuluyor mu?
• TTL kısa ise kullanıcı deneyimi bozuluyor mu? TTL uzun ise güvenlik riski artıyor mu?
• Gecikme testinde: eski OTP ile yeni OTP karışıyor mu? Kullanıcı hangi kodu girmeli?

İçerik güvenliği

• OTP e-postasının içinde ekstra hassas bilgi var mı (kullanıcı adı, IP, gereksiz ayrıntı)?
• Link kullanılıyorsa: token tek kullanımlık mı, süreli mi, referrer/paste korunuyor mu?
• Link tıklanınca: doğru cihaz/oturum doğrulaması var mı, yoksa “her yerde açılır” mı?

5) OTP ekranı: doğrulama, hata mesajları ve akış devamı

Doğru kod senaryosu

• Kod doğru girildiğinde kullanıcı doğru ekrana yönleniyor mu (dashboard, onboarding, profil)?
• Kullanıcı durumu doğru işaretleniyor mu (verified, active)?
• Analitik event’leri doğru mu (otp_verified, signup_completed)?

Yanlış kod senaryoları

• Yanlış kod girildiğinde mesaj net mi ama fazla bilgi vermiyor mu?
• Deneme sayısı arttıkça güvenlik önlemleri devreye giriyor mu?
• Kullanıcıyı “resend”e zorlamak yerine doğru yönlendirme yapılıyor mu?

Süre aşımı / kod geçersiz

• TTL dolduğunda kullanıcıya “yeni kod iste” yolu açık mı?
• Eski kodla doğrulama denendiğinde sistem davranışı tutarlı mı?
• “Kod süresi doldu” mesajı kullanıcıyı suçlamadan açıklıyor mu?

UI/UX detayları

• Kod alanı otomatik odaklanıyor mu? Mobilde OTP otomatik doldurma (autofill) çalışıyor mu?
• 6 haneli kod girişinde tek tek kutucuklar doğru çalışıyor mu (paste davranışı dahil)?
• Geri tuşu ile signup ekranına dönünce state bozuluyor mu?

6) Yeniden gönderim (Resend OTP): en çok bozulan yer

Gerçek dünyada kullanıcıların önemli bir kısmı OTP’yi ilk seferde görmez ya da yanlış e-posta yazar. Resend akışı bu yüzden kritik bir “kurtarma” mekanizmasıdır.

Resend kontrol listesi

• Resend butonu hemen mi çıkıyor, yoksa mantıklı bir bekleme sonrası mı aktif oluyor?
• Resend sonrası yeni OTP üretildi mi? Eski OTP otomatik geçersiz mi?
• Resend limitleri (sayı/süre) doğru mu? Kullanıcıya bekleme bilgisi veriliyor mu?
• Resend işlemi arka arkaya tetiklenince sistem tutarlı mı?
• E-posta sağlayıcı gecikmesi yüzünden iki OTP üst üste gelirse kullanıcıyı şaşırtacak bir durum oluşuyor mu?

“E-posta adresini değiştir” senaryosu

• Kullanıcı yanlış e-posta girdiyse OTP ekranından e-posta değiştirebiliyor mu?
• Değişiklik sonrası eski OTP’ler ve pending kayıt durumu temizleniyor mu?
• Yeni e-posta ile doğrulama süreci düzgün başlıyor mu?

7) Disposable e-posta ile suistimal senaryoları

Tek kullanımlık e-posta, QA için iyi olduğu kadar saldırgan için de cazip olabilir. Bu yüzden “sadece çalışıyor mu?” değil “kötüye kullanımda nasıl davranıyor?” sorusu da test edilmelidir.

Enumeration ve bilgi sızıntısı

• “Bu e-posta kayıtlı” mesajı, dışarıdan hesap varlığını doğrulamaya izin veriyor mu?
• OTP isteği atıldığında sistem, kayıtlı/kayıtsız ayrımını saldırgana açık ediyor mu?
• Hata mesajları aynı mı, yoksa durumdan duruma fazla detay mı veriyor?

OTP brute force

• Yanlış OTP denemelerinde artan gecikme (progressive delay) var mı?
• Belirli denemeden sonra hesap/oturum kilidi var mı?
• IP, cihaz veya fingerprint bazlı korumalar devreye giriyor mu?

Çoklu hesap üretimi

• Aynı cihazdan seri hesap üretiminde limit uygulanıyor mu?
• Disposable domain kullanımı yoğunlaştığında risk puanlaması var mı?
• Şüpheli davranışlarda ek doğrulama (captcha gibi) devreye giriyor mu?

8) Mobil uygulama özel senaryoları

Uygulama yaşam döngüsü

• Uygulama arka plana gidip gelince OTP ekranında sayaç/TTL doğru mu?
• Uygulama kapanıp açılınca kullanıcı hangi state’e dönüyor?
• Zayıf ağ/bağlantı kopması: resend ve verify çağrıları doğru şekilde toparlanıyor mu?

Derin link ve link doğrulama

• OTP linki kullanılıyorsa deep link doğru route’a gidiyor mu?
• Link başka cihazda açılırsa ne oluyor? Güvenlik ve UX dengesi doğru mu?
• Link geçersiz/eskimişse kullanıcıya anlaşılır bir geri dönüş sunuluyor mu?

9) Gözlemlenebilirlik: QA’nın “kanıt” katmanı

Test sonucu “oldu” demek yetmez; üretimde bir sorun çıkınca nereden anlaşılacağını da doğrulamak gerekir. Bu yüzden olay kayıtları ve metrikler en az akış kadar önemlidir.

Önerilen event ve metrikler

• otp_requested: e-posta, amaç, kaynak ekran (PII maskeli).
• otp_sent: teslimat sağlayıcısı, latency, message id (güvenli şekilde).
• otp_verified: başarı, deneme sayısı, geçen süre.
• otp_failed: hata türü (invalid, expired, rate_limited) ve kullanıcıya gösterilen mesaj kodu.
• signup_completed: kayıt tamamlandı, ilk oturum açıldı.

Log hijyeni

• OTP kodu loglanmamalı (maskelenmeli veya hiç yazılmamalı).
• E-posta adresi gerekiyorsa hash/partial mask ile tutulmalı.
• Hata stack’leri kullanıcıya taşmamalı; UI’da güvenli mesajlar olmalı.

10) Uçtan uca örnek test senaryoları

Senaryo A: Hızlı kayıt ve doğrulama

1. Disposable e-posta ile kayıt formunu doldurun ve gönderin.
2. OTP e-postasının geldiğini doğrulayın; latency’yi not edin.
3. Kodu girin, doğrulama sonrası yönlendirme ve hesap durumunu kontrol edin.
4. Aynı OTP’yi tekrar deneyin; sistemin güvenli şekilde reddettiğini doğrulayın.

Senaryo B: Resend + eski kod karmaşası

1. OTP isteyin, ilk kod gelmeden resend yapın.
2. İki e-posta geldiğinde hangisinin geçerli olduğunu doğrulayın.
3. Eski kodla doğrulama deneyin; doğru hata ve yönlendirmeyi kontrol edin.
4. Yeni kodla doğrulayın; başarıyla tamamlandığını doğrulayın.

Senaryo C: Rate limit

1. Belirlenen sürede art arda OTP isteyin.
2. Limit noktasında sistemin davranışını kontrol edin (mesaj, bekleme süresi, UI).
3. Bekleme sonrası tekrar deneyin; normal akışa dönüyor mu kontrol edin.

Senaryo D: Süre aşımı

1. OTP isteyin, TTL dolana kadar bekleyin.
2. Eski kodla doğrulayın; “expired” davranışını kontrol edin.
3. Yeni kod isteyip doğrulayın; state temizliği ve kullanıcı deneyimini kontrol edin.

Sonuç

Tek kullanımlık e-posta ile signup + OTP akışlarını test etmek, sadece bir fonksiyon testinden fazlasıdır: teslimat kalitesi, state yönetimi, güvenlik önlemleri ve kullanıcı deneyimini aynı anda ölçersiniz. Bu kontrol listesini düzenli olarak CI/QA süreçlerine ekleyerek, kayıt dönüşümünü artırır; aynı zamanda spam hesap üretimi ve OTP suistimallerine karşı sisteminizi güçlendirirsiniz.