1. GİRİŞ

Veri artık organizasyonların en değerli varlıklarından biri. Ancak verinin değeri, doğruluğu, güvenilirliği ve zamanında ulaşılabilirliğiyle doğrudan ilişkilidir. "Data Testing" yani veri testi, veri boru hatlarının (ETL/ELT), veri göllerinin, veri ambarlarının ve ML pipeline'larının üretime alınmadan önce ve üretimde iken beklenen kalitede olduğunu doğrulayan disiplinler bütünüdür. Bu makalede veri testi neden kritik, kimler için önemli ve hangi problemleri çözdüğü teknik bir bakışla ele alınacaktır.

Bu neden bugün önemli?

• ML modelleri ve raporlar yanlış veya eksik veriyle beslendiğinde yanlış kararlar alınır; finansal ve itibar riskleri ortaya çıkar.
• Büyük veri ve streaming senaryoları ile veri çeşitliliği arttı; manuel kontroller yeterli değil.
• Regülasyonlar, audit ve izlenebilirlik gerektirdiğinden veri doğruluğunun kanıtlanması önem kazandı.

Kimler için önemli?

• Veri mühendisleri ve MLOps ekipleri — pipeline güvenilirliğini sağlamak
• Veri bilimciler — eğitim verilerinin kalitesini doğrulamak
• Ürün ve iş birimleri — KPI'ların güvenilirliğini garanti etmek
• SRE ve platform ekipleri — data‑driven servislerin stabilitesini korumak

2. KAVRAMSAL TEMELLER

2.1 Data testing nedir?

Data testing, verinin beklenen yapıda, tutarlı, eksiksiz ve doğru olduğunu otomatik veya yarı‑otomatik testler aracılığıyla doğrulama pratiğidir. Yazılım testlerine benzer şekilde, veri için bir test piramidi düşünülebilir: birim testler (record level checks), entegrasyon testleri (pipeline/transform doğrulama), end‑to‑end testler (source ⇒ sink reconciliation) ve kabul testleri (business validation).

2.2 Temel terminoloji

• Schema validation: Veri sütunlarının tip, zorunluluk ve isim açısından beklenen yapıyla eşleşmesi.
• Row count reconciliation: Kaynak vs hedef arasında beklenen satır sayısının doğrulanması.
• Data quality checks: Null oranı, benzersiz değer sayısı, min/max, dağılım testleri gibi kontroller.
• Contract tests / data contracts: Üretici‑tüketici arasında veri sözleşmesi; değişiklikler PR ile kontrol edilir.
• Canary tests: Küçük bir gerçek veri seti ile pipeline'ı test etme yaklaşımı.

2.3 Data test piramidi

1. Unit tests (record‑level): Fonksiyonların dönüş değerleri, örn. transform fonksiyonu beklenen formatta çıktı veriyor mu?
2. Integration tests: Bir job'ın veya task grubunun birbirleriyle düzgün çalışması — join, aggregation, write semantics.
3. End‑to‑end tests: Kaynaktan hedefe tam akış; reconciliation ve SLA doğrulaması.
4. Acceptance / Business tests: İş takımlarının beklediği KPI veya metrik kontrolleri; ör.: günlük aktif kullanıcı sayısı artışına bağlı iş senaryoları.

3. NASIL ÇALIŞIR?

3.1 Sistem mimarisi ve bileşenler

Data testing çözümü genelde şu bileşenleri içerir: test definition repository (kod/SQL/DSL), runner/orchestrator (Airflow/Prefect/Dagster entegrasyonu), assertion engine (Great Expectations, Deequ, custom assertions), benchmark & golden datasets (referans veriler), reporting & alerting (Slack, email, ticketing) ve governance (test coverage, ownership metadata).

3.2 Test tanımları ve sürümleme

Testler kod olarak tutulmalı (test as code). SQL, YAML veya özel DSL ile testlerin versiyonlanması, PR tabanlı değişiklik kontrolü ve CI pipeline'larda çalıştırılması gerekir. Örneğin bir transform PR'ı açıldığında ilgili data contract ve schema testleri otomatik çalıştırılmalı; başarısızsa PR reddedilmelidir.

3.3 Veri örnekleme ve golden dataset'ler

