İçeriğe atla

Pazaryeri Uçtan Uca Nasıl Test Edilir ve Pilot Yayına Alınır?

Ders 9 / 10 · 30 dakika okuma · İleri

Satıcı başvurusundan katalog, çok satıcılı ödeme, kargo, iade ve hakedişe kadar tüm pazaryeri döngüsünü E2E test ederek kontrollü pilot yayın ve Go/No-Go planı oluşturmayı öğrenin.

Bu Derste Öğrenecekleriniz

  • Pazaryeri için ölçülebilir Go-Live kriterleri ve gerçekçi test verisi hazırlayabilir.
  • Satıcı, katalog, ödeme, kargo, iade ve hakediş akışlarını uçtan uca test edebilir.
  • Yetki, idempotency, entegrasyon kesintisi ve finansal istisna testleri oluşturabilir.
  • Pilot satıcı, kategori ve trafik kapsamını kontrollü biçimde planlayabilir.
  • Go/No-Go ve rollback karar çerçevesi oluşturabilir.

Pazaryeri Yayına Alınmaz; Önce Uçtan Uca Kanıtlanır

Bir pazaryerinde ayrı ayrı çalışan ekranlar, gerçek ticari döngünün çalıştığını kanıtlamaz. Satıcı başvurusundan müşterinin siparişine, ödemeden kargoya, iadeden hakedişe kadar birbirine bağlı süreçler gerçekçi senaryolarla birlikte test edilmelidir.

Pilot yayın, eksik bir sistemi müşteriye açmak değildir. Sınırlı satıcı, kategori ve trafikle canlı koşullarda kontrollü doğrulama yapmaktır.

Not — Temel ilke

Test planı menülere göre değil iş akışlarına göre hazırlanmalıdır. 'Ödeme ekranı çalışıyor' yerine 'iki satıcılı sipariş başarıyla tahsil edildi, alt siparişlere ayrıldı, kargolandı ve doğru hakediş oluştu' test edilir.

1. Yayın Kriterlerini Testten Önce Yazın

  • Kritik kullanıcı akışları PASS.
  • Açık P1/kritik hata yok.
  • Ödeme ve refund mutabakatı doğru.
  • Satıcı alt sipariş ayrıştırması doğru.
  • Kargo ve takip çalışıyor.
  • Hakediş hesapları doğrulandı.
  • Yetki ve veri izolasyonu test edildi.
  • Destek/istisna kuyrukları hazır.
  • Pilot satıcılar operasyonu tamamlayabiliyor.

Go/No-Go kararı test sonucuna göre verilmelidir; takvim baskısı kriterlerin yerini almamalıdır.

2. Test Ortamları ve Veri

Test için üretime benzeyen kategori, ürün, satıcı, varyant, fiyat, stok ve adres verileri hazırlayın.

  • En az iki satıcı.
  • Farklı komisyon oranları.
  • Farklı kargo koşulları.
  • Varyantlı ürün.
  • Stok sınırı olan ürün.
  • İndirimli ürün.
  • Farklı kullanıcı rolleri.
  • İade/refund senaryosu.

Gerçek kişisel veya ödeme verilerini gereksiz biçimde test ortamına taşımayın.

3. Test Hesapları

  • Müşteri.
  • Satıcı A yöneticisi.
  • Satıcı A katalog kullanıcısı.
  • Satıcı B yöneticisi.
  • Admin operasyon.
  • Admin finans.
  • Destek kullanıcısı.

Yetki testleri için farklı roller zorunludur.

4. Satıcı Başvuru E2E Testi

  1. Yeni satıcı hesap açar.
  2. İletişimini doğrular.
  3. İşletme bilgilerini tamamlar.
  4. Gerekli kabul ve bilgileri verir.
  5. Admin incelemeye alır.
  6. Düzeltme ister.
  7. Satıcı düzeltir.
  8. Admin onaylar.
  9. Satıcı mağaza/hakediş/kargo kurulumunu tamamlar.
  10. Satışa hazır statüsüne geçer.

