Müşteri başvurularını, verileri ve yetkileri anlamlı otomatik testlerle korumak için örnek bir akış, hata senaryoları ve açık yayın kararları içeren uygulamalı rehber.
Bir işletmenin web sitesi düzgün görünebilir; buna rağmen teklif formu başvuruları kaydetmiyor olabilir. Kullanıcı hesabına giriş yapabilir, fakat açılan sayfada başka müşteriye ait bir belge görebilir. Bu yüzden otomatik testin başlangıç noktası açılabilen sayfaların sayısı değildir. Önce sitenin müşteriye verdiği sözü ve bu sözün tutulduğunu gösterecek kanıtı tanımlamak gerekir. Beklenen davranış, deneme verileri ve başarısızlıkların sorumlusu belli olduğunda aynı kontroller her değişiklikte tekrar edilebilir.
Bu rehberdeki eğitim şirketi ve atölye başvuru akışı varsayımsaldır. Örnek, gerçek bir projede elde edilmiş sonuçları anlatmaz ve belirli bir hata azalması vadetmez. Amaç, işletme sahibi, ürün sorumlusu ve geliştiricinin yayın kararında kullanabileceği ortak bir test dili oluşturmaktır.
İş beklentisini ölçülebilir bir sonuca çevirin
“Form çalışıyor” yeterince açık bir kabul koşulu değildir. Şöyle yazın: ziyaretçi başvuruya açık atölyeyi seçer, geçerli bilgilerini gönderir, başvuru numarası alır ve kayıt yetkili çalışanın inceleme ekranında görünür. Olmaması gerekenleri de belirtin: yeniden denemede çift kayıt oluşmaması, yetkisiz çalışanın kişisel bilgileri görememesi ve sunucu kabul etmeden başarı mesajı gösterilmemesi. Bu koşulları web sitesi proje ihtiyaç dokümanına eklemek, sonradan çıkabilecek yorum farklılıklarını azaltır.
Öncelik sırasını hatanın işletmeye etkisi, fark edilme güçlüğü ve ilgili bölümün değişme sıklığıyla belirleyin. Yeni müşteri getiren bir form başlangıç için uygun olabilir. Daha az kullanılan bir belge indirme işlemi de özel bilgiler içeriyorsa aynı derecede önem taşıyabilir. Yalnızca ziyaret sayısına bakarak karar vermek, sessizce oluşan önemli sorunları gözden kaçırabilir.
Uygulamalı örnek: atölyeye başvuru
Örneğimizde başvurunun gönderilmesi yer ayrıldığı anlamına gelmesin. Katılımı daha sonra yetkili çalışan onaylasın. Test yazılmadan önce bu ayrım üzerinde anlaşılmalıdır; aksi halde test yanlış bir ürün kararını başarıyla doğrulayabilir. Başvuruya açık ve kapalı atölyeler, inceleme yetkisi olan bir çalışan ve bu yetkisi olmayan başka bir çalışan için tamamen kurgusal deneme verileri hazırlayın.
- Başarılı başvuru: açık atölyeyi seçip geçerli bilgileri gönderin. Başvuru numarasını, “İnceleme bekliyor” durumundaki tek kaydı ve kaydın ilgili çalışana görünmesini doğrulayın.
- Eksik bilgi: zorunlu alanı boş bırakın veya yalnızca boşluk girin. Alanın yanında anlaşılır hata bekleyin. Başvuru oluşmamalı, diğer geçerli bilgiler korunmalıdır.
- Değişen durum: ziyaretçi formu açtıktan sonra başvuruları kapatın. Sunucu, kararlaştırılmış kurala göre gönderimi reddetmeli; arayüz nedenini ve sonraki adımı açıklamalıdır.
- Tekrarlanan gönderim: düğmeye yeniden basın veya bağlantı kesildikten sonra tekrar deneyin. Kayıt sayısını ve başvuru numarasını kontrol edin. Düğmenin pasif görünmesi tek başına yeterli kanıt değildir.
- Yetkili inceleme: sorumlu çalışan başvuruyu okuyup durumunu değiştirebilmeli; diğer hesap özel bilgileri alamamalı ve değişiklik yapamamalıdır.
Teşekkür mesajını görmek, kaydın gerçekten saklandığını kanıtlamaz. Veritabanındaki kayıt da ziyaretçinin sonsuz bir yüklenme ekranında kalmadığını göstermez. Kabul koşulu, saklanan sonuç ile kullanıcının gördüğü deneyim arasındaki bağlantıyı kurmalıdır. İşletme açısından sorun, bu iki taraftan herhangi birinde ortaya çıkabilir.
Soruya uygun test katmanını seçin
Her kuralı tarayıcıda baştan sona çalıştırmak gerekmez. Tarih, kontenjan ve başvuru durumu kombinasyonları iş mantığına yakın bir yerde sınanabilir. API testleri geçersiz verinin reddedilmesi, erişim kararları ve durum geçişleri için uygundur. Tarayıcı testleri ise parçaların birlikte çalışmasını denetler: atölye seçimi, alanların doldurulması, gönderim ve anlaşılır sonucun gösterilmesi.
Buradaki maliyet yalnızca çalıştırma süresi değildir. Geniş tarayıcı kapsamı gerçek etkileşimleri izlerken arayüz değişikliklerinde bakım isteyebilir. Yalnızca küçük fonksiyonları sınamak ise bileşenlerin birleştiği yerleri açık bırakabilir. Örneğimiz için kural çeşitlerini ilgili katmanda kapsayıp temel yolculuklar için seçilmiş tarayıcı senaryoları tutmak makul bir başlangıçtır. Ürünü ve yayın sürecini anlamadan her ekibe aynı test oranını önermek yararlı değildir.
Reddedilme ve toparlanma da ayrı senaryolardır
Adres veya istek içindeki başvuru kimliğini değiştirerek başka bir kişinin kaydını okumayı deneyin. Çalışanın yetkisi kaldırıldıktan sonra önceden açılmış ekrandan durum güncelleyin. Tarayıcı alan kurallarını atlayarak sunucuya geçersiz veri gönderin. Test yalnızca hata mesajını değil, bilginin açığa çıkmadığını ve değişiklik yapılmadığını da denetlemelidir. Roller arasındaki farkları önceden belirlemek için web uygulamalarında yetkilendirme rehberinden yararlanabilirsiniz.
Sunucunun başvuruyu kaydettiğini, fakat yanıtın tarayıcıya ulaşmadığını da düşünün. Bağlantı hatası, kayıt oluşmadığını göstermez. Başvuru durumunu sorgulama veya aynı işlemi güvenle yeniden gönderme davranışı tanımlanmalı ve sınanmalıdır. Bildirim e-postası gönderilemezse başvuru geçerli kalacak mı, çalışan bundan nasıl haberdar olacak? Bunlar önce ürün kararıdır; güvenilir API entegrasyonu bu kararların teknik tarafını tamamlar.
Test sonucunu güvenilir hale getirin
Playwright, kullanıcının görebildiği sonuçların test edilmesini ve testlerin birbirinden bağımsız olmasını önerir. Kaynak: Playwright resmî iyi uygulamalar belgesi. Örneğimizde her çalıştırmaya ayırt edilebilir kurgusal başvurular ve hesaplar verin. Atölyenin kapanmasını sınayan test, önce başka bir testin atölyeyi oluşturmasına muhtaç kalmasın. Gerçek müşteri kayıtlarını deneme verisine taşımayın; temizlik işlemini yalnızca o çalışma için oluşturulan kayıtlarla sınırlandırın.
Playwright'ın web için asenkron doğrulamaları, koşul sağlanana veya ayarlanan süre dolana kadar yeniden kontrol eder; await ile beklenmeleri gerekir. Kaynak: doğrulamalar belgesi. Rastgele sabit süreler eklemek yerine başvurunun anlamlı bir duruma geçmesini bekleyin. Yalnızca ikinci çalıştırmada başarılı olan test incelenmelidir. Tekrar denemek, ilk hatanın nedenini açıklamaz.
Başarısızlığı yayın kararına bağlayın
Hangi sorunların yayını durduracağını önceden kararlaştırın. Bu örnekte başvuruların kaybolması, özel bilgilerin açığa çıkması ve yetkisiz güncellemeler açık adaylardır. Koşulları site yayın kontrol listesine ekleyin. İncelemeyi kimin yapacağı, düzeltme veya geri alma kararının nasıl verileceği belli olsun. Sayfa adresleri değişiyorsa ilgili kontrolleri URL taşıma planına da bağlayın.
- Her önemli yolculuk için açık başarı koşulu ve anlamlı bir ret senaryosu vardır.
- Test, bilinen kurgusal verilerle tek başına çalışabilir.
- Hata raporu ortamı, takılan adımı ve olası iş etkisini belirtir.
- Kaydedilen ekran görüntüleri ve günlüklerin erişim ve saklama kuralları bellidir.
- Ürün değiştiğinde testleri güncellemekten sorumlu kişi tanımlıdır.
Yeşil rapor sitenin kusursuz olduğunu gösterir mi? Yalnızca yazılmış senaryoların çalıştırıldıkları ortamda geçtiğini gösterir. Otomasyon bütün elle yapılan kontrolleri kaldırır mı? Metinlerin açıklığı, keşif amaçlı kullanım ve gerçek cihaz deneyimi yine değerlendirilmelidir. Önemli bir hatadan sonra, uygunsa tekrarlanmasını yakalayacak bir kontrol ekleyin ve bakımını site bakım ve güvenlik planına dahil edin. Test grubunu, desteklediği kararların niteliğiyle değerlendirin.
Yapay zekâ desteğiyle hazırlanmıştır; teknik kaynaklar doğrulama amacıyla listelenmiştir.