Her şeyi entegre etmeden önce, veriler yanlış aktarıldığında ne olacağını test edin

Yeni bir sistemi mevcut yapıya bağlamak çoğu ekip için bir “teknik entegrasyon” işi gibi görünür. API cevap veriyorsa, bağlantı kuruluyorsa, veri akıyorsa sorun yok sanılır. Asıl risk genelde burada başlar, veri akar ama yanlış akar. Üstelik bu hata çoğu zaman sessiz ilerler.

Entegrasyonlarda en tehlikeli problem bağlantının kopması değil, yanlış verinin doğruymuş gibi taşınmasıdır. Bağlantı koparsa alarm çıkar, iş durur, ekip bakar. Yanlış veri aktarıldığında ise rapor bozulur, sipariş yanlış yönlenir, fatura hatalı kesilir, müşteri kaydı parçalanır, stok tutmaz. Fakat bunların nedeni hemen entegrasyona bağlanmaz.

Bu tür hataların etkisi zincirleme olur. Pazartesi sabahı satış temsilcisi CRM'de yeni müşterinin "Bireysel" yerine "Kurumsal" olarak açıldığını fark eder. Aynı müşteri için finans analisti ERP'de vergi numarasının yanlış alana yazıldığını görünce fatura oluşturamaz. İki ekip farklı belirtilerle uğraşsa da sorunun kaynağı aynı entegrasyondur. Destek ekibi müşterinin geçmişini eksik gördüğü için zayıf geri dönüş yapar. Regülasyona tabi veri akışlarında uyumluluk riski de doğar.

Çoğu ekip entegrasyon çalıştığı anda projeyi tamamlanmış kabul eder. Oysa asıl kontrol bundan sonra başlar. Canlıya geçmeden önce yanlış veri aktarımı ihtimallerini görünür hâle getirmezseniz sorunları üretim ortamında öğrenirsiniz.

Veri aktarım hatasını test etmek ne demektir?

Veri aktarım hatasını test etmek, kaynak sistemden hedef sisteme giden verinin doğru, tam, tutarlı ve beklenen formatta taşınıp taşınmadığını doğrulama sürecidir. “Veri geçti mi?” sorusundan fazlasına bakar. “Doğru kayıt mı geçti, doğru alana mı yazıldı, değer dönüşümü beklendiği gibi mi oldu, iş kuralları bozuldu mu?” gibi sorularla ilgilenir.

Teknik bağlantı testi ile veri aktarım testi aynı şey değildir. API’ye istek atıp 200 yanıtı almak, web kancasının (webhook) tetiklenmesi ya da iki sistemin birbirini görmesi yalnızca iletişimin kurulduğunu gösterir. Bu, iş açısından güvenilir veri akışı olduğu anlamına gelmez.

Bu testlerin amacı erken aşamada dört temel riski yakalamaktır:

• Veri kaybı: Bazı alanların hiç taşınmaması ya da kayıtların eksik gelmesi.
• Alan eşleşme hatası: Kaynaktaki bir alanın hedefte yanlış alana yazılması.
• Dönüşüm sorunu: Tarih, para birimi, kod, statü gibi değerlerin yanlış çevrilmesi.
• İş kuralı ihlali: Zorunlu alan, onay mantığı, statü geçişi gibi kuralların bozulması.

Entegrasyonun başarılı sayılması için sadece paketlerin taşınması yetmez, işlem sonucunun da doğru olması gerekir. Veri kalitesi yalnızca teknik bir konu değildir; doğrudan iş sonuçlarını etkiler. Gartner verilerine göre, entegre olmayan sistemlerin ve düşük veri kalitesinin organizasyonlara yıllık ortalama maliyeti 12,9 milyon doları buluyor. Bu nedenle entegrasyon projelerinde yalnızca bağlantının çalışması değil, aktarılan verinin doğruluğunun da sistematik olarak doğrulanması kritik önem taşır.

