E-ticaret yayın testi: İlk gerçek siparişten önce senaryolar

Müşteri kupayı seçiyor, ödemeyi tamamlıyor ve sipariş numarasını görüyor. Mağaza ekibi paneli açtığında sipariş beklemede görünüyor; depodaki arkadaş ise ürünün hangi renginin gönderileceğini anlayamıyor. Ön yüzün çalışması, mağazanın satışa hazır olduğu anlamına gelmiyor. E-ticaret yayın testi, müşterinin gördüğü ekranla siparişi hazırlayan ekibin kullandığı bilgiyi aynı işlem üzerinden karşılaştırmalıdır. Testin sonunda yalnızca bir ödeme ekranı değil, işletmenin tamamlayabildiği bir sipariş görmek isteriz.

Bu yazıdaki örnek, iki renk ve iki boy seramik kupa satan kurgusal bir mağazadır. Amaç belirli bir altyapıyı tanıtmak değil, yayın öncesinde hangi sorulara cevap aranacağını göstermektir. Tek ürünlü bir mağazada listeyi daraltabilir, bayi fiyatları veya birden fazla depo varsa genişletebilirsiniz. Testleri kendi ürün, ödeme ve teslimat kurallarınıza göre hazırlayın; başka bir sitenin kontrol listesini değiştirmeden kullanmak, sizin operasyonunuzdaki önemli bir ayrıntıyı görünmez bırakabilir.

Başarılı siparişin ne olduğunu ekiple birlikte yazın

İlk iş, satın alma yolculuğunun beklenen sonucunu tanımlamaktır. Kupa örneğinde doğru varyant, güncel fiyat ve teslimat tutarı müşteriye gösterilmeli; işlem sonunda sipariş kaydı, ödeme bilgisi ve hazırlanacak ürün birbiriyle uyuşmalıdır. Bir kontrol belgesine işlemin başlangıcını, kullanılacak örnek ürünü, beklenen sonucu ve kontrol edecek kişiyi yazın. Böylece ekipten biri test edildi dediğinde hangi senaryodan söz edildiği anlaşılır. Testin kapsamına müşteri ekranı kadar yönetim panelini ve bildirimleri de alın.

Her sonucu yalnızca geçti veya kaldı diye işaretlemek yerine kısa bir kanıtla kaydedin. Sipariş numarası, denenen varyant ve gözlenen sorun yeterli olabilir. Ürün yöneticisi yanlış görseli, depo görevlisi eksik ürün kodunu, yazılım ekibi de kaybolan durum değişikliğini fark edebilir. Aynı siparişi farklı görevlerden insanların incelemesi bu yüzden değerlidir. BiKreatif’in e-ticaret yazılımı hizmeti değerlendirilirken bu ekiplerin hangi ekranları kullandığını baştan konuşmak, kabul kapsamını somutlaştırır.

Ürün seçimini birkaç gerçek alışveriş sorusuyla deneyin

Kategoriden ürüne gidin ve ilk kez gelen birinin cevap arayacağı soruları takip edin. Beyaz kupanın büyük boyu seçildiğinde doğru görsel ve stok bilgisi gösteriliyor mu? Seçilmeyen bir özellik yüzünden sipariş belirsiz kalıyor mu? Farklı renkleri sepete eklediğinizde satırlar birbirinden ayırt ediliyor mu? Aynı ürünün iki boyunu satın alan kişi, sepeti yeniden açtığında hangisini seçtiğini anlayabilmelidir. Özellik adlarının ürün sayfası, sepet, sipariş özeti ve depo ekranındaki karşılıklarını birlikte kontrol edin.

Bir de beklenmeyen seçim yapın. Stoku kalmayan varyanta ulaşın, miktarı değiştirin, ürün bağlantısını farklı bir tarayıcıda açın. Sistem eski seçimi hatırlıyorsa bunun ziyaretçiyi yanıltmadığını görün. Ürün açıklamasındaki içerik, ölçü veya paket adedi satın alınan şeyle aynı olmalıdır. Örneğin fotoğrafta iki kupa bulunması, satışın tek adet olduğu bilgisi yeterince belirgin değilse beklentiyi değiştirebilir. Test notuna yalnızca teknik hata değil, yanlış siparişe yol açabilecek anlatım boşluklarını da ekleyin.