Test veri setleri (golden datasets) hem unit/integration testler için hem de canary testleri için kullanılmalıdır. Golden dataset'ler deterministik olmalı ve veri çeşitliliğini temsil etmelidir: edge case'ler, null değerler, büyük string’ler, tarih sınırları vb. Ayrıca dataset'lerin versiyonlanması ve erişilebilir olması gerekir.

3.4 Assertion türleri

• Structural assertions: Schema, column existence, datatype checks.
• Statistical assertions: Null ratio, distinct count, distribution change detection (KL divergence, PSI).
• Business assertions: KPI thresholds, monotonicity (ordering), referential integrity.
• Behavioral assertions: Idempotency, at‑least‑once/ exactly‑once semantics.

3.5 Test orchestration — ne zaman çalıştırılır?

• CI zamanında: Kod değişiklikleri (transform, schema) PR aşamasında test edilir.
• Pre‑production / staging: Canary ve end‑to‑end testler release pipeline'ında çalıştırılır.
• Production: Periyodik profil testleri, freshness ve reconciliation job'ları çalıştırılır; kritik sapmalarda alert tetiklenir.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Netflix — veri doğrulama ve canary pattern

Büyük ölçekli streaming platformlarda veri değişiklikleri küçük gecikmeler ve büyük etkiler yaratır. Netflix benzeri organizasyonlar canary pattern uygulayıp yeni transform kodunu limitli dataset üzerinde test eder; golden dataset ile sonuçlar doğrulanınca genişletir. Ayrıca model eğitim veri setleri için reproducibility testleri (snapshot comparison) rutin hale getirilir.

4.2 Uber — realtime assertions ve SLA'lar

Uber gibi düşük latency gerektiren ürünlerde, streaming assertions (event schema, timestamp monotonicity, lag thresholds) üretimde gerçek zamanlı olarak çalışır. Ayrıca row count reconciliation ve checkpoint monitoring SLA'ların bir parçasıdır.

4.3 Finans (Stripe) — reconciliation ve immutability

Ödeme platformlarında reconciliation kritik bir görevdir: kaynak bankaların raporları ile platform raporlarının tutarlı olması zorunludur. İmmutable audit log'lar (append‑only) ve otomatik reconciliation job'ları veri testi sürecinin merkezindedir.

4.4 ML pipeline'larda test stratejileri (OpenAI örneği)

ML pipeline'larda veri testleri, feature'ların kalite kontrolünden label doğruluğuna kadar uzanır. Feature validation, label leakage kontrolü, train/validation distribution karşılaştırmaları ve model input contract testleri (shape, dtypes, nullability) production öncesi zorunlu olmalıdır.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Erken hata yakalama: Testler CI/CD ile entegre çalıştığında hatalar üretime gitmeden yakalanır.
• Güven ve hız: İş ekipleri raporlara güvenir, veri ekipleri daha hızlı iterasyon yapar.
• Uyumluluk kanıtı: Testler audit için kanıt sağlar; regülasyon uyumu kolaylaşır.

Sınırlamalar

• Test bakım maliyeti: Test tanımlarının güncel tutulması dersektir; schema değişimleri yüksekse workload artar.
• False positive/negative: Zayıf tune edilmiş kontroller operational yükü artırabilir.
• Ölçeklenebilirlik: Büyük veri iş yüklerinde tam veri doğrulama maliyetli olabilir; sampling ve stratejik testleme gerekir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

Aşağıdaki tablo veri testi yaklaşımlarını karşılaştırır:

7. EN İYİ PRATİKLER

7.1 Development & CI/CD

• Test as code: Tüm veri testleri versiyonlanmış kod deposunda tutulmalı ve PR sürecinde otomatik çalıştırılmalıdır.
• Fast unit tests: Dönüş hızını korumak için küçük, deterministik unit test'ler oluşturun.
• Integration tests in staging: Gerçek veriye yakın staging ortamında end‑to‑end testler yapılmalı.

7.2 Production monitoring ve alerting

• Automated reconciliation: Scheduled job'lar ile kaynak ve hedef tutarlılığı periyodik doğrulansın.
• Freshness SLOs: Veri akışının tazeliği için SLO tanımları ve SLA izleme.
• Alert runbooks: Her test hatası için triage adımları ve owner'lar net olmalı.

7.3 Data privacy & security

• Masking & sampling: Test veri setlerinde PII ve hassas veriler maskelenmeli; sampling temsili olmalı.
• Access control: Test altyapısına erişim limitlenmeli ve audit edilmelidir.
• Contract testing: Üretici‑tüketici sözleşmeleri (schema contracts) CI'da doğrulansın.