Süreç neden bozulur: Veri aktarım testleri neden çoğu ekipte yetersiz kalır?

Ekiplerin, API bağlantısı başarılıysa veri akışının da doğru olduğunu varsayması en yaygın sebeptir. Özellikle takvim sıkışıksa “kayıt karşıya düştü” notunu görmek rahatlatıcı gelir. Oysa kayıt düşmüş olabilir ama müşteri tipi yanlış eşlenmiş, sipariş tarihi saat farkı nedeniyle bir gün kaymış, zorunlu alan boş kaldığı için hedef sistem varsayılan bir değer atamış olabilir.

Uygulamada sorunların büyük kısmı şu noktalarda ortaya çıkar:

• Alan eşlemeleri: Benzer görünen alanlar yanlış bağlanır.
• Format dönüşümleri: Tarih biçimi, ondalık ayırıcı, karakter seti, telefon formatı sorun çıkarır.
• Zorunlu alanlar: Kaynakta opsiyonel olan veri, hedefte zorunlu olabilir.
• Varsayılan değerler: Hedef sistem boş gelen alanı otomatik doldurur ve hatayı gizler.
• Statü ve kod listeleri: Aktif/pasif bilgisi, ülke kodu, ürün kategorisi gibi değerler bire bir eşleşmeyebilir.

Çoğu ekip birkaç düzgün kayıtla test yapmanın yeterli olduğunu düşünür. Asıl problemler ise gerçek veriler geldiğinde ortaya çıkar. Beş düzgün kayıtla yapılan test yanıltır. Sahadaki veri temiz değildir; eski kayıtlar, tekrarlar, yarım bırakılmış formlar ve serbest metinler vardır.

İş birimlerinin doğrulamaya dâhil edilmemesi de tabloyu bozar. IT tarafı teknik olarak her şeyi doğru görürken satış, finans ya da operasyon “bu veriyle işlem yapılamaz” diyebilir. Zaman baskısıyla UAT kısa kesilir, negatif senaryolar atlanır, “canlıda bakarız” denir. Genelde pahalıya mal olan da budur.

Mini vaka

İstanbul merkezli bir üretici firmamın finans analisti, aylık rapordaki toplamların ERP ile uyuşmadığını fark etti. İlk incelemede muhasebe kayıtlarında sorun görünmüyordu. Daha sonra sipariş tarihinin saat dilimi dönüşümünde yapılan küçük bir hata nedeniyle bazı faturaların bir sonraki muhasebe dönemine kaydığı ortaya çıktı.

Bu vakanın da gösterdiği üzere, CRM ve ERP gibi sistemler arasında veri akışı yönetilirken alan eşleşmeleri, kayıt ilişkileri ve aktarım kurallarının kontrollü ele alınması kritik önem taşır. Bu süreçlerde veri taşıma ve senkronizasyon yaklaşımları için Bitrix24 CRM veri aktarımı kullanarak yüksek veri kontrolü elde edebilirsiniz.

Veri Aktarım Hatası Simülasyonu Kontrol Listesi ve Test Senaryosu

Kapsamlı ve adım adım kılavuzu almak için e-posta adresinizi girin.

You acknowledge that you have read and understood Bitrix24 Privacy Policy

Adım 1: Kritik veri akışlarını ve başarısızlık etkisini haritalayın

Her entegrasyonu aynı derinlikte test etmeye çalışırsanız odak dağılır. İlk haritalama çalışmasını çoğu projede BT ekibi hazırlar. Ancak müşteri kartının hangi alanlarının gerçekten kritik olduğunu genellikle finans ve satış ekipleri belirler.

Örneğin vergi numarasındaki tek bir hata finans için canlıya geçişi durdurabilecek kadar kritikken, pazarlama etiketi daha sonra düzeltilebilir. Başlangıç için müşteri, sipariş, teklif, fatura, stok hareketi ve iade kaydı gibi ana kayıtları belirleyin.

