Cevap.

Test verilerinin yönetimi, otomasyonun en eski sorunlarından biridir. Otomasyona başlangıçta (Excel'de test senaryoları, makrolar, eski QTP) veriler çoğu zaman test yazarının "başında" veya doğrudan kodun içinde "bulunuyordu". CI/CD'nin ve paralel çalıştırmaların gelişimi yeni stratejiler gerektiriyordu: birden fazla testin aynı verileri eşzamanlı kullanırken yarışları nasıl önleyebiliriz ve sonuçların tekrarlanabilirliğini nasıl sağlayabiliriz?

Sorun: paylaşılan (shared) test verileri hızlı bir şekilde çakışmalara ve öngörülemeyen sonuçlara yol açar. Testler istikrarsız hale gelir, hata ayıklama zordur, veri parçaları "kirletir" veritabanlarını, çoklu iş parçalarında çalıştırma hatalara (data race) yol açar.

Çözüm — "test başına veri" (Test Data Per Test) stratejilerinin uygulanması:

Her test için benzersiz veya parametreli test verilerinin kullanımı
Testten önce ve sonra veri oluşturma/temizleme (setup/teardown, fixture)
Namespace'ler, tenant'lar, kullanıcılar yoluyla test ortamlarının ayrılması
Test başına yeniden başlatma ile in-memory veritabanları kullanma

Anahtar özellikler:

Benzersiz veri oluşturma (UUID, zaman damgası), testin ardından otomatik silme
Test veri fabrikalarının (Test Data Factories) kullanımı
İzole edilmiş sandbox ortamları ile çalışma

İkna edici Sorular.

Üretim verilerini test verisi olarak kullanmak normal mi?

Hayır! Güvenlik, gizlilik riski taşımakla birlikte, veri değişkenliği nedeniyle testlerin öngörülemezliğine yol açar.

Verileri temizlemek için setUp ve tearDown kullanmak yeterli mi?

Her zaman değil. Riskleri azaltmaya yardımcı olurlar, ancak paralel çalıştırmalar testleri çarpışmaya sokabilir, eğer veriler küresel kalır veya benzersiz hale getirilmezse.

Aynı test verilerini smoke ve regresyon senaryolarında kullanmak mümkün mü?

Daha iyi olur — hayır. Smoke testleri mümkün olduğunca bağımsız olmalı ve regresyon ise kapsamlı veri hazırlığı gerektirir, aksi takdirde yanıltıcı sonuçlar olabilir.

Tipik Hatalar ve Antipatternler

Birden fazla teste rastgele uyan genel, "sihirli" verilerin kullanımı
Test sonrası temizlenmeyen veri kalıntıları
Tüm testlerde aynı kayıtların çift kullanımı

Hayattan Bir Örnek

Negatif Durum

Şirketin bir ortak girişi ve tüm otomatik testlerde kullanılan birkaç "paylaşılan" kullanıcı ve sipariş vardı. Paralel bir çalıştırma, testlerin birbirinin siparişlerini silmesine veya bir siparişin durumunu birkaç iş parçasında değiştirmesine yol açtı.

Artılar:

Az sayıda testte hızlı ve basit uygulanabilir
Ek altyapı gerektirmez

Eksiler:

Belirsiz çökme, hata ayıklama zorlukları
Testleri paralel veya farklı ortamlarda güvenli bir şekilde çalıştırmak imkansız

Pozitif Durum

Test veri fabrikaları kuruldu: her senaryo için testten önce benzersiz bir sipariş ve kullanıcı yaratılıyor, testten sonra siliniyordu ve sandbox ortamı yeniden başlatılıyordu.