Bir sigorta acentesi yazılımında test yapmak isteyen her ekip, er ya da geç aynı ikilemle karşılaşır: Gerçekçi testler için gerçekçi veri gerekir; ancak gerçek müşteri verisi kişisel veridir ve test ortamlarında dolaşmaması gerekir. Kimlik numaraları, iletişim bilgileri, araç plakaları ve adresler, test kolaylığı uğruna riske atılabilecek bilgiler değildir. Test verisi yönetimi, bu ikilemi çözen yöntemler bütünüdür.
InsureHub olarak acentelerin bize emanet ettiği verinin yalnızca canlı ortamda ve yetkili erişimle kullanılmasını bir ilke olarak görüyoruz. Bu yazıda bu ilkenin test süreçlerinde nasıl uygulanabileceğini anlatıyoruz.
Neden üretim verisinin kopyası kullanılmamalı?
- Hukuki yükümlülük: Kişisel verilerin işlenme amacı ve erişim kapsamı sınırlıdır. Test, verinin toplanma amacına girmez.
- Genişleyen saldırı yüzeyi: Test ortamları genellikle canlı ortam kadar sıkı korunmaz; daha fazla kişi erişir, daha fazla araç bağlanır.
- Kazara iletişim riski: Gerçek telefon numaraları ve e-posta adresleri içeren bir test ortamında, bildirim testleri gerçek müşterilere mesaj gönderebilir.
- Kontrolsüz kopyalar: Bir kez çoğaltılan veri, geliştirici bilgisayarlarına ve paylaşılan dosyalara yayılabilir.
Üç temel yöntem
Sentetik veri üretimi
Sentetik veri, hiçbir gerçek kişiye ait olmayan ama gerçek verinin yapısını ve kurallarını taşıyan veridir. Kimlik numarası alanı, doğrulama algoritmasına uyan ama kimseye ait olmayan değerlerle doldurulur. Plaka alanı geçerli biçimde ama kurgusal olarak üretilir. DASK testleri için adresler, yapı tarzı ve inşa yılı gibi alanların gerçekçi dağılımlarıyla oluşturulur.
Sentetik verinin gücü, uç durumları bilinçli olarak üretebilmesidir. Çok uzun bir ad, eksik bir adres satırı, ruhsat bilgisinde alışılmadık bir kombinasyon; bunlar gerçek veride nadiren karşılaşılan ama yazılımın doğru ele alması gereken durumlardır.
Maskeleme ve anonimleştirme
Bazı analizler, örneğin bir performans sorununun gerçek veri dağılımında tekrar üretilmesi, sentetik veriyle yeterince temsil edilemeyebilir. Bu durumlarda veri, test ortamına taşınmadan önce maskelenir. Kişiyi tanımlayan alanlar geri döndürülemez biçimde değiştirilir, ilişkiler korunur ama kimlik ortadan kalkar. Maskelemede dikkat edilmesi gereken nokta, birden fazla alanın bir araya gelerek kişiyi yeniden tanımlanabilir kılmamasıdır.
Ortam ayrımı ve erişim sınırı
Hangi yöntem kullanılırsa kullanılsın, geliştirme, test ve canlı ortamların birbirinden ayrı olması temel koşuldur. Her ortamın kendi veritabanı, kendi kimlik bilgileri ve kendi dış servis bağlantıları olmalıdır. Test ortamındaki bir yapılandırmanın yanlışlıkla canlı veritabanına bağlanması, en iyi maskeleme stratejisini bile anlamsız kılar.
Dış servislerde test verisi
Sigorta şirketi servisleri ve EGM gibi resmî sorgular test ortamında ayrı bir dikkat gerektirir. Bu servislere test ortamından gerçek kişilere ait bilgilerle sorgu atılmamalıdır. Bunun yerine sağlayıcının sunduğu test uç noktaları, kaydedilmiş örnek yanıtlar ya da bu yanıtları taklit eden sahte servisler kullanılır. Böylece trafik, kasko ve DASK akışlarının her biri, kendi beklediği yanıt yapısıyla gerçek bir sorgu yapılmadan test edilebilir.
İyi bir test veri setinin özellikleri
- Tekrar üretilebilir: Aynı komutla her seferinde aynı başlangıç durumu oluşturulabilir.
- Sürümlü: Veri şeması değiştiğinde test verisi de birlikte güncellenir.
- Belgelenmiş: Hangi kurgusal müşterinin hangi senaryoyu temsil ettiği açıktır; örneğin "aktif kasko poliçesi olan ve yenilemesi yaklaşan bireysel müşteri".
- Küçük ama kapsayıcı: Gereksiz büyüklükte değil, ama önemli uç durumları içerecek çeşitlilikte.
- Kendini temizleyen: Testlerin oluşturduğu kayıtlar iş bittikten sonra kaldırılır.
Demo ve eğitim ortamları
Test verisi yönetiminin acenteleri doğrudan ilgilendiren bir yüzü de demo ve eğitim ortamlarıdır. Yeni bir ekip üyesine yazılımı tanıtırken ya da bir acente yazılımı değerlendirirken kullanılan ortamlarda da gerçek müşteri bilgisi bulunmamalıdır. Gerçekçi ama kurgusal bir veri seti, CRM ekranlarının, teklif geçmişinin ve raporların nasıl görüneceğini risk yaratmadan gösterir. Bir demo hesabı talep ettiğinizde karşınıza çıkan verinin bu şekilde hazırlanmış olması beklenir.
Acenteler için kontrol soruları
Yazılım sağlayıcınızın verinizi nasıl koruduğunu anlamak için şu sorular yol gösterici olabilir:
- Test ve geliştirme ortamlarında gerçek müşteri verisi bulunuyor mu?
- Bir hata incelemesi için veriye erişim gerektiğinde bu erişim nasıl yetkilendiriliyor ve kayıt altına alınıyor?
- Bildirim testleri gerçek kişilere mesaj gönderme riskine karşı nasıl izole ediliyor?
Bu soruların net yanıtları, acente yazılımının veri güvenliğine yalnızca canlı ortamda değil, geliştirme sürecinin tamamında önem verdiğini gösterir.
Test verisini kod gibi yönetmek
Test verisinin elle hazırlanıp bir dosyada saklanması, kısa sürede bakımı zor bir yapıya dönüşür. Daha sürdürülebilir yöntem, test verisini üreten kodun da yazılımla birlikte tutulmasıdır.
Tohumlama betikleri
Boş bir ortamı tanımlı bir başlangıç durumuna getiren betiklerdir. Örnek acenteler, şubeler, farklı yetkilere sahip kullanıcılar ve her branştan kurgusal teklif geçmişi bu betiklerle oluşturulur. Yeni bir geliştirici tek bir komutla çalışır bir ortama sahip olur.
Fabrika fonksiyonları
Testler içinde ihtiyaç duyulan kayıtları anlamlı varsayılanlarla üreten küçük yardımcılardır. Bir test yalnızca "yenilemesi yaklaşan kasko poliçesi olan müşteri" ister; geri kalan tüm alanlar fabrika tarafından geçerli değerlerle doldurulur. Böylece test, yalnızca kendisi için önemli olan ayrıntıyı belirtir ve okunabilirliği artar.
Bu iki araç birlikte kullanıldığında, şema değiştiğinde güncellenmesi gereken tek bir yer olur ve test verisi yazılımla birlikte gelişir.
Bu yaklaşımın güvenlik açısından da bir kazanımı vardır: Test verisinin nereden geldiği her zaman bellidir. Bir ortamda beklenmedik bir kayıt görüldüğünde, bunun tohumlama betiğinden mi yoksa başka bir kaynaktan mı geldiği hızla anlaşılır. Kaynağı belirsiz verinin olmaması, gerçek müşteri bilgisinin test ortamlarına sızmasını da zorlaştırır.
Sonuç
Gerçekçi test ile kişisel verinin korunması birbirine rakip hedefler değildir. Sentetik veri, gerektiğinde maskeleme ve katı ortam ayrımı birlikte uygulandığında, yazılım kapsamlı biçimde test edilirken müşteri bilgisi yalnızca ait olduğu yerde kalır.