5. Katalog E2E Testi

  1. Satıcı kategori seçer.
  2. Ürün ekler veya ortak ürüne eşleşir.
  3. Varyant oluşturur.
  4. Fiyat/stok girer.
  5. Moderasyona gönderir.
  6. Admin düzeltme ister veya onaylar.
  7. Ürün yayına çıkar.
  8. Arama ve filtrede bulunur.
  9. Ürün sayfasında doğru satıcı teklifi görünür.

6. Çok Satıcılı Satın Alma Testi

  1. Müşteri Satıcı A'dan ürün ekler.
  2. Satıcı B'den ürün ekler.
  3. Sepet satıcı gruplarını doğru gösterir.
  4. Kargo tutarları hesaplanır.
  5. Ödeme başlatılır.
  6. Ödeme doğrulanır.
  7. Tek ana sipariş oluşur.
  8. İki satıcı alt siparişi oluşur.
  9. Her satıcı yalnız kendi kalemini görür.
  10. Finansal snapshot doğru oluşur.

7. Stok Yarışı Testi

Son bir adet ürünü iki müşteri aynı anda almaya çalıştığında overselling davranışını test edin.

  • Rezervasyon zamanı.
  • Ödeme başarısızsa stok serbest bırakma.
  • Başarılı siparişin önceliği.
  • Müşteriye anlaşılır hata.

8. Fiyat Değişimi Testi

Ürün sepetteyken satıcı fiyatı değiştirirse checkout öncesi nihai fiyat doğrulaması yapılmalıdır.

Müşteriden ekranda onaylamadığı farklı tutar tahsil edilmemelidir.

9. Ödeme Başarı Testleri

  • Normal başarılı ödeme.
  • Ek doğrulamalı ödeme varsa.
  • Callback gecikmesi.
  • Callback tekrar gönderimi.
  • Tarayıcı dönüşü yok fakat sağlayıcı başarılı.
  • Sağlayıcı başarılı, yerel sipariş adımı geçici hata.

Her senaryoda finansal kayıt ve müşteri siparişi tutarlı olmalıdır.

10. Ödeme Başarısızlık Testleri

  • Kart/ödeme reddi.
  • Doğrulama başarısız.
  • Timeout.
  • Sağlayıcı teknik hata.
  • Müşteri sayfayı kapattı.
  • Yeniden ödeme denemesi.

Başarısız girişim çift sipariş veya kalıcı stok rezervasyonu oluşturmamalıdır.

11. Idempotency Testi

Aynı callback, refund isteği veya kargo olayı iki kez gönderildiğinde finansal ve operasyonel kayıtlar çoğalmamalıdır.

Örnek — Beklenen sonuç

Aynı ödeme bildirimi 3 kez işlense bile tek başarılı payment sonucu, tek sipariş kesinleştirme ve tek komisyon hareketi bulunur.

12. Kargo E2E Testi

  1. Satıcı siparişi hazırlar.
  2. Kargo etiketi üretir.
  3. Takip numarası oluşur.
  4. Müşteri bilgilendirilir.
  5. Taşıyıcı durumları gelir.
  6. Teslimat tamamlanır.
  7. Sipariş ve hakediş olayı doğru ilerler.

13. Çoklu Paket Testi

Aynı siparişte iki paket oluşturun. Her paketin doğru ürün/adetleri taşıdığını ve müşterinin ayrı takip numaralarını gördüğünü doğrulayın.

14. İade ve Refund E2E Testi

  1. Müşteri tek kalem için iade açar.
  2. Uygunluk kontrol edilir.
  3. İade kargosu oluşturulur.
  4. Satıcı ürünü teslim alır.
  5. Sonuç kaydedilir.
  6. Refund doğru tutarda çalışır.
  7. Komisyon/hakediş ters kaydı oluşur.
  8. Ekstre ve müşteri durumu güncellenir.