Ödeme sonucunu siparişin bütün kayıtlarıyla karşılaştırın

Ödeme denemelerini kullanılan sağlayıcının test ortamı ve güncel deneme yöntemleriyle yürütün. Başarılı işlem kadar başarısız işlem, yarıda bırakılan akış ve kullanıcının geri dönmesi de değerlendirilmelidir. Tarayıcıdaki sonuç mesajını yönetim panelindeki kayıtla karşılaştırın. Ödeme tamamlanmadığında müşteriye tamamlandı deniyor mu? Sonuç henüz belli değilken hangi açıklama gösteriliyor? Sipariş numarası ile ödeme işlem referansı ilişkilendirilebiliyor mu? Bu sorular, destek ekibinin daha sonra işlemi araştırabilmesi için de önemlidir.

Tekrar gelen bir bildirim veya aynı düğmeye iki kez basılması yeni bir sipariş oluşturmamalıdır. İlgili kontrolün nasıl yapılacağı entegrasyona bağlıdır; kabul senaryosunda ise beklenen iş sonucu açıkça yazılabilir. Aynı ödeme denemesi için iki ayrı hazırlık işi açılmasını istemezsiniz. Teknik inceleme gerektiğinde yalnızca ekran fotoğrafı göndermek yerine işlem zamanı ve kayıt referansını da paylaşın. Test verilerini gerçek müşteri kayıtlarından ayırın; denemelerin satış ekibine gerçek bir sipariş gibi aktarılmasını önleyin.

Tek satırlık test kaydı örneği

Ürün: büyük beyaz kupa; miktar: bir; işlem: başarısız ödeme sonrası yeniden deneme. Beklenen sonucu tek sipariş, doğru stok ve tutarlı ödeme durumu olarak kaydedin. İşlem referansını ve gözlenen sonucu bu satıra ekleyin.

Son ürünün iki kişiye satılmasını ayrı bir senaryo yapın

Stok kontrolü, ürün sayfasında bir sayı görmekten ibaret değildir. Örnek mağazada büyük beyaz kupadan bir adet kaldığını düşünelim. İki farklı oturum aynı ürünü sepete eklediğinde hangi aşamada miktar ayrılacak? Bir kişi işlemi tamamladığında diğeri nasıl bilgilendirilecek? Burada bütün mağazalar için tek bir doğru süre yoktur. İşletmenin ayırma ve serbest bırakma kuralı belirlenmeli, yazılımın bu kurala göre davrandığı denenmelidir. Özellikle birden fazla satış kanalı varsa stok kaynağını açıkça tanımlayın.

Başarısız ödeme veya süresi dolan işlem sonrasında ayrılan miktarın durumunu da inceleyin. Ürün gereksiz yere satış dışı kalıyor mu, yoksa hazırlanacak siparişe rağmen yeniden satılabilir görünüyor mu? İptal ve iade senaryolarını bu kontrolün devamı olarak düşünün. Paneldeki toplam stok, satılabilir stok ve ayrılmış miktar farklı amaçlara hizmet edebilir. Ekran adlarını ve ekipteki kullanımını karşılaştırın. Bir kişinin stok dediğinde gördüğü sayı, başka birinin gönderime hazır ürün sayısı olmayabilir.

Siparişi depoda gerçekten hazırlayın

Test siparişini yönetim panelinde görmekle durmayın; hazırlanacak bir iş olarak ele alın. Görevli hangi ürünü, hangi miktarda ve hangi adrese göndereceğini ekranından çıkarabilmeli. Sipariş notu, hediye paketi veya farklı teslimat bilgisi varsa doğru kişiye ulaşmalıdır. Kupa örneğinde kırılabilir ürünün paketleme notu ile kargo seçiminin operasyon tarafında nasıl göründüğünü kontrol edin. Ürünü hazırlayan kişinin müşteriyle yeniden görüşmeden temel işlemi tamamlayabilmesi, bilginin yeterli olup olmadığını gösterir.

