E-ticaret yayın öncesi test planı: siparişin tüm durumları

Bir mağazanın yayına hazır olduğunu anlamak için bir ürünü sepete ekleyip başarılı ödeme ekranını görmek yeterli değildir. Katalogdaki farklı ürünler, değişen stok, eksik adres, yinelenen tıklama ve ödeme sağlayıcısından geç gelen yanıt aynı sipariş yolculuğunun parçalarıdır. Yayın öncesi testin görevi, her olası hatayı sonsuza kadar ortadan kaldırmak değildir. Kritik durumların nasıl karşılandığını görmek, sorumlulukları belirlemek ve çözülemeyen konuları yayın kararını veren kişilere açıkça aktarmaktır.

Bu rehberde, farklı boyut ve renk seçenekleri bulunan ev ürünleri satan hayali bir mağaza üzerinden ilerliyoruz. Mağazanın stok sistemi ve ödeme bağlantısı olduğunu varsayıyoruz; ancak belirli bir yazılımın menülerini izlemiyoruz. Böylece kontrol planını mevcut altyapına uyarlayabilirsin. Ödeme kontrolleri sağlayıcının desteklediği test ortamında ve test verileriyle yapılmalıdır. Gerçek müşteri bilgileri, gerçek kartlar veya gerçek siparişler üzerinden rastgele deneme yapmak bu planın parçası değildir.

Yayın kararı ile test listesini birbirinden ayır

Bir test kaydının başarılı görünmesi teknik bir gözlemdir; yayına geçme kararı ise işletmenin de katıldığı ayrı bir değerlendirmedir. Hangi akışların mutlaka çalışması gerektiğini önceden yaz. Örneğin ürün seçimi, doğru tutarın gösterilmesi, ödeme durumunun kaydı ve siparişin operasyon ekibine ulaşması kritik kabul edilebilir. Görseldeki küçük bir hizalama sorunu ile siparişin kaybolması aynı öncelikte değerlendirilmemelidir. Önceliği sorunun alışverişe ve günlük operasyona etkisiyle açıklamak, tartışmayı kişisel tercihlerden uzaklaştırır.

Listede her kontrolün bir sahibi, test koşulu ve beklenen sonucu olsun. “Sepet denendi” kaydı yerine “iki farklı varyasyon eklendiğinde ürün adları, seçilen özellikler ve toplam doğru göründü” yaz. Başarısız kayıtlarda gerçekleşen davranışı ayrıca belirt. Sorunun giderildiğini kontrol edecek kişi de belli olsun. Bir geliştiricinin değişikliği tamamlaması ile mağaza ekibinin akışı tekrar onaylaması farklı adımlardır; ikisinin aynı satırda kaybolmasını önle.

Temsil gücü olan bir test kataloğu seç

Yalnız en sorunsuz ürünü kullanırsan katalogdaki istisnaları göremezsin. Tek seçeneği bulunan ürün, çok varyasyonlu ürün, uzun başlıklı ürün, indirimli ürün ve stok dışı ürün gibi farklı kayıtlar seç. Görseli olmayan veya açıklaması kısa kalan kayıtları da incele. Bunları gerçek katalogdaki sorunları gizlemek için özel hazırlanmış kusursuz örneklerden oluşturma. Test ürünlerinin hangi ihtiyacı temsil ettiğini kaydet; böylece yeni bir ürün türü geldiğinde kontrol planını nasıl genişleteceğini bilirsin.

Seçilen kayıtların fiyat, stok ve özellik bilgilerinin onaylı başlangıç durumunu sakla. Bir kontrol sırasında stok başka bir ekip tarafından değiştirilirse sonucu açıklamak zorlaşabilir. Test süresince veriyi kimin değiştireceği konusunda anlaş. Özellikle entegrasyon üzerinden gelen bilgilerde hangi sistemin kaynak olduğunu belirle. Bir ürüne panelden müdahale edildiğinde sonraki veri aktarımının bu değişikliği geri alıp almadığını ayrıca incele. Katalog yapısı belirsizse önce ürün kataloğu planını netleştirmek gerekir.

Ürün keşfini bilinen ve bilinmeyen aramalarla dene