15. Hakediş Testi

Siparişten payout'a kadar hesaplamayı bağımsız kontrol tablosuyla karşılaştırın.

  • Brüt ürün tutarı.
  • İndirim dağılımı.
  • Komisyon matrahı.
  • Komisyon.
  • Kargo/servis kalemi.
  • İade/mahsup.
  • Net satıcı alacağı.
  • Ödeme durumu.

16. Hakediş Sonrası İade Testi

Satıcıya ödeme yapıldıktan sonra iade oluşturun. Sistem geçmiş ödemeyi silmeden doğru ters kayıt veya mahsup üretmelidir.

17. Yetki ve Veri İzolasyonu Testi

  1. Satıcı A, Satıcı B sipariş URL'sine doğrudan erişmeyi dener.
  2. Katalog kullanıcısı finans ekranına erişmeyi dener.
  3. Destek kullanıcısı hakediş hesabını değiştirmeyi dener.
  4. Satıcı başka müşterinin verisini sorgulamayı dener.
  5. Yetkisiz admin aksiyonu API seviyesinde denenir.

Yalnız menüyü gizlemek yetki kontrolü değildir. Sunucu/servis katmanı yetkiyi uygulamalıdır.

18. Kritik Hesap Güvenliği Testleri

  • Parola sıfırlama.
  • Oturum sonlandırma.
  • Kritik bilgi değişikliği.
  • Rol değişikliği.
  • Hakediş hesabı değişikliği.
  • Tekrarlanan başarısız girişim/risk kontrolleri.

Güvenlik test kapsamı sistem riskine göre profesyonel güvenlik incelemesiyle genişletilebilir.

19. Entegrasyon Kesinti Testleri

  • Ödeme sağlayıcısı ulaşılamıyor.
  • Kargo API'si hata veriyor.
  • ERP stok servisi gecikiyor.
  • E-posta/SMS servisi çalışmıyor.
  • Webhook gecikiyor.

Her kesintide sistemin veri kaybetmeden nasıl davranacağı ve manuel yedek süreç tanımlı olmalıdır.

20. Performans ve Yük Testi

Beklenen trafik, eşzamanlı checkout ve katalog hacmine göre kritik endpoint ve iş kuyruklarını test edin.

  • Ürün listeleme/arama.
  • Sepet.
  • Checkout.
  • Ödeme callback.
  • Sipariş oluşturma.
  • Satıcı sipariş listesi.
  • Admin kritik kuyrukları.

Tek bir 'site hızlı' sonucu yerine iş akışı bazlı hedefler belirleyin.

21. Gözlemlenebilirlik

  • Uygulama hata logları.
  • Ödeme/kargo entegrasyon logları.
  • Queue/job başarısızlıkları.
  • Performans metrikleri.
  • Kritik iş olayı sayaçları.
  • Alarm eşikleri.

Canlıda hata müşteriden önce mümkün olduğunca sistem tarafından fark edilmelidir.

22. Pilot Satıcı Seçimi

Pilot için yalnız en büyük satıcıları değil, farklı operasyon tiplerini temsil eden yönetilebilir bir grup seçin.

  • Manuel ürün girişi kullanan.
  • Toplu dosya kullanan.
  • Entegrasyon kullanan.
  • Az SKU.
  • Yüksek SKU.
  • Farklı kargo modeli.

23. Pilot Kategori Seçimi

İlk pilotta katalog, kargo ve iade karmaşıklığı yönetilebilir kategoriler tercih edin. Çok özel mevzuat veya yüksek operasyon riski taşıyan kategoriler iş modeline göre sonraki faza bırakılabilir.

24. Pilot Trafik ve Sipariş Limiti