Kargo bağlantısı kullanılıyorsa etiket, takip bilgisi ve sipariş durumu aynı gönderiyi izlemelidir. Müşteriye iletilen bağlantıyı da açın; yönetici ekranında görünen bir adresin dışarıdan çalıştığını varsaymayın. Entegrasyon hizmeti geçici olarak cevap vermediğinde sipariş kaybolmamalı, ekip neyi tekrar deneyeceğini anlayabilmelidir. Başarısız denemeleri görünür tutmak, aynı gönderi için birden fazla kayıt açılmasını fark etmeyi kolaylaştırır. Bildirim metinlerini de bu gerçek akışa göre okuyun; henüz hazırlanmamış sipariş için yola çıktı mesajı gitmemelidir.

İptal ve kısmi iadede toplamı yeniden kurun

İlk sipariş iki farklı kupa içeriyorsa bunlardan yalnızca birinin iptal edildiği durumu deneyin. Sipariş satırı, stok hareketi, ödeme düzeltmesi ve müşteri bildirimi birbirini takip ediyor mu? Bir kupon kullanılmışsa kısmi işlem sonrasında hangi tutarın geçerli olacağı işletmenin tanımladığı kurala göre hesaplanmalıdır. Bu kuralları yayın günü belirlemek yerine teklif ve geliştirme aşamasında açıklığa kavuşturun. Hazır platformun varsayılan davranışı ile ekibin beklediği işleyiş farklıysa, bunu testte yakalayabilmelisiniz.

İade edilen ürünün fiziksel kontrolünü de ayrı bir görev olarak düşünün. Talep açılması, ürünün depoya gelmesi ve yeniden satılabilir bulunması aynı olay değildir. Yazılım bütün bu adımları tek bir düğmeyle tamamlıyorsa ekibin bunun sonucunu bilmesi gerekir. Testte kayıt geçmişini takip edin ve müşteriye gösterilen durumun anlaşılır olmasına bakın. Ayrıntılı operasyon kuralları gerektiğinde özel yazılım projesi kapsamında hangi akışların ayrıca geliştirilmesi gerektiği bu örneklerle belirlenebilir.

Telefonu, farklı rolleri ve yayın ayarlarını kontrol edin

Aynı satın alma akışını telefonda tamamlayın. Klavye alanı kapattığında hata mesajı görülebiliyor mu? Varyant değiştirmek veya teslimat seçmek için parmakla rahatça işlem yapılabiliyor mu? Kullanıcı sayfadan ayrılıp döndüğünde sepetin durumu anlaşılır mı? Mobil kontrolü yalnızca ekranı küçülterek yapmayın; gerçek cihazdaki giriş, kaydırma ve uygulamalar arasında geçiş deneyimini görün. Hesap açmadan alışveriş gibi desteklenen bir yol varsa onu da ayrı bir ziyaretçi olarak deneyin.

Ardından yönetici olmayan çalışanların ekranlarını inceleyin. Sipariş hazırlayan kişinin fiyat veya kullanıcı yetkilerini değiştirmesine ihtiyaç yoktur; fakat görevini tamamlayacak bilgiyi görebilmelidir. Yayın öncesi korumalar, test ödeme ayarları ve arama motoru erişimi için de kısa bir teslim kaydı hazırlayın. Google’ın e-ticaret sitesi yayına alma açıklaması, keşif ve dizine eklenme hazırlığını operasyonel lansmandan ayrı değerlendirmek için yararlı bir başvuru noktasıdır. Siparişin çalışması ile aramada görünürlük aynı kontrol değildir.

Yayın kararına açık sorunlar ve geri dönüş planını ekleyin