Her akış için şu dört soruyu cevaplayın:

1. Veri hangi sistemden çıkıyor?
2. Hangi sisteme gidiyor?
3. Hangi olay, akışı tetikliyor?
4. Tek yönlü mü, çift yönlü mü çalışıyor?

Sonra iş açısından kritik alanları öne alın. Pazarlama etiketi yanlış taşındığında sorun yönetilebilir olabilir ancak sipariş tutarı, fatura adresi, vergi numarası, stok kodu ya da teslim tarihi yanlış taşınırsa doğrudan operasyon etkilenir.

Amaç sadece akışı görmek değildir, hata olursa ne bozulur sorusunu açık hâle getirmektir. Test önceliği teknik karmaşıklığa göre değil de iş etkisine göre verilmelidir.

Operasyon örneği

İstanbul’da faaliyet gösteren bir üretim firmasının proje toplantısında entegrasyon ekibi tüm veri akışlarını aynı öncelikte test etmek istedi. Operasyon yöneticisi ise yalnızca stok ve sipariş akışındaki bir hatanın aynı gün sevkiyatları durduracağını belirtti. Bunun üzerine ekip test planını teknik karmaşıklığa göre değil, iş etkisine göre yeniden sıraladı ve böylece departmanlar arasındaki akışta ortaya çıkabilecek potansiyel darboğazların önüne geçti.

Adım 2: Doğruluk kriterlerini ve kabul eşiklerini yazılı hâle getirin

Haritayı çıkardıktan sonra sıra "doğru aktarım" ifadesinin ne anlama geldiğini netleştirmeye gelir. İlginç olan şu ki birçok projede bu tanım hiç yazılmaz. Bu adım atlanırsa herkes farklı bir başarı tanımıyla hareket eder. Geliştirici için veri paketinin gitmesi yeterli olabilir. Finans için küçük bir fark bile kabul edilemez. Operasyon içinse gecikmeli statü güncellemesi kritik olabilir.

Her kritik alan için en azından şu bilgileri yazın:

• Alan adı ve iş anlamı
• Beklenen format
• Zorunlu olup olmadığı
• Dönüşüm kuralı
• İzin verilen değerler
• Boş gelirse ne olacağı

Örneğin sipariş tarihi kaynakta “03.07.2026 14:30” formatında tutulurken, hedef sistem UTC zaman damgası (timestamp) bekliyor olabilir. Burada sadece biçimden ziyade zaman dilimi dönüşümü de kuralın parçasıdır. Müşteri tipi kaynakta serbest metinse hedefte kapalı bir kod listesine dönüştürülmesi gerekebilir.

Başarı kriterini “aktarıldı” yerine “doğru aktarıldı” olarak yazın ve örnek kabul eşikleri belirleyin:

• Kritik finans alanlarında hata toleransı: %0
• Statü güncelleme gecikmesi: en fazla 2 dakika
• Tekrarlı kayıt toleransı: sıfır
• Zorunlu olmayan açıklama alanlarında boş geçiş: belirli sınırlar içinde kabul

Kritik ve tolere edilebilir sapmalar yazılı ayrılmazsa test sonunda bitmeyen tartışmalar çıkar. Entegrasyon kabulü kanaate değil de önceden tanımlanmış ölçütlere dayanmalıdır. Entegrasyonlarda yalnızca veri aktarımı değil, doğru alanların doğru süreçlerle eşleşmesi de önemlidir. Otomasyon kuralları ve entegrasyon senaryolarını doğru uygulayan Türk işletmeler hem operasyonel verimliliklerini hem de gelirlerini artırmayı başarıyor.

Örnek Akış: CRM’den ERP’ye müşteri kartı entegrasyonu

Müşteri kartı aktarımında teknik olarak verinin gitmesi yeterli değildir, iş birimlerinin belirlediği kabul eşiklerine tam uyum aranır:

Adım 3: Gerçek hayattaki hataları yansıtan test senaryoları oluşturun

İyi bir senaryo seti kullanmak, canlı kullanımda karşılaşılabilecek problemleri test ortamında ortaya çıkarır. Sadece temiz örneklerle yapılan bir test ise entegrasyonu olabileceğinden daha güvenli gösterir. Senaryoları üç grupta kurun: normal durumlar, sınır durumlar ve kasıtlı bozuk veriler.

Normal senaryolar günlük iş akışını temsil eder; müşteri kaydı açılır, sipariş oluşur, statü değişir, fatura kesilir. Sınır durumlar ise maksimum karakter uzunluğu, çok satırlı adres, özel karakter içeren isim, yüksek tutarlı sipariş veya gece yarısına yakın zaman damgası gibi sorunlu alanları test eder.

Kasıtlı bozuk veriler kullanmak testin en dürüst kısmıdır. Özellikle şu senaryoları dâhil edin:

• Eksik zorunlu alan
• Bozuk tarih veya saat formatı
• Yinelenen müşteri ya da sipariş kaydı
• Geçersiz ülke, para birimi veya statü kodu
• Türkçe karakter veya karakter kodu sorunu
• Kaynakta boş kalan ama hedefte zorunlu olan alanlar
• Aynı kaydın güncelleme ve oluşturma mantığının karışması

Geçmiş hataları da senaryo havuzuna ekleyin. “Adresler ERP’ye parçalı düştü”, “iade statüsü CRM’ye yanlış yansıdı”, “aynı lead iki kez açıldı” gibi gerçek vakalar soyut risklerden daha değerlidir.

Adım 4: Testleri güvenli bir ortamda çalıştırın ve sonucu satır/alan düzeyinde karşılaştırın

Bu tür testleri asıl üretimde yapmak istemezsiniz. Üretime benzeyen ama izole bir ortam gerekir. Sistem sürümleri, entegrasyon kuralları, alan yapıları ve temel iş akışı davranışı canlı kullanıma yakın olmalıdır.

Bu noktada ekipler genellikle log ekranındaki "başarılı" mesajıyla yetinir. Oysa asıl soru işlemin tamamlanıp tamamlanmadığı değil, doğru sonuç üretip üretmediğidir. Doğrulama iki seviyede yapılmalıdır:

• Satır/alan düzeyi kontrol: Tek tek kayıtların doğru alanlara doğru değerlerle yazıldığını görmek.
• Toplu mutabakat: Kayıt sayısı, toplam tutar, statü dağılımı gibi genel sonuçların eşleştiğini kontrol etmek.

Karşılaştırma yaparken özellikle şu kontrolleri atlamayın:

• Kaynak ve hedefte kayıt sayısı aynı mı?
• Kritik alan değerleri, beklenen dönüşüm kuralına uyumlu mu?
• Güncellenmesi gereken kayıt güncellenmiş mi, yoksa yeni bir kayıt olarak mı açılmış?
• Zamanlama kabul sınırı içinde mi?
• Hatalı kayıtlar reddedilmiş mi, sessizce kabul mü edilmiş?

Örnek kayıt doğrulaması önemlidir. 10.000 siparişin çoğu doğru görünürken belirli bir ürün kategorisindeki kayıtlar bozuluyor olabilir. Sadece toplu sonuçlara bakarsanız bunları kaçırabilirsiniz. Fakat tersi de mümkündür, birkaç örnek doğru görünür ama toplu mutabakatta toplam tutar sapar.

Test sonunda kısa bir kontrol çıktısı üretin:

• Toplam işlenen kayıt
• Başarılı kayıt
• Reddedilen kayıt
• Uyarı alan kayıt
• Manuel inceleme gerektiren kayıt

Böylece teknik log ile iş etkisi aynı tabloda görünür.

