POS Testlerinde Decline Senaryoları Nasıl Test Edilmeli?

--

POS testlerinde çoğu zaman odak noktası başarılı işlemler olur.

Kart okutulur, şifre girilir, onay gelir, slip çıkar ve test tamamlanmış kabul edilir.

Oysa gerçek hayatta ödeme sistemlerinin en kritik davranışlarından biri, işlemin başarısız olduğu anlarda ortaya çıkar. Çünkü kullanıcı deneyimini, finansal güvenliği ve operasyonel doğruluğu çoğu zaman “onaylanan” işlemler değil, doğru yönetilen decline (red) senaryoları belirler.

Bir başka deyişle:

Ödeme sistemlerinde kalite, yalnızca işlemin geçtiği yerde değil; geçmediği yerde de test edilmelidir.

Decline (Red) Nedir?

Decline (red), kart işleminin issuer banka (kart sahibi banka) veya ilgili ödeme sistemi tarafından onaylanmaması durumudur.

Yani sistem şunu söyler:

“Bu işlem şu anda gerçekleştirilemez.”

Bu red cevabı farklı nedenlerle oluşabilir. Örneğin:

• yetersiz bakiye

• kart limitinin aşılması

• hatalı şifre

• kartın bloke olması

• şüpheli / riskli işlem

• kartın kullanım kurallarına uymayan bir senaryo

Buradaki önemli nokta şudur:

Her decline senaryosu aynı değildir.

Ve hepsi aynı şekilde test edilmemelidir.

Press enter or click to view image in full size

Neden Önemlidir?

Çünkü decline senaryoları yalnızca “işlem başarısız oldu” anlamına gelmez.

Aynı zamanda şu soruları da beraberinde getirir:

• POS ekranında doğru mesaj gösteriliyor mu?

• Kullanıcıya doğru yönlendirme yapılıyor mu?

• Slip çıkıyorsa doğru bilgi mi yazıyor?

• Backend tarafında gereksiz kayıt oluşuyor mu?

• Limit üzerinde yanlış blokaj bırakılıyor mu?

Bazı sistemlerde decline doğru dönse bile kullanıcı deneyimi yanlış olabilir.

Bazılarında ise ekran doğru görünür ama arka planda tutarsız kayıtlar oluşabilir.

Bu yüzden decline testleri yalnızca response code kontrolüyle sınırlı kalmamalıdır.

Decline Türleri Nelerdir?

Pratikte decline senaryolarını birkaç ana gruba ayırmak mümkündür.

1. Finansal Decline (Finansal Red)

Kartta yeterli bakiye veya limit yoktur.

Örnek:

• Insufficient Funds (yetersiz bakiye)

• Exceeds Withdrawal / Spending Limit (çekim / harcama limit aşımı)

Bu senaryolarda kontrol edilmesi gereken şey yalnızca red cevabı değil, aynı zamanda kullanıcının ne gördüğüdür.

Örneğin kullanıcı “İşlem reddedildi” yerine “Yetersiz bakiye” gibi daha açıklayıcı bir mesaj görebiliyor mu?

2. Güvenlik / Risk Decline (Güvenlik / Risk Reddi)

İşlem fraud (sahtecilik) şüphesiyle reddedilir.

Örnek:

• Suspected Fraud (şüpheli işlem / sahtecilik şüphesi)

• Restricted Card (kısıtlı kart)

• Security Violation (güvenlik ihlali)

Bu tür senaryolarda çoğu zaman kullanıcıya gerçek sebep olduğu gibi gösterilmez. Çünkü güvenlik gereği daha genel mesajlar tercih edilir.

QA açısından burada önemli olan, hem response code’un doğru olması hem de müşteri ekranındaki mesajın iş kurallarına uygun gösterilmesidir.

3. Kart / Hesap Durumu Kaynaklı Decline

Kartın kendisiyle ilgili bir sorun vardır.

Örnek:

• Expired Card (süresi dolmuş kart)

• Invalid Card (geçersiz kart)

• Lost / Stolen Card (kayıp / çalıntı kart)

• Blocked Card (bloke kart)

Bu senaryolarda test yalnızca POS ekranıyla bitmez. Kart durumuna göre slip çıktısı, log kaydı ve backend davranışı da kontrol edilmelidir.

4. Teknik / Operasyonel Decline

İşlem teknik bir kural veya operasyonel nedenle reddedilir.

Örnek:

• Invalid Transaction (geçersiz işlem)

