E-ticaret sitesi kurulum projesi, iş gereksinimini çalışan katalog, ödeme, teslimat ve ölçüm akışına dönüştürür. Projenin tamamlanma ölçütü sayfaların güzel görünmesi değil, belirlenen müşteri ve operasyon görevlerinin doğrulanmasıdır. Bu teknik rehber, iş modeli başlangıcından farklı olarak girdileri, bağımlılıkları ve kabul kapılarını ele alır.
İş gereksinimini ölçülebilir teslimlere çevirin
Platform, ürün/varyant yapısı, stok kaynağı, ödeme sağlayıcısı, teslimat bölgeleri ve gereken entegrasyonlar listelenmelidir. Mevcut mağaza taşınıyorsa URL, medya ve veri envanteri eklenir. Bir entegrasyonun var olduğunu söylemek yerine fiyat, stok, sipariş ve iadenin hangi yönde aktarılacağını yazın.
Kapsam dışı işleri ayrıca görünür yapın: ürün fotoğrafı, hukuki metin kontrolü, özel ERP geliştirmesi veya reklam yönetimi gibi. “Anahtar teslim” ifadesi bu ayrımı otomatik yapmaz. Her teslimde işletme, ajans ve sağlayıcının sorumluluğu belirli olmalıdır.
Bir gereksinimin kabul cümlesi nasıl yazılır?
“ERP entegrasyonu yapılacak” yerine hangi alanın hangi yönde taşınacağını açıklayın. Temsili kabul cümlesi: kaynakta güncellenen varyant stoğu, kararlaştırılmış akışta mağazadaki aynı varyanta ulaşacak; başarısız kayıt sorumluya görünür olacak. Burada belirli bir süre veya teknik yöntem varsayılmaz; bunlar gerçek sistemlerin olanakları ve işletme ihtiyacıyla belirlenir.
Her teslimin girdisini yazın. Ürün dosyası eksikse aktarım işi, sağlayıcı onayı yoksa canlı ödeme işi tamamlanmış sayılmaz. İşletme, ajans ve üçüncü tarafın sorumluluğunu ayırın. Geciken girdinin takvime etkisini görünür tutmak, proje sonunda bütün eksikleri tek bir ekibe yüklemekten daha sağlıklı bir yönetim sağlar.
Katalog kabulünü kaynak ve müşteri görünümünde yapın
Ürün dosyasındaki SKU ve varyant kimliği tutarlı olmalıdır. Açıklama, görsel ve teknik özellik gerçek üründen hazırlanmalıdır. Farklı ürün yapıları içeren küçük bir örneklemle yükleme yapın. Panel sayısını görmek yerine müşteri görünümünde seçili varyantın fiyat/stok davranışını test edin.
Kaynak veride düzeltme yapılmadan yalnız hedef panelde değişiklik yapmak sonraki aktarımda hatayı geri getirebilir. Veri temizliği ve onay sorumlusunu projenin başında tanımlayın. Ürünlerin tamamı hazır değilse kapsamı sessizce eksik bırakmak yerine kabul planında açık iş olarak kaydedin.
Ürün anahtarı, varyant ilişkisi, fiyat/para birimi, stok, açıklama ve görsel kullanım hakkı veri sözleşmesinde bulunsun. Örnek aktarım yalnız sayısal toplam kontrolü değildir. Aynı kaydı ikinci kez işleyin, zorunlu alanı eksik bırakın ve başarısız satırın nasıl raporlandığını görün. Sonra müşterinin varyant seçiminin doğru sepet satırını oluşturduğunu denetleyin.
Görünüm hatası ile veri hatasını ayırın
Fiyat kaynakta yanlışsa tema düzeltmesi çözüm değildir. Kaynak doğru fakat mağazada farklı para birimi görünüyorsa alan eşlemesi veya sunum incelenir. Uzun ürün adı kırpılıyorsa bilgi doğru olabilir, arayüz görevi engelliyordur. Her soruna doğru iş türü ve kabul kanıtı atayın; genel “ürün problemi” etiketi sorumluluğu belirsiz bırakır.
Ödeme ve teslimatta yalnız başarı yolunu test etmeyin
- Başarılı ve reddedilen ödeme dönüşlerini test edin.
- Ödeme kabulüyle sipariş ve stok kaydını karşılaştırın.
- Farklı adres, sepet ve teslimat koşullarını deneyin.
- Müşteri bildirimlerinde gerçek işletme ve sipariş bilgisini kontrol edin.
- İptal/iade akışını sağlayıcı ve operasyonla birlikte doğrulayın.
Test kimliğiyle çalışan sistem canlı tahsilat kabulü değildir. Gerçek sağlayıcı onayı, yetkili kontrollü test ve güvenli secret yönetimi ayrı tamamlanmalıdır. Hukuki veya vergisel uygunluk blog kontrol listesinden otomatik çıkarılamaz.
Temsili test matrisi başarılı ödeme, reddedilen ödeme, geç gelen bildirim ve tekrar tıklamayı içerir. Sipariş, stok ve tahsilat aynı işlemi temsil etmelidir. Kargo tarafında farklı paket, hizmet dışı adres ve etiket kesintisini ekleyin. Kullanılan sistemin gerçek yetenekleriyle mümkün olan testleri ve yapılamayan canlı kontrolleri ayrı kaydedin.
Müşteriye giden e-posta veya SMS için de teslim sonucu ile uygulamanın isteği kabul etmesini ayırın. Test alıcısının gerçekten mesajı görmesi ayrı kanıttır. Hukuki metnin eklenmesi ve izin mekanizmasının görüntülenmesi hukuki uygunluk onayı değildir; işletmenin gerçek veri işleme süreci ayrıca değerlendirilir.
URL ve ölçüm envanterini sürüm dosyasına ekleyin
Her önemli URL kendi gerçek içeriğine ulaşıyor mu? Canonical ve sitemap aynı esas adresi mi kullanıyor? Taşınmış sayfalarda gerçek eşdeğere kalıcı yönlendirme bulunuyor mu? Google site taşıma rehberi URL haritası ve izleme için resmî kaynaktır; bütün eski yolları ana sayfaya göndermek geçişi tamamlamaz.
Teknik SEO denetimi erişim ve indekslemeyi, ölçüm rehberi olay anlamı ve çift kayıt kontrolünü tamamlar. Panel kimliğinin bulunması gerçek olayın doğru çalıştığına kanıt sayılmamalıdır.
Önemli adreslerin beklenen durum kodu, canonical, indeksleme tercihi ve içerik karşılığı belli olsun. Site taşımasında önceki ürünün yeni kategoriye veya ana sayfaya gitmesini eşdeğerlik kabulü sanmayın. Değişmeyen adresleri de test edin; yönlendirmeye ihtiyaç olmaması içerik kaybı kontrolünü ortadan kaldırmaz.
Ölçümde her olayın sahibi ve gerçek anlamı yazılsın. Aynı satın alma hem tema hem etiket yöneticisi tarafından gönderiliyorsa çift kayıt riski vardır. Hesap kimliğini bulmak doğru satın alma tutarı veya izin davranışı kanıtı değildir. Kontrollü testte olayın işlemi ve para birimini doğru temsil ettiğini inceleyin; gerçek kullanıcı verisini açık rapora taşımayın.
Yayın kararını geri dönüş ve açık sorunlarla verin
Mobil müşteri görevleri ve operasyon kabulü geçmeden yalnız tasarım onayıyla yayına çıkmayın. Alan adı ve SSL yanında mevcut posta DNS kayıtlarını da kontrol edin. Geçişe uygun kaynak, veri ve medya yedeği bulunmalı; rollback’in kim tarafından hangi koşulda yapılacağı belirlenmelidir.
Yayın sonrası hata, sipariş ve arama görünürlüğünü takip etmek için sorumlu ve kontrol zamanları yazın. Hazırlık sırasında düzeltilmeyen bağımlılıklar açık listede kalmalıdır. Bir test istisnası kabul edilecekse etkisi ve kabul eden kişi belirli olmalıdır.
Geri dönüş dosyası yaşayan veriyi kapsasın
Yedek alındıktan sonra oluşan siparişler, ödeme referansları ve stok hareketleri korunmalıdır. Eski kaynak kodunu geri açmakla veri tabanını geçmişe döndürmek farklı riskler taşır. Geri dönüşü başlatacak kişi, karar koşulu ve yeni işlemlerin mutabakatı önceden belirlenmelidir. Bu rehber gerçek DNS veya canlı geçiş yaptığınızı varsaymaz.
Yayına engel hata ile kabul edilebilir sonraki iş ayrılmalıdır. Ödeme kaybı veya yanlış ürün seçimi görsel rötuşla aynı öncelikte değildir. Kabul edilen istisnanın etkisi, sorumlusu ve takip tarihi yazılmalıdır. Tasarım onayının bütün operasyonu otomatik onayladığı düşünülmemelidir.
İşletmeye kullanılabilir bir bakım paketi teslim edin
Hesap sahipliği, yönetici rolleri, özel kod, veri eşleştirmeleri ve bakım planı işletmeye devredilmelidir. Kurulumun devam eden hizmet gerektiren alanlarını açıklayın. Başlangıç rehberi iş kararlarını, bütçe rehberi teklif kalemlerini tamamlar. Kurulum hizmeti kapsamını bu teslimler üzerinden görüşmek, neyin gerçekten tamamlanacağını görmenizi sağlar.
Hesap listesi, veri eşleme dosyası, özel geliştirme kaydı, test raporu ve bakım sorumlusu birlikte devredilsin. Eğitimde günlük ürün güncellemesi ve problemli sipariş yürütün. Yeni bir ekip üyesi aynı kayıttan hangi sistemin esas olduğunu anlayabiliyorsa teslim dosyası iş görüyordur. Kurulum sonrasında değişen ürün, sağlayıcı ve tema için hangi testlerin tekrar edileceği de bu dosyada bulunmalıdır.
Yayın sonrası kontrolü proje planının içine alın
İlk gerçek işlem test ortamından farklı kanıt taşır
Yayından sonra gerçek sağlayıcı yanıtı, müşteriye ulaşan bildirim ve taşıyıcı hareketi yetkili ekip tarafından izlenir. Önizlemede bütün testlerin geçmesi bu dış sistemlerin canlı koşullarını doğrulamaz. İzleme dosyası hangi kontrolün yerel, hangisinin sandbox, hangisinin canlı işlem olduğunu açıkça belirtmelidir.
Teknik kontrol listesinde önemli adresler, sayfa hataları, indeksleme tercihi ve ölçüm olaylarının değişip değişmediği bulunabilir. Operasyon listesinde sipariş, ödeme, stok ve paket eşleşmesi yer alır. İki listenin sorumlusu aynı olmak zorunda değildir; ortak olay referansı sayesinde bulgular birleştirilir. Müşteri kişisel verisi veya gizli anahtar açık rapora yazılmaz.
İlk dönemde bulunan her sorun yeni özellik talebi değildir. Önceden kabul edilmiş davranışın bozulması hata, kapsamda olmayan yeni iş ise değişikliktir. Bu ayrım destek ve bütçe tartışmasını azaltır. Çözüm kaydında uygulanan değişiklik ve ilgili regresyon kanıtı bulunmalıdır; yalnız “bakıldı” veya “tamamlandı” ifadesi sonraki ekibe yeterli bilgi bırakmaz.
Yurt dışına satışta dil, para birimi ve teslimat kontrollerini T-Soft e-ihracat kurulum kontrol listesinde inceleyebilirsiniz.
