Test Verisi Çöplüğü: Bir Ekip Kendi Yarattığı Veride Nasıl Boğulur?
Seri 2: Sahadan Hatalar – Bölüm 2
Yazılım geliştirme süreçlerinde çoğu zaman kodun kendisine, mimariye veya pipeline konfigürasyonlarına odaklanılır. Ancak bir test mühendisinin günlük mesaisini en çok tüketen, sabrını en çok sınayan gizli bir canavar vardır: Test verisi.
Bir gün test ortamında koştuğumuz kritik bir ödeme akışının sürekli patladığını gördük. Kod tarafında hiçbir değişiklik yoktu, servisler ayaktaydı, konfigürasyonlar doğruydu. Saatler süren log incelemelerinin ardından karşımıza çıkan gerçek şuydu:
Test için kullandığımız "test_user_99" adlı kullanıcının cüzdan bakiyesi eksiye düşmüş, sepetinde aylar öncesinden kalma binlerce geçersiz ürün birikmiş ve statüsü başka bir ekibin denemesi sırasında "askıya alındı" olarak işaretlenmişti.
Yani sistem çökmemişti; sistem, üzerinde koşturduğumuz verinin ağırlığı altında ezilmişti.
Paylaşımlı Veritabanı ve "Benim Verim Senin Verini Bozdu" Kaosu
Pek çok şirkette test ortamları ortak bir havuz gibidir. Geliştirici oradadır, testçi oradadır, ürün yöneticisi demolarını orada yapar, hatta bazen entegrasyon yapan iş ortakları bile aynı veritabanına veri basar.
Bu ortamda disiplinli bir veri yönetimi kurgulanmamışsa, kaçınılmaz olarak bir "veri çöplüğü" oluşur.
Bir test mühendisi saatlerini harcayıp özel bir senaryo için veri hazırlar: Belirli statüde bir kullanıcı, ona bağlı bir sipariş, onaylanmış bir fatura. Tam testi koşturacağı sırada başka bir ekip arkadaşı aynı kullanıcının şifresini sıfırlar ya da siparişini iptal eder.
Sonuç? Sahte hatalar, boşa giden saatler ve toplantılarda birbirine "Veritabanındaki şu kaydı kim güncelledi?" diye soran sinirli insanlar.
Test verisini bağımsızlaştıramayan bir ekip, vaktinin yarısını test yapmaya değil, test yapabilmek için ortamı temizlemeye harcar.
Prod'dan Veri Kopyalama Kolaycılığı ve Gizli Tehlikeleri
Birçok ekibin bu kaostan kaçmak için başvurduğu ilk can simidi genelde şudur: "Prod veritabanının bir kopyasını test ortamına çekelim, her şey birebir olsun."
İlk bakışta mantıklı ve zahmetsiz gelir. Ancak sahadaki pratik, bu yöntemin arkasında devasa riskler barındırdığını çok geçmeden yüzünüze çarpar:
- Maskeleme Kusurları ve Güvenlik: Prod verisini anonimleştirmek (maskelemek) sanıldığı kadar basit değildir. Telefon numaralarını değiştirirsiniz ama adres satırında müşterinin adı kalır; kimlik numaralarını silersiniz ama sipariş notlarında kişisel veriler unutulur. Test ortamını bir KVKK riskine dönüştürmek an meselesidir.
- Kör Noktalar: Prod verisi zengindir ama çoğunlukla "başarılı" akışların izlerini taşır. Sizin test ederken en çok ihtiyaç duyduğunuz şey ise sınır durumlar, bozuk veriler, yarım kalmış işlemler ve istisnalardır. Prod kopyası size hacim sağlar ama aradığınız o kırılgan senaryoları sunmaz.
- Şişkinlik: Terabaytlarca veriyi test ortamlarında replike etmek hem altyapı maliyetini katlar hem de ortamların esnekliğini yok eder.
Çöplükten Çıkış: Kendi Verisini Yaratan ve Yok Eden Testler
Biz bu batağa birkaç kez saplandıktan sonra veri stratejimizi tamamen değiştirmek zorunda kaldık. Öğrendiğimiz en kritik ders şuydu: İyi bir test, başkasının bıraktığı veriye güvenmez; kendi ihtiyacını kendisi yaratır.
Bunu sağlamak için üç temel prensip benimsedik:
- İzole ve Dinamik Veri Üretimi: Test senaryosu başlamadan hemen önce API'lar veya factory yapıları aracılığıyla sıfırdan bir kullanıcı, sipariş ya da nesne oluşturulmalı. Test bittiğinde ise bu veri mümkünse silinmeli ya da statüsü pasife çekilmeli.
- Idempotent Senaryolar: Bir test seti aynı veritabanında peş peşe on kez koşsa bile, bir önceki koşumun bıraktığı artıklar bir sonrakini engellememeli.
- Veri Mock'lama Kültürü: Her senaryo için uçtan uca devasa veritabanı kayıtlarına bağımlı kalmak yerine, dış servisleri ve karmaşık durumları kontrollü bir şekilde mock'layarak testin odağını daraltmak.
Masadaki Ders
Test otomasyonu ya da manuel süreçler hakkında konuşurken genelde en süslü araçları, en yeni kütüphaneleri tartışmayı severiz. Ama günün sonunda o testlerin üzerinde koştuğu zemin veridir.
Zemini çürük bir binanın üzerine gökdelen dikemezsiniz.
Veri yönetimini bir mühendislik disiplini olarak ele almayan ekipler, en gelişmiş otomasyon altyapısına sahip olsalar bile, kendi yarattıkları veri çöplüğünde debelenmekten asla kurtulamazlar. Kalite, sadece kodu değil; o kodun işlediği veriyi de aynı titizlikle yönetebilmektir.
Serinin üçüncü bölümünde, hemen her ekibin en az bir kez uykusunu kaçıran o kritik eşiğe geçeceğiz: Prod’a Çıkış Gecesi Yaşananlar: En Kusursuz Plan Neden Patlar?