Uygulama örneği

Satır ve alan düzeyinde pratik bir kontrol için iki sistemden alınan CSV çıktılarındaki toplam tutarlar eşleştirilebilir veya kritik alanların birleşimiyle oluşturulan “checksum” (MD5) değerleri kıyaslanabilir. SQL tarafında ise kaynak tablodan hedef tabloyu EXCEPT komutuyla çıkararak aradaki alan uyuşmazlıkları ve eksik satırlar tek bir sorguyla hızlıca tespit edilebilir.

"Pazarlama ve tanıtım için eksiksiz bir çözüm.\

Direktör ve Kıdemli Muhasebeci, Joarder Md Rezwan Hossain

TGlobal Accounting & Financial Services Pty Ltd. Australia

Ücretsiz kayıt

Adım 5: Hataları sınıflandırın, düzeltin ve güvenilirlik için süreci ölçekleyin

Testte bulunan her hatayı tek sepete atmak işi yavaşlatır, önce sınıflandırın. Çözüm sorumlusu ve tekrar etme riski ise hata tipine göre değişir.

• Eşleme hatası: Kaynaktaki alan, hedefte yanlış alana gidiyor.
• Dönüşüm hatası: Format, kod veya hesaplama yanlış çevriliyor.
• Veri kalitesi hatası: Kaynak veri eksik, kirli veya tutarsız.
• İş kuralı hatası: Statü, zorunlu alan onay mantığı bozuluyor.
• Performans hatası: Gecikme, kuyruk birikmesi, zaman aşımı yaşanıyor:

Her düzeltmeden sonra tekrar test yürütmek gerekir. Sadece düzelen senaryoyu değil, ilgili akışın çevresini de yeniden kontrol edin. Bir alanı düzeltirken başka bir dönüşüm kuralını bozmak sık görülür.

Süreçlerin sürdürülebilir olması için entegrasyon sonrası yalnızca hata düzeltmek değil, tekrar eden işleri otomatikleştirmek ve operasyonel görünürlüğü artırmak gerekir. Geleneksel yöntemlerde, bu çapta bir iş yükünü doğru yönetebilmek için büyük ve deneyimli ekipler gerekir. Fakat küçük ve orta büyüklükteki işletmeler artık yapay zekâ destekli Bitrix24 CRM çözümlerini kullanarak tekrar eden işleri kolayca otomatikleştirebilir.

Canlı kullanıma geçmeden önce minimum bir izleme seti tanımlayın:

• Hangi kritik akışlar günlük izlenecek?
• Hangi metrikler kontrol panelinde (dashboard) görünecek?
• Hangi hata oranına ulaşıldığında alarm tetiklenecek?
• Alarm kime düşecek?
• İlk incelemeyi kim yapacak, ne zaman escalation (yukarı aktarma) olacak?

Fallback davranışı (yedek akış) da tanımlı olmalıdır. Hatalı kayıt kuyrukta mı bekleyecek, karantinaya mı alınacak, manuel incelemeye mi düşecek? Bu tür hususları canlı kullanımda tartışmak istemezsiniz.

Ölçekleme tarafında hedef, testin kişiye bağımlı olmamasıdır. Senaryo seti, kabul kriterleri, kontrol tabloları ve izleme mantığı belgelenirse yeni akışlarda aynı disiplin tekrar uygulanabilir.

Örnek vaka

Ankara’da yerleşik bir destek ekibi her sabah aynı entegrasyon hatalarını manuel olarak yeniden işliyordu ve bu da hatırı sayılır miktarda iş yükü yaratıyordu. Hatalar sınıflandırılıp alarm kuralları tanımlandıktan sonra yalnızca kritik kayıtlar manuel incelemeye düştü, tekrarlayan operasyon yükü önemli ölçüde azaldı. Böylece destek ekibi müşterilere daha fazla vakit ayırıp daha yakın destek sunmak için ekstra zaman kazandı.