Mağaza ekibi ürünlerin isimlerini ve kategorilerini zaten bilir. Bu nedenle ilk görevi tam ürün adıyla, ikinci görevi ise yalnız ihtiyacı tarif ederek yap. Hayali mağazamızda “çalışma masası için küçük bir aydınlatma” arayan kişinin izlediği yolu düşün. Kategori isimleri bu ihtiyaca yardımcı oluyor mu? Filtreyi kaldırmak kolay mı? Sonuç bulunamadığında kullanıcıya bir sonraki adım gösteriliyor mu? Arama ve filtre sonuçlarını yalnız ürün sayısıyla değil, seçilen koşullarla tutarlılığı üzerinden kontrol et.

Listeye dönüldüğünde filtrelerin veya kaydırma konumunun ne olduğu gibi küçük görünen davranışları da not et. Her tercihin tek doğru cevabı yoktur; önemli olan kararlaştırılan deneyimin tutarlı işlemesidir. Filtre bir özelliği seçili gösterirken sonuçların bunu yansıtmaması ise açık bir problemdir. Bulgunun ekran görüntüsüne ek olarak seçilen koşulları yaz. Yalnız son ekranı paylaşmak, geliştiricinin aynı duruma ulaşmasını her zaman sağlamaz.

Varyasyon seçimini fiyat ve stokla birlikte kontrol et

Renk veya boyut değiştirildiğinde hangi bilgilerin değişmesi gerektiğini ürün ekibiyle tanımla. Görsel, fiyat, stok mesajı ve ürün kodu her mağazada aynı davranmayabilir. Beklenen davranış belli olmadan ekrandaki farkın hata olup olmadığı tartışmalı kalır. Kullanıcının seçimini yapmadan sepete ekleme düğmesine basmasını da dene. Sistem eksik seçimi anlaşılır biçimde belirtiyor mu, yoksa kullanıcı nerede yanlış yaptığını tahmin etmek zorunda mı kalıyor?

Sepete giden kaydın ürün detayında seçilen varyasyonla aynı olduğunu doğrula. Ardından ürün detayını yeniden açıp başka bir seçenek seç. Önceki seçimin yanlışlıkla yeni kayda taşınması veya sepetteki özelliklerin güncellenmeden kalması gibi durumlara bak. Aynı ürünün iki farklı varyasyonunu ayrı satırlarda izlemek gerekiyorsa bunun gerçekleştiğini kontrol et. Operasyon ekibinin hazırlayacağı ürün, yalnız görünen başlıkla değil doğru özellik ve kayıt bilgisiyle anlaşılabilmelidir.

Sepetteki değişiklikleri küçük bir durum tablosuna dönüştür

Adet artırma, azaltma, ürün kaldırma ve alışverişe geri dönme görevlerini sırayla uygula. Her işlemden sonra toplamın, varsa teslimat hesabının ve indirim bilgisinin tutarlılığını kontrol et. Bir ürün kaldırıldığında sepetin boş durumuna nasıl geçildiğini de gör. Sepet boşken kullanıcıdan ödeme adımına ilerlemesi beklenmemelidir. Sayfa yenilendiğinde veya bağlantı yeniden açıldığında sepetin nasıl davranacağı, mağazanın oturum ve saklama yaklaşımıyla birlikte değerlendirilmelidir.

Kupon kullanılıyorsa yalnız geçerli kodu test etme. Geçersiz, süresi tamamlanmış veya seçilen ürün için uygun olmayan bir kodun nasıl açıklanacağını belirle. Hata mesajı koşulları yanlış anlatmamalı ve kullanıcıya yapamayacağı bir işlem önermemelidir. Kampanya kurallarının kaynağı pazarlama ekibiyse son doğrulamayı da o ekip yapmalıdır. Yazılımın bir indirim uygulaması, ticari koşulların doğru aktarılmış olduğu anlamına tek başına gelmez.

Adres ve form kontrollerini gerçek görev gibi yürüt

