Ödeme formu test listesi: yayına almadan önce nelere bakılmalı?

Ödeme formu test listesi, bir e-ticaret akışını yayına almadan önce bakılması gereken durumları tek yerde toplar. Bu yazıda alan düzeyindeki denetimlerden iade ve ek doğrulama akışlarına kadar hangi senaryoların sınanması gerektiğini, hangi durumların üretimde denenmemesi gerektiğini ve test verinizi nasıl hazırlayacağınızı bulacaksınız.

Teste başlamadan önce neyi sabitlemelisiniz?

Testi dağınık yürütmenin en büyük bedeli, aynı hatayı iki kez bulmaktır. Bunu önlemek için üç şeyi baştan yazılı hâle getirin: hangi kart ağlarını desteklediğiniz, hangi para birimlerinde ve hangi ülkelerde ödeme aldığınız, hangi ödeme sağlayıcılarını kullandığınız. Bu üç liste, test kapsamınızın sınırlarını çizer.

İkinci hazırlık, ortamların ayrıldığından emin olmaktır. Test anahtarları üretim anahtarlarıyla karışırsa, farkında olmadan gerçek bir işlem başlatabilirsiniz. Bu tür kazalar genellikle panik anında, hızlı bir deneme yapmak isteyen bir geliştirici tarafından tetiklenir. Yapılandırmayı öyle kurun ki yanlış anahtarla çalışmak mümkün olmasın.

Üçüncü hazırlık, test verisidir. Kurgusal numaralardan oluşan küçük ve sabit bir set, bütün senaryoları yürütmek için yeterlidir. Bu numaraların hiçbiri gerçekte piyasaya sürülmemiştir ve hiçbir hesaba bağlı değildir; yalnızca biçim ve denetim kurallarına uydukları için geçerlidir.

Alan ve biçim denetimleri

Formun kendisiyle ilgili maddeler şunlardır:

• Boş gönderim: zorunlu alanlar boşken form gönderilebiliyor mu?
• Eksik numara: birkaç basamak eksik girildiğinde mesaj anlaşılır mı?
• Fazla uzunluk: alan sınırsız kabul ediyor mu, yoksa sessizce kırpıyor mu?
• Rakam dışı karakter: harf veya simge girildiğinde ne oluyor?
• Ayırıcılar: boşluklu ve tireli yapıştırma kabul ediliyor mu?
• Farklı uzunluklar: on beş ve on dokuz basamaklı numaralar doğru değerlendiriliyor mu?
• Son kullanma tarihi: geçmiş bir tarih reddediliyor mu, içinde bulunulan ay kabul ediliyor mu?
• Güvenlik kodu: kart ağına göre uzunluk uyarlanıyor mu?
• Kopyala yapıştır: alanlar yapıştırmayı engelliyor mu? Engelliyorsa bu bilinçli bir karar mı?
• Otomatik doldurma: tarayıcının önerisi alanları doğru dolduruyor mu?

Bu maddelerin çoğu tek bir oturumda, elle deneme yapılarak tamamlanır. Yapıştırmayı engellemek gibi kararlar kullanıcıyı doğrudan etkilediği için bilinçli verilmelidir.

Bu listeyi yalnızca bir kez değil, formda değişiklik yapılan her sürümde baştan işaretleyin. Küçük görünen bir düzenleme, örneğin alanların sırasını değiştirmek veya bir doğrulamayı kaldırmak, maddelerin bir kısmını geçersiz kılar. Değişikliğin hangi maddeleri etkilediğini not etmek, sonraki sürümlerde aynı yerleri yeniden keşfetmeyi önler.

Durum yönetimi: red, yeniden deneme ve iade

Alan denetimleri formun yüzeyidir; asıl zorluk işlemin durumlarındadır.

Tablodaki en kritik satır yeniden denemedir. Kullanıcı reddedilen bir ödemeden sonra tekrar denediğinde, sistemin aynı sipariş üzerinde çalışması gerekir. Her deneme için yeni bir sipariş açan bir kurgu, kısa sürede hayalet siparişlerle dolu bir panel bırakır.

Ek doğrulama ve dönüş akışı nasıl sınanır?

Banka, işlemi ek bir doğrulama adımına yönlendirdiğinde kullanıcı farklı bir sayfaya gider ve oradan geri döner. Bu dönüş, akışın en kolay kırılan yeridir.

Sınanması gereken üç sonuç vardır: kullanıcı doğrulamayı başarıyla tamamlar, kullanıcı doğrulamayı iptal eder, doğrulama sırasında bir hata oluşur. Üçünde de sipariş durumu tutarlı kalmalıdır. İptal edilen bir doğrulamadan sonra sipariş “beklemede” durumunda asılı kalmamalı; kullanıcı aynı sepetle yeniden deneyebilmelidir.

Dönüş adresinde tarayıcı sayfayı yenileyebilir. Bu durumda aynı işlem ikinci kez işlenmemelidir. Bunu test etmenin basit yolu, dönüş adresini doğrudan açmaktır; sistem aynı sonucu mu üretiyor, yoksa ikinci bir kayıt mı oluşuyor?

