Çoğu kişi tedarikçi entegrasyonunu şöyle bitirdiğini sanır: API anahtarını girdi, test siparişi geçti, kod geldi, tamam. Oysa bir entegrasyonun gerçek sınavı başarılı senaryoda değil, başarısız senaryoda verdiği tepkidir. Kod geldiğinde herkes mutludur; kod gelmediğinde sistemin ne yaptığı ise doğrudan senin kasandan ödenir.
Bu yüzden test etmek, birkaç deneme siparişi geçmek değil bir protokol yürütmektir. Hangi hata kodları var, zaman aşımında ne dönüyor, aynı referansla iki kez istek atınca ne oluyor, sandbox ile canlı davranış arasında hangi farklar var? Bu yazıda bir e-pin satış scripti devreye alınmadan önce yürütülmesi gereken test adımlarını, sandbox kullanımının sınırlarını ve canlı geçişte hangi kontrollerin kalıcı olarak açık kalması gerektiğini anlatıyorum.
Sandbox neden canlının aynısı değildir?
Sandbox ortamı sana iki şeyi doğru öğretir: istek/yanıt formatı ve kimlik doğrulama akışı. Üçüncü bir şeyi ise neredeyse hiç öğretmez: gerçek yük altında davranış. Sandbox'ta yanıt süresi 200 milisaniyedir, canlıda kampanya saatinde 8 saniyeye çıkar. Sandbox'ta stok sonsuzdur, canlıda biter. Sandbox'ta hata kodları düzgün döner, canlıda bazen boş gövdeli 200 alırsın.
Bu yüzden sandbox testini bitiş çizgisi değil başlangıç çizgisi saymak gerekir. Sandbox'ta doğrulanacak şey kontrat uyumudur: alanlar doğru mu, imza doğru hesaplanıyor mu, para birimi ve ondalık biçimi bekleneni mi veriyor. Bu katman geçildikten sonra sıra gerçek davranışa gelir. İyi bir e-pin yazılımı her tedarikçi için ayrı ortam tanımı tutar; böylece sandbox anahtarıyla canlı anahtar asla aynı kutuya girmez.
Minimum test matrisi hangi senaryoları kapsar?
Test matrisi yazılı olmak zorundadır, çünkü akılda tutulan test listesi her zaman mutlu yola daralır. Aşağıdaki on iki senaryo, entegrasyon kaynaklı vakaların büyük kısmını canlıya çıkmadan yakalar. Her senaryo için beklenen davranışı önce sen yaz, sonra sistemin gerçekte ne yaptığına bak. İkisi arasındaki her fark bir hatadır, isterse sistem "çalışıyor" görünsün.
| Senaryo | Nasıl tetiklenir | Beklenen davranış |
|---|---|---|
| Başarılı sipariş | Geçerli ürün, yeterli bakiye | Kod teslim, sipariş kapalı |
| Yetersiz bakiye | Bakiyeyi sipariş altına düşür | Alternatif tedarikçiye yönlendirme |
| Stok yok | Stoksuz ürün kodu gönder | Ürünü geçici pasife al |
| Geçersiz ürün kodu | Eşleşmeyen kod gönder | Eşleştirme hatası logu, sipariş bekletme |
| Zaman aşımı | Süre sınırını 1 sn'ye indir | Durum sorgusu, retry yok |
| Aynı referansla ikinci istek | İsteği iki kez gönder | Tek teslimat, ikinci istek yok sayılır |
| Yanlış imza / anahtar | Anahtarın son karakterini boz | Kritik alarm, tedarikçi kilitle |
| Boş gövdeli 200 | Yanıtı mock ile boşalt | Başarı sayılmaz, doğrulamaya düşer |
| Kısmi teslimat | 3 adetlik siparişte 2 kod dön | Eksik adet kuyruğa, müşteri bilgilendirme |
| Kur değişimi | Alış kurunu %10 oynat | Marj eşiği kontrolü devreye girer |
| İade / iptal | Teslim sonrası iptal isteği | Bakiye iadesi, kod geçersizleştirme |
| Eşzamanlı 20 sipariş | Paralel istek gönder | Rezerve bakiye çalışır, çift kod yok |
Idempotency testini atlarsan hangi fatura gelir?
Idempotency, aynı isteği iki kez göndermenin tek bir sonuç üretmesidir. Test edilmediğinde ortaya çıkan tablo şudur: müşteri ödeme sayfasında yenile tuşuna bastı, iki sipariş oluştu, iki kod tedarikçiden düştü, biri müşteriye gitti, diğeri kayıp. Zarar tedarikçi alış maliyeti kadardır ve bu tür kayıplar genellikle ay sonunda mutabakatta fark edilir.
Testi yapmak ise beş dakika sürer: aynı referans numarasıyla iki istek gönder, tedarikçinin ikincisine ne dediğine bak. Bazı tedarikçiler ikinci isteği reddeder, bazıları aynı kodu tekrar döner, bazıları yeni bir sipariş açar. Üçüncü davranışı gösteren tedarikçide referans kontrolünü kendi tarafında yapmak zorundasın. Dijital ürün satış yazılımı seçerken sorulacak net soru şudur: sipariş referansı tekilliği veritabanı seviyesinde mi garanti ediliyor, yoksa sadece uygulama kodunda mı?
Canlıya çıkış sonrası ilk ay hatalarının kaynağı
- Test edilmemiş hata senaryoları 40%
- Sandbox-canlı davranış farkı 30%
- Idempotency eksikliği 20%
- Yanlış ortam anahtarı 10%
Gölge mod nedir ve canlı riskini nasıl düşürür?
Sandbox ile canlı arasında çok az kişinin kullandığı bir ara aşama var: gölge mod. Burada gerçek siparişler mevcut çalışan akışla teslim edilmeye devam eder, ama yeni entegrasyon aynı isteği paralel olarak sadece doğrulama amaçlı çalıştırır ve sonucu loglar. Müşteriye hiçbir şey gitmez; sen ise gerçek trafikle yeni entegrasyonun nasıl davrandığını görürsün.
Gölge modun kazandırdığı şey istatistiktir. Bir hafta sonunda elinde gerçek yanıt süresi dağılımı, gerçek hata kodu frekansı ve gerçek stok sapması olur. Bu veriyle canlıya geçiş kararı tahmin değil ölçüm olur. Ardından kademeli açılış gelir: trafiğin %10'u, sonra %30'u, sonra tamamı. Bir epin yazılım altyapısında yönlendirme ağırlıkları panelden ayarlanabiliyorsa bu kademeli geçiş tek bir alan değiştirilerek yapılabilir.
Canlıya geçtikten sonra hangi testler kapanmaz?
Entegrasyon testi bir kerelik iş değildir; tedarikçi habersiz değişiklik yapar, alan adı taşır, hata kodu ekler. Bu yüzden bazı testler canlıda sürekli açık kalmalı. En önemlisi sağlık yoklaması: düzenli aralıkla minimum tutarlı bir sorgu isteği atıp yanıt süresini ve dönen yapıyı kaydetmek. İkincisi kontrat doğrulama: beklenen alanlar yanıtta hâlâ var mı, tip değişmiş mi.
Üçüncüsü sessiz bozulma kontrolü: başarı oranı düşmediği halde ortalama teslim süresi yükseliyorsa bu bir uyarıdır. Dördüncüsü ise ortam ayrımı kontrolü; canlı ortamda sandbox anahtarıyla yapılmış tek bir istek bile kataloğunda hayali stok yaratabilir. Bu dört kontrol açıksa entegrasyon bozulduğunda bunu müşteriden değil sistemden öğrenirsin.
| Sürekli kontrol | Sıklık | Alarm koşulu | Durum |
|---|---|---|---|
| Sağlık yoklaması (bakiye/stok sorgusu) | 5 dakika | 3 üst üste hata | Zorunlu |
| Kontrat doğrulama (alan/tip) | Günlük | Beklenen alan eksik | Zorunlu |
| Teslim süresi eğilimi | Saatlik | Ortalama 2 katına çıkması | Önerilir |
| Ortam anahtarı ayrımı | Her dağıtımda | Canlıda test anahtarı | Zorunlu |
| Idempotency örneklemesi | Haftalık | Çift kayıt tespiti | Önerilir |
Test kayıtlarını normal siparişlerle aynı havuzda bırakmak, ciro ve marj raporlarını kalıcı olarak bozar. Her test siparişine ayrı bir kaynak etiketi ver ve raporlarda varsayılan olarak dışla; ama silme, çünkü hata analizinde en çok o kayıtlara bakacaksın.
Entegrasyonu tahminle değil protokolle aç
Pinova; tedarikçi başına ortam ayrımı, referans tekilliği, sağlık yoklaması ve yönlendirme ağırlıklarıyla kademeli canlı geçişi standart hale getirir.
Tedarikçi sandbox vermiyorsa nasıl test edilir?
Bu durumda en küçük tutarlı gerçek ürünle canlı üzerinde sınırlı test yapılır ve hata senaryoları yerel mock ile simüle edilir. Mock, tedarikçinin dokümandaki hata kodlarını birebir döndürecek şekilde kurulmalıdır.
Kaç test siparişi yeterlidir?
Sayı değil kapsam belirleyicidir. On iki senaryonun her biri en az bir kez çalıştırılmışsa yeterlidir; aynı mutlu yolu elli kez denemek hiçbir yeni bilgi vermez.
Zaman aşımı süresi kaç saniye olmalı?
Tedarikçinin gerçek yanıt süresi dağılımına bakılır ve üst dilimin biraz üstü seçilir; çoğu tedarikçide 10-15 saniye makuldür. Çok kısa süre gereksiz failover, çok uzun süre bekleyen müşteri üretir.
Gölge mod canlı bakiyeyi harcar mı?
Doğru kurulduğunda harcamaz, çünkü gölge modda yalnızca sorgu ve doğrulama çağrıları yapılır; satın alma isteği gönderilmez. Satın alma da denenecekse bu ayrı ve bütçesi sınırlı bir test turudur.
Test matrisini kâğıt üzerinde görmek bir başlangıç; hangi senaryonun panelde hangi ekrana düştüğünü görmek işi bitirir. Sipariş logu, hata kodu geçmişi ve tedarikçi sağlık göstergesinin gerçek görünümü için canlı demo üzerinden entegrasyon ekranlarını incele, sonra kendi tedarikçi listen için bu on iki senaryoyu tek tek işaretle.