Test verisiyle eksik alan, uzun adres ve hatalı biçimde girilmiş iletişim bilgisi durumlarını dene. Zorunlu alanların görünürlüğünü, etiketlerin anlaşılmasını ve hata mesajının doğru alanla ilişkisini incele. Kullanıcı bir hatayı düzelttiğinde diğer bilgilerini kaybediyor mu? Mobil klavye açıkken sonraki alanlara ve devam düğmesine ulaşabiliyor mu? Form değerlendirmesinde yalnız doğru veriyi kabul etmek değil, hatadan sonra işleme devam edebilmek de önemlidir.

W3C’nin erişilebilir form rehberi, alanların etiketlenmesi, gerekli açıklamalar ve doğrulama mesajları için yararlı bir teknik çerçeve sunar. Bu çerçeveyi sitenin kendi senaryolarıyla uygula. Örneğin teslimat ile fatura bilgisi farklı olduğunda hangi alanların açılacağını test listesine yaz. Yalnız görsel bir kontrol yaparak bütün formun erişilebilir olduğunu ilan etme; incelemenin kapsamını açık tut.

Ödeme sonucunun sipariş durumuna nasıl dönüştüğünü izle

Ödeme sağlayıcısının sunduğu test olanaklarını ve mağazanın desteklediği senaryoları teknik ekiple belirle. Başarılı işlem kadar reddedilen işlem ve kullanıcının geri dönmesi de planın parçasıdır. Sağlayıcı ekranındaki sonuç ile mağaza panelindeki sipariş durumu arasında tutarsızlık varsa bunu yalnız arayüz sorunu gibi ele alma. Ziyaretçiye görünen mesaj, stok davranışı ve operasyonun göreceği durum birlikte incelenmelidir. Her sağlayıcının yöntemini kendi resmi belgelerinden doğrulamak gerekir.

Ödeme düğmesine art arda basılması veya sonucun geç gelmesi gibi durumlarda kullanıcıya ne gösterildiğini sor. Aynı test isteğinin yinelenmesiyle yeni bir işlem arasındaki ayrımın nasıl ele alındığını teknik ekip açıklamalıdır. Burada amaç kendi başına ödeme sistemini zorlamak değildir. Desteklenen test koşullarında sipariş kaydının tutarlılığını ve belirsiz durumdaki iletişimi değerlendirmektir. Çözülemeyen bir ödeme belirsizliği için yayın öncesinde açık bir karar kaydı oluştur.

Bildirimleri yalnız teslim edildi mi sorusuyla sınırlama

Sipariş bildiriminin müşteriye ve ilgili operasyon kişisine doğru içerikle ulaştığını test adresleri üzerinden kontrol et. Seçenekler, adet, tutar ve teslimat bilgisi ekrandaki kayıtla aynı olmalı. Bildirimin başlığında veya metninde eski marka adının, test ortamının ya da geçersiz iletişim bilgisinin kalıp kalmadığına bak. Mağaza panelindeki bir değişiklik, bildirim şablonlarına otomatik yansımıyor olabilir. Bu nedenle her kanalı kendi çıktısı üzerinden değerlendirmek gerekir.

Operasyon ekibinden bir kişiye örnek siparişi hazırlaması için yalnız normalde göreceği bilgileri ver. Ürünü ve varyasyonu anlayabiliyor mu, ek açıklama için başka bir sisteme bakması gerekiyor mu? Bu küçük masa başı prova, tasarım ekibinin göremediği eksikleri ortaya çıkarabilir. Bildirimin gecikmesi halinde siparişin nereden takip edileceğini de belirle. Tek bir e-postaya bağlı süreç yerine mağazanın mevcut kayıt ve takip olanaklarını açıkça tanımla.

Yayın sabahı için kısa ve sorumlusu belli bir plan bırak

Test ortamındaki onaylar, canlı ortamda hiçbir kontrol yapılmayacağı anlamına gelmez. Canlıya geçişte alan adı, bağlantılar ve ortam ayarları gibi değişen parçaları listele. Kontrollerin kim tarafından, hangi sırayla ve hangi destek kanalıyla yürütüleceğini belirle. Gerçek ödeme gerektiren bir doğrulama varsa bu, ayrıca yetkilendirilmiş bir işletme prosedürü olmalıdır; geliştiricinin veya pazarlama ekibinin rastgele kararıyla yapılmamalıdır. Yayın penceresinde ulaşılacak kişileri önceden teyit et.