Bu akışı denemek için doğrulamayı tetikleyen bir test kartı kullanmanız gerekir; hangi numaranın hangi davranışı ürettiğini sağlayıcının kendi belgelerinden doğrulayın. Denemeyi farklı tarayıcılarda ve bir mobil cihazda tekrarlayın; dönüş adresinin nasıl açıldığı cihazdan cihaza değişebilir.

Aynı sorun, bir ödeme isteğinin iki kez gelmesi durumunda da ortaya çıkar ve ödeme sistemlerinde en pahalı hataların kaynağı burasıdır. Kullanıcı gönderme düğmesine iki kez basabilir, ağ isteği kendiliğinden tekrarlayabilir veya tarayıcı aynı isteği yeniden gönderebilir. Sistemin bu durumda iki ayrı ödeme oluşturmaması gerekir.

Çözüm, her ödeme isteğine kullanıcıya ve sepete bağlı bir anahtar vermek ve aynı anahtarla gelen ikinci isteği yeni bir işlem başlatmak yerine ilk işlemin sonucunu döndürmektir. Bu yaklaşımın çalıştığını görmek için test ortamında aynı isteği art arda iki kez gönderin ve ödeme kayıtlarını sayın. İkinci kayıt oluşuyorsa akışta bir boşluk var demektir.

Hangi durumlar üretimde denenmemeli?

Bazı senaryolar test ortamında kalmalıdır. Gerçek kartla deneme yapmak, gerçek bir siparişi iade etmek, canlı bir aboneliği iptal etmek ve gerçek müşteri verisiyle test etmek bunların başında gelir. Üretimde yalnızca izleme ve doğrulama yapılır; örneğin başarısız ödeme oranının beklenen aralıkta olduğunu görmek gibi.

Üretimde yapılan denemelerin bir başka riski, veri kirliliğidir. Gerçek sistemde oluşturulan sahte siparişler raporlara girer, stok kayıtlarını bozar ve muhasebe akışını etkiler. Bu kayıtları temizlemek, testi doğru yapmaktan çok daha fazla zaman alır.

Üretici ile test verinizi hazırlayın

Bu listenin maddelerini yürütmek için farklı ağlardan ve uzunluklardan numaralara ihtiyacınız olacak. Sitemizdeki sahte kredi kartı numarası üretici, kart ağını ve adedi seçerek test numarası üretir; her numarayı son kullanma tarihi ve güvenlik koduyla birlikte kopyalayabilirsiniz. Ürettiğiniz seti kaydedip listenin maddelerini tek tek işaretlemek, elle numara uydurmaktan hem hızlı hem de tekrarlanabilirdir. Araç bu adreste: test kredi kartı numarası üretici.

Üretilen numaralar yalnızca yapısal olarak geçerlidir ve hiçbiri gerçekte piyasaya sürülmemiştir; test ortamınızda saklanabilir, ancak gerçek bir ödeme için kullanılamaz.

Geliştiriciler için: durum matrisi ve tekrarlanabilirlik

Bu listeyi bir kontrol kâğıdı olarak değil, otomatik testlere bağlanacak bir durum matrisi olarak kurun. Satırlarda işlem durumları, sütunlarda beklenen sonuçlar yer alsın: sipariş oluştu mu, durum ne oldu, stok düştü mü, kullanıcıya hangi mesaj gitti. Her hücre en az bir testle eşleşsin.

İkinci kural, testlerin tekrarlanabilir olmasıdır. Aynı testi iki kez çalıştırdığınızda aynı sonucu görmüyorsanız, testin kendisi güvenilmezdir. Bunun en yaygın nedeni, testlerin sırayla çalışacağını varsaymasıdır; her test kendi verisini kurmalı ve kendi sonrasını temizlemelidir.

Üçüncü kural, hata yollarını başarı yolu kadar ciddiye almaktır. Reddedilen ödeme, zaman aşımı, iptal ve kısmi iade senaryoları, mutlu yoldan daha fazla kod yolu barındırır. Yalnızca onaylanan işlemi test eden bir set, gerçek trafikte ilk kez karşılaşacağınız hataları görmezden gelir.

Dördüncü kural, test verisini sürümle birlikte tutmaktır. Test setiniz kod deposunda yaşasın, değişiklikleri gözden geçirilsin ve kimin neden değiştirdiği görülebilsin. Böylece bir test kırıldığında, verinin mi koddan mı kaynaklandığını ayırt etmek kolaylaşır.

Sonraki adımlar

Yayına çıkmadan önce bu maddeleri bir kez baştan sona işaretlemeniz, çoğu sürprizi ortadan kaldırır. Tarih alanının ince ayrıntıları için kart son kullanma tarihi yazısına, sağlayıcı senaryoları için Stripe test kartları yazısına bakabilirsiniz. Test verisinin uyum boyutunu merak ediyorsanız PCI DSS ve test verisi yazısı hangi verinin test ortamında saklanabileceğini anlatıyor.