“E-posta geldi” yeterli bir test sonucu değildir.
Bir kayıt mesajı, yanlış alıcı, süresi dolmuş bir bağlantı, bozuk mobil düzen, üretim ana bilgisayar adı ya da başka bir dilde anlamsız bir konu satırıyla gelen kutusuna ulaşabilir. İyi e-posta testi, tüm kullanıcı yolculuğunu izler ve hatayı teşhis etmek için yeterli kanıt bırakır.
Geçici gelen kutuları burada faydalıdır çünkü her çalıştırma temiz bir adresle başlayabilir. Gelen kutusu atılabilir olmalı; test sonucu ise olmamalıdır.
Küçük, kasıtlı bir matris oluşturun
Kullanıcıyı engelleyebilecek akışlarla başlayın:
- yeni hesap doğrulaması;
- şifre sıfırlama;
- takım veya çalışma alanı daveti;
- e-posta değişikliği onayı;
- oturum açma bağlantısı veya tek kullanımlık kod;
- hassas bir işlem sonrası güvenlik uyarısı.
Her akış için mutlu yolu, bir süresi dolmuş ya da yeniden kullanılan kimliği ve bir alıcı‑tarafı hatasını test edin. Bu, aynı mutlu‑yol mesajlarını ondalara göndermekten daha fazla gerçek kusur yakalar.
Senaryo başına bir gelen kutusu kullanın
Tek bir adresi yeniden kullanmak belirsizlik yaratır. Eski bir sıfırlama mesajı en yeniyle karıştırılabilir ve paralel testler birbirlerinin bağlantılarını tüketebilir.
Her test durumu ya da test çalıştırması için benzersiz bir adres oluşturun. Bunu derleme numarası, ortam, yerel ayar ve senaryo ile birlikte kaydedin. Bir test başarısız olursa, adres kanıtın bir parçası olur ve saklama süresi dolmadan incelenebilir.
Staging ortamında gerçek müşteri adresleri kullanmayın. İstenmeyen mesaj riski, analizleri kirletir ve otomatik temizlik zorlaşır.
Gövde öncesinde zarfı doğrulayın
Herhangi bir şeye tıklamadan önce şunları doğrulayın:
- Mesaj, bu test için oluşturulan tam adrese gönderildi.
- Gönderen alan adı, ortam için beklenen alan adı.
- Konu, hassas verileri ifşa etmeden eylemi tanımlıyor.
- Sadece hedeflenen sayıda mesaj geldi.
- Zaman damgası, tetikleyen eylemden daha sonraki bir zaman.
Bu kontroller, gövde ayrıştırıcısı gizlemeden önce yönlendirme ve çoğaltma sorunlarını yakalar.
İçeriği kullanıcı gördüğü gibi test edin
Mesajı hem dar hem de geniş bir görünümde açın. Birincil eylemin görünür olduğundan, düz‑metin yedeklemesinin anlaşılır olduğundan ve uzun adres ya da URL'lerin düzeni bozmadığından emin olun.
Kod‑tabanlı bir akış için, en yeni kodun bir kez çalıştığını ve kullanım sonrası başarısız olduğunu doğrulayın. Bağlantı‑tabanlı bir akışta, açmadan önce ana bilgisayarı ve ortamı onaylayın. Staging mesajının üretime işaret etmesi, bağlantı teknik olarak çalışsa bile bir sürüm engelleyicidir.
Ayrıca daha az göz alıcı detayları da kontrol edin: yanıt‑adres davranışı, destek iletişimi, süresi dolma ifadesi, yerel ayar ve mesajda gösterilen hesap ya da çalışma alanı adı.
Değerli negatif durumlar
Kullanışlı negatif testler şunları içerir:
- ikinci bir kod talep etmek ve birincisinin geçersiz olduğunu doğrulamak;
- süresi dolmuş bir bağlantıyı açmak;
- aynı bağlantıyı iki kez açmak;
- mesajı kullanmadan önce hesap durumunu değiştirmek;
- zaten bir üyenin adresi olan bir adresi davet etmek;
- desteklenmeyen veya hatalı biçimlendirilmiş bir adres girmek;
- teslimi, sürenin aşılmasına kadar geciktirmek.
Bu testler, basit bir gelen kutusu kontrolünün asla bulamayacağı yarış koşulları ve yanıltıcı hata mesajlarını ortaya çıkarır.
Ürün hatasını teslim gecikmesinden ayırın
Bir mesaj eksik olduğunda, mümkün olduğunda kullanıcı eylemi, uygulama kuyruğa ekleme, sağlayıcı devri ve gelen kutusuna varış zaman damgalarını koruyun. Boş bir gelen kutusunun ekran görüntüsü yalnızca mesajın o anda görünür olmadığını kanıtlar.
Genel bir “e-posta bozuk” sorunu açmadan önce Doğrulama E-postası Gelmiyor: Bozuk Adımı Bulun içindeki tanı dizisini kullanın.
Otomatikleştirilecekler
Kararlı sözleşmeleri otomatikleştirin:
- benzersiz bir adres oluşturun;
- ürün eylemini tetikleyin;
- sınırlı bir zaman aşımı ve geri çekilme ile sorgulayın;
- beklenen gönderici ve konuyu eşleştirin;
- en yeni eşleşen mesajı okuyun;
- kodu veya bağlantıyı ürünle doğrulayın;
- faydalı hata kanıtlarını kaydedin;
- temizleyin.
Görsel inceleme, metin kalitesi ve alışılmadık istemci davranışlarını odaklı bir manuel geçişte tutun. Otomasyon tekrar için iyidir, zevk için değil.
Güvenilir Geçici-Gelen Kutusu API Otomasyonu API tarafını, sorgulamayı ve temizlik işlemlerini kapsar.
Faydalı bir hata raporu
Geliştiricilerin harekete geçebileceği bir rapor, senaryo, ortam, adres, tetikleme zamanı, beklenen gönderici, gözlemlenen mesajlar, son sorgulama zamanı, yanıt durumu ve bir ekran görüntüsü ya da temizlenmiş gövde alıntısı içerir. Canlı sırları ya da yeniden kullanılabilir doğrulama bağlantılarını herkese açık bir soruna asla eklemeyin.
Amaç, e-postanın güvenilmez olduğunu kanıtlamak değil; hangi sözleşmenin başarısız olduğunu belirlemek ve düzeltmeye giden yeniden üretilebilir bir yolu bırakmaktır.