Geri dönüş kararının koşulları ve veriye etkisi de konuşulmalıdır. Bir yedeğin var olması, ortaya çıkan bütün siparişleri kayıpsız biçimde eski duruma taşıyabileceğin anlamına gelmez. Teknik ekibin açıklayabildiği bir geri dönüş yöntemi, sorumlu kişi ve karar noktası iste. Yayın sonrasında görülen sorunları tek yerde kaydet; farklı mesaj gruplarında kaybolan bildirimler önceliklendirmeyi zorlaştırır. Açık kalan işler ve kabul edilen sınırlılıklar herkes tarafından görülebilmelidir.

Aynı bulguyu farklı ekiplerin anlayabileceği biçimde kaydet

“Ödeme çalışmıyor” gibi bir bildirim, incelemeyi başlatmak için yeterli ayrıntı taşımaz. Test ortamını, kullanılan ürün kaydını, izlenen adımları ve görülen mesajı ekle. Sorun her denemede mi oluşuyor, yoksa belirli bir varyasyonda mı? Beklenen sonuç hangi onaylı iş kuralına dayanıyor? Bu bilgileri yazmak, geliştiricinin sorunu tekrar üretmesini ve işletme ekibinin ticari etkisini değerlendirmesini kolaylaştırır. Kayıtta özel kişisel bilgileri veya ödeme verilerini paylaşmak gerekmez; test senaryosunu açıklayan güvenli bilgiler kullanılmalıdır.

Örneğin hayali mağazamızda iki farklı renk sepete eklendiğinde sipariş bildiriminde ikisinin de aynı renk olarak göründüğünü düşünelim. Ekran görüntüsü yalnız yanlışlığı gösterir. İyi bir kayıt, seçilen ürün kodlarını ve bildirimde beklenen renkleri de içerir. Teknik düzeltmeden sonra yalnız bildirim metnini kontrol etmek yetmeyebilir; paneldeki kayıt ve operasyon çıktısı da aynı senaryoyla yeniden değerlendirilir. Böylece tek bir görünen belirtiyi kapatırken ilişkili verinin yanlış kalması önlenmeye çalışılır.

Her bulgu için kapsamı açık bir kapanış koşulu belirle. Bu örnekte kapanış, iki varyasyonun sepetten operasyon kaydına kadar ayrı ve doğru görünmesidir. Son testin hangi sürümde yapıldığını yaz; daha sonra benzer sorun çıktığında eski raporun hangi durumu anlattığı anlaşılır. Kullanıcı etkisini abartmadan açıklamak da önemlidir. Sorun yalnız belirli koşullarda oluşuyorsa bunları belirtmek, bütün mağazanın kullanılamadığı izlenimini vermekten daha doğru bir değerlendirme sağlar.

Sonuçları bir test raporunda birleştir

Raporun her satırında senaryo, kullanılan kayıt, beklenen sonuç, gerçekleşen sonuç ve son kontrol tarihi bulunsun. Başarısız kontrolleri kapatmak için “düzeltildi” yazmak yerine yeniden denemenin sonucunu kaydet. Bir davranış bilinçli olarak sonraki aşamaya bırakılıyorsa karar veren kişiyi ve gerekçeyi belirt. Böylece tamamlanan işler, kabul edilen sınırlamalar ve yayını engelleyen sorunlar birbirine karışmaz. Test raporu, projenin hatasızlık belgesi değil; neyin nasıl değerlendirildiğinin kaydıdır.

Mağazanın ihtiyaçları değiştikçe bu liste de değişir. Yeni bir teslimat seçeneği, ürün türü veya ödeme yöntemi geldiğinde ilgili senaryoları ekle. İlk yayın için oluşturduğun kayıtlar, sonraki değişikliklerde neyi tekrar kontrol etmen gerektiğini hatırlatır. Digitalismo’nun e-ticaret çalışmasını planlarken katalog, kullanıcı deneyimi ve operasyon kontrollerini bu nedenle birlikte ele alıyoruz. Daha sağlam bir başlangıç, yalnızca daha uzun test yapmak değil, doğru durumları açık biçimde değerlendirmekle mümkündür.