• Format Error (biçim / format hatası)

• Function Not Supported (desteklenmeyen işlem / fonksiyon)

• Transaction Not Permitted (işleme izin verilmedi)

Bu decline türleri çoğu zaman son kullanıcıdan çok sistemin kendi iç kurallarını ilgilendirir. Ama QA için çok değerlidir çünkü entegrasyon kalitesini gösterir.

Press enter or click to view image in full size

QA Perspektifinden Nasıl Test Edilmeli?

Decline senaryolarını test ederken şu katmanlar birlikte değerlendirilmelidir:

1. Response Code Kontrolü

İlk kontrol her zaman sistemin döndüğü teknik cevaptır.

• Doğru decline code dönüyor mu?

• Beklenen senaryoyla eşleşiyor mu?

• Farklı decline sebepleri birbirine karışıyor mu?

Bu aşama önemlidir ama tek başına yeterli değildir.

2. POS Ekran Davranışı

Kullanıcı decline aldığında ne görüyor?

• Mesaj açık mı?

• Fazla teknik mi?

• Yanıltıcı mı?

• İş kuralına uygun mu?

Örneğin fraud decline (sahtecilik şüphesi nedeniyle red) için kullanıcıya çok detaylı bir açıklama göstermek istenmeyebilir. Bu durumda ekran mesajı ile teknik response code farklı seviyelerde ele alınmalıdır.

3. Slip ve Raporlama Kontrolü

Bazı decline senaryolarında slip çıkar, bazılarında çıkmaz. Çıktığı durumlarda ise içerik önemlidir.

Kontrol edilmesi gerekenler:

• Slip çıkıyor mu?

• Mesaj doğru mu?

• Tutar bilgisi doğru mu?

• Rapor ekranlarında işlem doğru statüyle görünüyor mu?

4. Backend ve Finansal Etki

Decline senaryosunda en kritik sorulardan biri şudur:

İşlem reddedildi ama sistem arka planda gerçekten temiz kaldı mı?

Burada QA’in dikkat etmesi gereken noktalar:

• gereksiz authorization (yetkilendirme / provizyon) kaydı oluştu mu?

• limit üzerinde yanlış blokaj kaldı mı?

• ledger / muhasebe kaydı oluştu mu?

• retry (yeniden deneme) veya duplicate (mükerrer / tekrarlı işlem) riskine açık bir durum var mı?

Özellikle timeout (zaman aşımı) veya belirsiz cevaplarla birleşen decline senaryolarında bu kontrol daha da kritik hale gelir.

Press enter or click to view image in full size

Neden Regression Testlerinde Atlanır?

Çünkü; decline senaryoları çoğu zaman “negatif test” başlığı altında toplanır ve dar kapsamda ele alınır.

Genellikle şu hatalar yapılır:

• sadece tek bir decline code test edilir

• tüm decline’lar aynı davranıyormuş gibi düşünülür

• POS ekranı kontrol edilir ama backend kontrol edilmez

• gerçek hayatta sık yaşanan fraud (sahtecilik) / timeout (zaman aşımı) birleşimleri test edilmez

Oysa production (canlı ortam) tarafında kullanıcıların en çok karşılaştığı ödeme problemleri çoğu zaman bu alanlardan çıkar.

Pratik Test Yaklaşımı Nasıl Olmalı?

Daha sürdürülebilir bir decline test yaklaşımı için şu yapı kullanılabilir:

1. Decline sebebini net tanımla

2. Beklenen response code’u belirle

3. POS ekran mesajını doğrula

4. Slip / rapor davranışını kontrol et

5. Backend ve finansal etkiyi incele

6. Gerekirse retry (yeniden deneme) akışını test et

Bu yapı decline testlerini yalnızca “red aldı mı?” seviyesinden çıkarır ve gerçek ödeme kalitesine yaklaştırır.

Sonuç

POS testlerinde decline (red) senaryoları, başarılı işlemler kadar önemlidir.

Hatta bazı durumlarda daha da önemlidir.

Çünkü ödeme sistemlerinde güven, yalnızca işlemin geçtiği anda değil; geçmediği anda da korunmalıdır.

Bu yüzden decline testlerinde asıl soru şu olmalıdır:

İşlem reddedildi mi değil, doğru şekilde mi reddedildi?

Ödeme sistemleri tarafında kalite çoğu zaman başarılı işlemlerden değil, başarısız işlemlerin doğru yönetilmesinden anlaşılır.