Pilot dönemde trafik, satıcı ve sipariş hacmini kontrollü artırın.

  1. İç ekip test siparişleri.
  2. Davetli kullanıcılar.
  3. Sınırlı gerçek trafik.
  4. Kategori bazlı açılış.
  5. Daha geniş trafik.

25. Pilot Operasyon Odası

  • Tek sorumlu koordinatör.
  • Ödeme/finans temsilcisi.
  • Satıcı operasyonu.
  • Müşteri desteği.
  • Teknik ekip.
  • Günlük hata/olay listesi.
  • Hızlı Go/No-Go karar kanalı.

26. Pilot Günlük Kontrol

  1. Yeni satıcı/ürün sorunları.
  2. Başarılı/başarısız ödeme.
  3. Sipariş ayrıştırma.
  4. Stok/fiyat hataları.
  5. Kargo gecikmeleri.
  6. İade/refund.
  7. Hakediş/mutabakat.
  8. Destek talepleri.
  9. Teknik hatalar.

27. Hata Sınıflandırması

  • P0: güvenlik/veri/finansal bütünlüğü ciddi etkileyen acil olay.
  • P1: kritik ticari akışı durduran.
  • P2: önemli fakat geçici yöntemle yönetilebilen.
  • P3: düşük etkili iyileştirme/görsel sorun.

Seviye tanımlarını ekibiniz ve risk profiliniz için önceden netleştirin.

28. Go/No-Go Toplantısı

Pilot sonrası tam yayın kararını kanıtlarla verin.

  • Kritik test sonucu.
  • Açık hata listesi.
  • Finansal mutabakat.
  • Operasyon kapasitesi.
  • Satıcı hazırlığı.
  • Destek kapasitesi.
  • Geri dönüş planı.

29. Rollback / Geri Dönüş Planı

Yayın sırasında kritik hata oluşursa neyin kapatılabileceğini ve verinin nasıl korunacağını önceden belirleyin.

  • Yeni checkout'u durdurma.
  • Belirli ödeme yöntemini kapatma.
  • Belirli satıcı/kategoriyi pasife alma.
  • Entegrasyonu güvenli moda alma.
  • Müşteri/satıcı iletişimi.
  • Veri düzeltme planı.

Uygulama: Pilot Yayın Test Dosyası

  1. Go-Live kriterlerini yazın.
  2. Test hesaplarını oluşturun.
  3. Satıcı, katalog, ödeme, kargo, iade ve hakediş E2E senaryolarını listeleyin.
  4. Yetki testlerini ekleyin.
  5. Entegrasyon kesinti senaryolarını ekleyin.
  6. Pilot satıcı ve kategorileri seçin.
  7. Hata seviyelerini tanımlayın.
  8. Günlük pilot kontrol tablosunu oluşturun.
  9. Go/No-Go katılımcılarını belirleyin.
  10. Rollback planını yazın.

Şimdi Uygulayın

Ders Çıktısı

Elinizde gerçek ticari döngüyü, finansal doğruluğu, veri izolasyonunu ve operasyon kapasitesini kanıtlayan Pilot Yayın Test Dosyası bulunmalıdır.

Pazaryerini teknik ve operasyonel olarak kanıtladık. Son derste kontrollü canlıya geçişi ve ilk 90 günde hangi metrik ve yönetim ritmiyle ilerleyeceğimizi kuracağız.

Bu Derste Ne Öğrendik?

  • Pazaryeri yayına alınmadan önce gerçek ticari döngü uçtan uca kanıtlanmalıdır.
  • Pilot yayın; sınırlı satıcı, kategori ve trafikle ödeme, sipariş, kargo, iade, hakediş, yetki ve operasyon süreçlerinin canlı koşullarda kontrollü doğrulanmasıdır.

Öğrendiklerinizi Projenize Dönüştürün

Pazaryeri, online mağaza veya kurumsal dijital ticaret projeniz için KMK'nın deneyimli ekibiyle ihtiyaçlarınızı değerlendirin.