Adres formu testleri, ödeme adımında kullanıcıyı en çok kaybettiren alanların başında gelir; çünkü buradaki tek bir hata satışı bitirir. Bu yazıda hangi senaryoları kapsamanız gerektiğini, ülkeye göre değişen zorunlu alanların nasıl ele alınacağını, hata mesajlarının nasıl sınanacağını ve kaydın gönderim sonrası nasıl korunması gerektiğini bulacaksınız.
Form neden kullanıcı kaybettiren bir adım olur?
Ödeme adımı, kullanıcının artık kararını verdiği yerdir. Bu adımda karşılaştığı her engel, satın alma isteğini zayıflatır. Gereksiz bir zorunlu alan, anlaşılmaz bir hata mesajı ya da kaybolan bir girdi, kullanıcının sekmeyi kapatması için yeterlidir.
Adres formu bu yüzden diğer formlardan farklı değerlendirilmelidir. Kayıt formunda katlanılabilen bir sürtünme, ödeme adımında doğrudan gelir kaybına dönüşür. Testlerin amacı da bu sürtünmeyi ölçmektir: kullanıcı hangi noktada duruyor ve neden duruyor?
İkinci neden, verinin kalitesidir. Kullanıcı hızlı geçmek için alanları uydurma değerlerle doldurur. Formun bunu hem engellemesi hem de mümkün olduğunca az soru sorması gerekir. Bu denge, ancak senaryoların bilinçli seçilmesiyle kurulur.
Hangi senaryolar mutlaka sınanmalı?
Test kümesini üç eksende kurmak yeterlidir: ülke, alan zorunluluğu ve kullanıcı davranışı. Aşağıdaki tablo, bu eksenlerden doğan temel senaryoları özetler:
| Senaryo | Ne sınar |
|---|---|
| En kısa mutlu yol | Yalnızca zorunlu alanlarla tamamlanan form |
| Ülke değişimi | Alan kümesinin ve etiketlerin yeniden düzenlenmesi |
| Posta kodu olmayan ülke | Alanın gizlenmesi veya boş kabul edilmesi |
| Çok uzun sokak satırı | Alan sınırı ve kesme davranışı |
| Latin dışı yazı | Karakter desteği ve gösterim |
| Geri dönüş | Hata sonrası girilen değerlerin korunması |
Bu senaryoların her biri, tek bir ülkeyle değil, birbirinden farklı en az üç ülkeyle çalıştırılmalıdır. Ülkeler arasından biçim olarak ayrışan örnekleri seçmek, kapsamı genişletir. Yalnızca tek bir ülkeyle yapılan testler, ülkeye bağlı kod yollarının çoğunu hiç çalıştırmaz.
Bir de olumsuz senaryolar vardır: alanı boş bırakmak, yalnızca boşluk girmek, çok uzun bir metin yapıştırmak ve özel karakterler kullanmak. Bu dört davranış, doğrulamanın gerçekten çalıştığını gösterir. Yalnızca mutlu yolu sınamak, formun doğru çalıştığı izlenimini verir ama hiçbir sınırı test etmez.
Ülkeye göre alanlar nasıl değişmeli?
Ülke seçimi, formun merkezindeki karardır. Kullanıcı ülkeyi değiştirdiğinde alanlar da değişmelidir: bazı alanlar zorunlu hale gelir, bazıları isteğe bağlı olur, bazıları gizlenir. Posta kodu sistemi olmayan bir ülkede bu alanı zorunlu tutmak, kullanıcıyı uydurma bir değer girmeye iter.
Bu davranışın test edilmesi gereken bir ayrıntısı vardır: ülke değiştiğinde önceden girilmiş değerler ne olacak? Şehir alanı temizlenmeli mi, yoksa kullanıcı yeni ülkeye uygun biçimde düzeltmeli mi? İki davranış da savunulabilir, ama ikisinin karışması kullanıcıyı şaşırtır. Testler bu kararı açıkça sınamalıdır.
Etiketler de ülkeye göre değişmelidir. Bir ülkede idari bölüm anlamına gelen alan, başka bir ülkede farklı bir adla anılır. Etiketin sabit kalması, kullanıcının hangi bilgiyi girmesi gerektiğini anlamamasına yol açar. Test kümesinde her etiketin doğru ülkeyle eşleştiğini kontrol eden en az bir senaryo bulunmalıdır.
Hata mesajları nasıl sınanır?
Hata mesajı, kullanıcının formdan vazgeçmesini engelleyen en önemli araçtır. İyi bir mesaj üç şeyi söyler: hangi alan sorunlu, neden sorunlu ve ne yapılması gerekiyor. Bu üçünü söylemeyen bir mesaj, kullanıcıyı deneme yanılmaya bırakır.
Testlerde mesajın içeriği kadar zamanlaması da kontrol edilmelidir. Hata, kullanıcı alandan ayrıldığında mı yoksa gönderim sırasında mı görünüyor? Tarayıcıda mı, sunucuda mı üretiliyor? Aynı hata iki katmanda farklı metinlerle görünüyorsa, kullanıcı hangisine güveneceğini bilemez.
Mesajın erişilebilirliği de sınanmalıdır. Hata metni yalnızca renkle anlatılmamalı, ekran okuyucular tarafından duyurulmalı ve ilgili alanla ilişkilendirilmelidir. Bu, testlerde en sık atlanan başlıktır; oysa erişilebilirlik hataları doğrudan kullanıcı kaybına yol açar.
Ayrıca mesajın dili kullanıcının seçtiği dile uygun olmalıdır. Bir alanda Türkçe, başka bir alanda başka bir dil görünmesi, formun güvenilirliğini zedeler. Çok dilli bir üründe bu, ayrı bir test başlığıdır.
Kaydetme ve geri dönüş davranışı neden önemli?
Kullanıcı formu doldurup gönderdiğinde bir hata alırsa, girdiği değerlerin korunması gerekir. Kaybolan bir adres, kullanıcının her şeyi baştan yazması anlamına gelir ve çoğu kullanıcı bu noktada vazgeçer. Testler, hata sonrası sayfanın yeniden yüklendiği her durumda değerlerin korunduğunu doğrulamalıdır.
Tarayıcı otomatik doldurma davranışı da test edilmelidir. Adres alanları, tarayıcının ve işletim sisteminin en çok tanıdığı alanlardır. Otomatik doldurmanın alanları doğru eşleştirmesi, kullanıcı için büyük bir kolaylıktır; yanlış eşleştirme ise sessiz bir hata üretir. Alanların amacını makineye doğru anlatan işaretler kullanmak bu sorunu büyük ölçüde çözer.
Verinin nereye kaydedildiği de bir test konusudur. Adres, yalnızca sipariş kaydına mı yazılıyor, yoksa kullanıcının hesabına da ekleniyor mu? İkinci durumda kullanıcının onayı alınmalı ve kayıt sonradan düzenlenebilmelidir. Beklenmeyen bir kayıt, gizlilik açısından da sorun yaratır.
Geliştiriciler için: testleri otomatikleştirme ve veri
Bu senaryoların çoğu otomatik testlere uygundur. Ülke seçimi, alan zorunluluğu ve hata mesajı gibi davranışlar, sabit veriyle tekrar tekrar çalıştırılabilir. Otomatikleştirilemeyen kısım ise görsel düzendir: alan sırası, etiket yerleşimi ve mobil görünüm. Bu ikisini ayrı test başlıkları olarak ele almak, kapsamı netleştirir.
Sabit veri kümenizi ülke bazında kurun ve her senaryo için ayrı bir kayıt tutun. Kurgusal adres kullanmak, testlerin hem tekrarlanabilir olmasını hem de gerçek kişisel veriyi test ortamına taşımamayı sağlar. Bu veriler yalnızca yazılım testi içindir; gerçek gönderi veya ikamet kanıtı olarak kullanılamaz. Kayıtları nasıl gruplayacağınızı ve adlandıracağınızı test verisinde adres kayıtları yazısında ayrıntılı olarak anlatıyoruz.
Test verisini üretirken, aynı kaydın hem formu dolduran hem de sonucu doğrulayan tarafta kullanılmasına dikkat edin. Beklenen değeri testin içinde elle yazmak yerine veri dosyasından okumak, kaydı güncellediğinizde testin kendiliğinden uyum sağlamasını sağlar. Böylece veri ile beklenti arasındaki sessiz kayma önlenir.
Doğrulamayı istemci ve sunucu tarafında ayrı ayrı sınayın. Tarayıcıdaki kontrol kullanıcıya hızlı geri bildirim verir, sunucudaki kontrol ise verinin gerçekten korunduğunu garanti eder. Yalnızca birini test etmek, diğerinin sessizce bozulmasına izin verir.
Sunucudan dönen hata kodlarını test verisiyle eşleştirin. Her hata kodunun kullanıcıya gösterilen bir karşılığı olmalı ve bu karşılık sabit kalmalıdır. Böylece metin değiştiğinde testler kırılır ve beklenmeyen bir değişiklik erken fark edilir.
Sonraki adımlar
Ödeme adımındaki formu sınarken üç ülkeyi, bir olumsuz senaryoyu ve bir geri dönüş senaryosunu birlikte çalıştırın; bu küçük küme, formun en kritik davranışlarını kapsar. Kurgusal kayıt üretmek için adres üretici sayfasından ülke bazında örnek alabilir, doğrulamanın hangi düzeyde tutulacağını ise adres doğrulama ve normalleştirme yazısından okuyabilirsiniz.