Son toplantıda bütün maddeleri eşit ağırlıkta tartışmayın. Yanlış ürünün hazırlanması, ödeme sonucunun kaybolması veya siparişin iki kez oluşması temel akışı etkiler. Küçük bir görsel hizalama sorunu farklı öncelikte olabilir. Her açık sorunu kullanıcıya ve operasyona etkisiyle yazın. Hangi sorunun kapanmadan yayın yapılamayacağını ekipçe belirleyin. Kararı yalnızca geliştiren kişi vermesin; mağazayı işletecek taraf, hangi işleyişi teslim aldığını görsün.

Bir sorun çıkarsa kimin kampanyayı durduracağı, kimin teknik incelemeyi yürüteceği ve müşteri taleplerini kimin karşılayacağı belli olsun. Önceki kod sürümüne dönmek, yeni alınmış siparişleri silmek anlamına gelmemelidir. Yayın saatindeki sürümü ve işlem kayıtlarını koruyun. İlk gerçek siparişleri de belirlenen sorumlular birlikte izlesin. Kabul testi böylece bir dosyanın imzalanmasıyla biten iş olmaktan çıkar; ekibin mağazayı devralmasını sağlayan ortak bir çalışma hâline gelir.

Sık Sorulan Sorular

Bir başarılı ödeme testi yeterli mi?

Tek bir işlem yalnızca o anda denenen yol hakkında bilgi verir. Farklı varyant, başarısız ödeme, tekrar gönderim ve sipariş hazırlama gibi akışları da değerlendirin. Özellikle yönetim panelindeki kaydın müşteri ekranıyla uyuşması gerekir. Test kapsamını mağazanın kullandığı gerçek iş kurallarına göre belirleyin.

Bütün testler gerçek parayla mı yapılmalı?

Ödeme sağlayıcısının sunduğu test ortamı ve desteklediği senaryolarla başlayın. Canlı ortam doğrulaması gerekiyorsa yöntemi sağlayıcının güncel talimatlarına göre ayrıca planlayın. Test işlemlerini ve kullanılan hesapları ekipçe ayırt edilebilir tutun. Gerçek sipariş ve deneme kaydını aynı operasyon kuyruğunda karıştırmayın.

Test listesini kim hazırlamalı?

Yazılım ekibi teknik senaryoları, mağaza ekibi ürün ve operasyon istisnalarını getirir. Müşteri hizmetleri tekrar eden soruları, depo görevlileri hazırlama ihtiyaçlarını ekleyebilir. Bir koordinasyon sorumlusu listeyi bir arada tutmalıdır. Yalnızca geliştirme ekranlarından hazırlanmış bir liste, günlük işleyişteki sorunları gözden kaçırabilir.

Hazır altyapı kullanırken de kabul testi gerekir mi?

Evet. Hazır platformun üzerinde ürün veriniz, tema ayarlarınız, ödeme ve teslimat seçenekleriniz çalışır. Aynı altyapıyı kullanan iki mağazanın akışları farklı olabilir. Test, platformun genel olarak çalıştığını yeniden kanıtlamak için değil, sizin kurulumunuzun ve operasyonunuzun birlikte işlediğini görmek için yapılır.

İade akışı yayından sonraya bırakılabilir mi?

İade ve iptal mağazanın desteklediği işlemlerse temel akışları yayın öncesinde açıklığa kavuşmalıdır. Geliştirme kapsamı ayrıntıya göre değişebilir; fakat ekip hangi kayıtla ne yapacağını bilmelidir. Özellikle stok ve ödeme durumlarının birbirinden kopması, ilk taleplerde elle takip yükünü artırabilir.

Testler geçince hiçbir sorun çıkmaz mı?

Test, hazırlanmış senaryoların gözlenen koşullarda çalıştığını gösterir. Yeni kullanım biçimleri veya dış servis değişiklikleri başka sorunlar ortaya çıkarabilir. Bu yüzden ilk gün izleme ve sorumluluk planını da teslimin parçası yapın. Kontrolün değeri, ekibin gördüğü sorunu daha hızlı tanımlayıp ele alabilmesidir.