8. SIK YAPILAN HATALAR

• Testleri sonradan eklemek: Başlangıçta test stratejisi belirlememek uzun vadede maliyeti artırır.
• Yetersiz oracle (golden) veri: Testlerin beklenen sonucu belirleyecek güvenilir referans eksikliği.
• Threshold'ları sabit tutmak: Mevsimsellik veya büyüme ile eşiklerin yeniden değerlendirilmemesi yanlış alarmlara neden olur.
• Owner ve runbook eksikliği: Alarm geldiğinde kimin ne yapacağı net değilse MTTR artar.

9. GELECEK TRENDLER

9.1 AI destekli data testing

AI modelleri anomaly detection, data lineage scoring ve otomatik test önerileri sunmak için kullanılacak. Örneğin, model bazlı test generator'lar geçmiş incident'leri öğrenip yeni assertion'lar önerebilir.

9.2 Contract‑first development

Data contracts, schema registry ve PR tabanlı kontrol mekanizmaları daha yaygın hale gelecek. Değişiklikler kod review sürecine entegre olarak veri kalitesinin korunmasına yardımcı olacak.

9.3 Standardizasyon ve tekilleştirilmiş test katalogları

Organizasyonel ölçekte ortak test kütüphaneleri, golden dataset registries ve test metadata katalogları ortaya çıkacak; bu da test reuse ve coverage takibini kolaylaştıracak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Data testing nereden başlamalı?

   Kritik veri setleriyle başlayın (finans, satış, KPI kaynakları). Basit row count, schema ve null rate testleriyle pilot kurun; sonra kapsamı genişletin.

2. 2. Hangi araçlar önerilir?

   Great Expectations, Deequ, Soda, Monte Carlo, dbt tests, pytest‑based frameworks ve custom SQL test runner'lar yaygın kullanılır. Seçim organizasyonun ihtiyaçlarına göre yapılmalıdır.

3. 3. Golden dataset nasıl yönetilmeli?

   Versiyonlanmış, küçük ama temsili setler oluşturun; erişimi kontrol edin ve otomatik güncelleme politikaları belirleyin.

4. 4. Testleri CI'ya nasıl entegre ederim?

   PR pipeline'larında transform testlerini, schema validation'ı ve unit assertion'ları çalıştırın; staging ortamında end‑to‑end testleri tetikleyin.

5. 5. Production'da full validation mı yoksa sampling mi?

   Full validation maliyetli olabilir. Önem derecesine göre hybrid yaklaşım kullanın: kritik dataset'lerde full, diğerlerinde akıllı sampling.

6. 6. False positive'leri nasıl azaltırım?

   İstatistiksel testler, mevsimselliği gözeten modeller ve dynamic thresholds kullanın; ayrıca alert suppression ve eskalasyon politikaları ekleyin.

7. 7. Contract test nedir?

   Üretici‑tüketici arasında beklenen schema ve semantic sözleşmenin kod veya manifest olarak tutulmasıdır. Değişiklik PR ile yönetilir.

8. 8. Veri testi ekibi nasıl yapılandırılmalı?

   Cross‑functional: veri mühendisleri, veri bilimciler, SRE ve domain owner'lar birlikte çalışmalı; ownership ve SLA'lar net tanımlanmalı.

Anahtar Kavramlar

• Golden dataset: Test için kullanılan referans veri seti.
• Contract testing: Üretici ile tüketici arasında veri sözleşmesi testleri.
• Reconciliation: Kaynak ve hedef veri tutarlılığını karşılaştırma.
• Sampling: Büyük veri setlerinde temsili kontrol için örnek seçme stratejisi.

Öğrenme Yol Haritası

1. 0–1 ay: SQL, temel istatistik, veri kalite temel kavramları ve ETL/ELT akışlarını öğrenin.
2. 1–3 ay: Great Expectations veya Deequ ile temel assertion'lar oluşturun; küçük bir pipeline için end‑to‑end test kurun.
3. 3–6 ay: Canary pattern, golden dataset yönetimi, sampling stratejileri ve CI entegrasyonları üzerinde pratik yapın.
4. 6–12 ay: AI‑based anomaly detection, contract testing, production reconciliation ve governance otomasyonları ile deneyim kazanın.