Sık yapılan hatalar ve mini vaka örneği

En sık görülen hata sadece sorunsuz akışı test etmektir. İkinci hata çok az örnek kullanmaktır. Üçüncü hata ise iş ekiplerini doğrulamaya katmamaktır. Teknik olarak geçen veri, iş açısından kullanılamaz olabilir.

Kullanabileceğiniz kısa bir kontrol listesi şöyle olabilir:

• Sadece başarılı örnekleri değil, bozuk veriyi de test edin.
• Kritik alanlar için sıfır tolerans gereken noktaları yazın.
• Geçmiş hata örneklerini senaryo setine alın.
• Log kontrolünü iş sonucu doğrulamasıyla birleştirin.
• Canlı öncesi alarm ve sahiplik modelini netleştirin.

Entegrasyon başarısı bağlantı kurmakla ölçülmez. Asıl başarı, yanlış aktarımı canlıya çıkmadan önce yakalayabilen disiplinli bir test süreci kurmaktır. Veri doğru taşınmıyorsa entegrasyon teknik olarak çalışıyor görünse bile iş tarafında başarısızdır.

Mini Vaka

Bir şirkette CRM'den ERP'ye aktarılan sipariş tarihlerinin UTC dönüşümünde yapılan küçük bir zaman dilimi hatası, ay sonuna denk gelen yüzlerce siparişin bir sonraki aya yazılmasına neden oldu. Entegrasyon teknik olarak sorunsuz çalışsa da son çeyrek satış raporları hatalı oluştu, finans ekibi raporları yeniden düzenlemek zorunda kaldı ve sorunun kaynağı ancak detaylı veri mutabakatı sonrasında ortaya çıktı.

Bu tür hatalar çoğu zaman sistemlerin çalışmamasından değil, yanlış verinin uzun süre doğru kabul edilmesinden kaynaklanır. Benzer sorunları önlemenin en etkili yolu ise kritik veri akışlarını düzenli olarak doğrulamak, kabul kriterlerini yazılı hâle getirmek, gerçek hayata yakın test senaryoları oluşturmak ve canlı ortamda sürekli izleme ile mutabakat kontrollerini standart sürecin bir parçası kılmaktır.

SSS

Gerçek müşteri verisi olmadan güvenilir test yapılır mı?

Evet. Ancak sentetik veri gerçek hayatı taklit etmelidir; bozuk format, tekrar eden kayıt, eksik alan gibi durumlar üretilmelidir. Gerekirse maskelenmiş gerçek veri desenleri kullanılır.

Kaç kayıt test etmek yeterlidir?

Sabit bir rakamdan ziyade riske dayalı bir alan kapsamı hedeflenmelidir. Yüksek hacimli veri yüklemek yerine; her ana veri tipi, sınır durumu ve hata ihtimali için ortalama 15-25 arası farklı profil belirleyip toplamda birkaç yüz kayıttan oluşan nitelikli bir test havuzuyla başlamak en ideal yaklaşımdır.

Üçüncü taraf araç olmadan karşılaştırma yapılabilir mi?

Evet. CSV dışa aktarımı, SQL sorgusu, temel makrolar veya tablolar ile temel karşılaştırmalar yapılabilir. Şart olan alan bazında tutarlı kontrol mantığıdır.

Canlıya ne kadar yakın bir ortam gerekir?

Mümkün olduğunca yakın. Veri modeli, entegrasyon kuralları, sürümler ve temel iş akışı davranışı benzer olmalıdır. Çok farklı test ortamı yanlış güven üretir.

Hatalar aralıklıysa nasıl yakalanır?

Tek seferlik test yetmez. Aynı senaryoyu farklı zamanlarda ve veri setleriyle tekrar çalıştırın. Kuyruk, zamanlama, eş zamanlı işlem ve yük altındaki davranış için tekrarlı test gerekir.