Sigorta yazılımlarında test otomasyonu ve kalite güvence nasıl kurulur?

Test otomasyonu, yazılımın beklenen şekilde çalıştığını doğrulayan test senaryolarının insan müdahalesi olmadan, tekrarlanabilir biçimde ve her kod değişikliğinde çalıştırılması demektir. Sigorta yazılımlarında bu yaklaşım bir lüks değil zorunluluktur; çünkü tek bir tarife parametresindeki hata binlerce poliçenin yanlış primle üretilmesine, tek bir entegrasyon hatası ise SBM bildirimlerinin aksamasına yol açabilir.

Kalite güvence (Quality Assurance, QA) ise yalnızca test yapmak değil, hataların oluşmasını önleyen süreçlerin bütünüdür: gereksinimlerin doğrulanması, kod incelemesi, test stratejisi, ortam ve veri yönetimi. Bu yazıda sigorta yazılımlarına özgü test alanlarını, otomasyonun hangi katmanlarda kurulacağını ve adım adım uygulama planını ele alıyoruz.

Sigorta yazılımlarını test etmek neden farklıdır?

Sigorta yazılımları, yoğun hesaplama kuralları, uzun yaşam döngülü kayıtlar ve çok sayıda dış entegrasyonu aynı anda barındırdığı için standart iş uygulamalarından daha zor test edilir. Bir poliçe yıllar boyunca zeyil, yenileme, hasar ve iptal hareketleri alabilir; her hareket prim, komisyon ve muhasebe kayıtlarını etkiler.

Sigortaya özgü başlıca zorluklar şunlardır:

• Hesaplama yoğunluğu: Tarifeler çok sayıda risk faktörü, indirim, sürprim ve yuvarlama kuralı içerir. Küçük bir sıralama değişikliği bile sonucu değiştirebilir.
• Zamana bağlı mantık: Gün esaslı prim iadesi, vade farkı, yenileme ve geçmiş tarihli zeyiller, test senaryolarında tarih kontrolü gerektirir.
• Ürün çeşitliliği: Her yeni ürün veya tarife versiyonu yeni test kombinasyonları demektir.
• Dış bağımlılıklar: SBM, TRAMER, kimlik doğrulama servisleri, ödeme sistemleri ve acente yazılımları test ortamında her zaman erişilebilir değildir.
• Mevzuat etkisi: Zorunlu sigortalardaki düzenleme değişiklikleri kısa sürede ve hatasız uygulanmalıdır.
• Kişisel veri: Gerçek müşteri verisinin test ortamında kullanılması KVKK açısından ciddi risk taşır.

Test piramidi sigorta yazılımına nasıl uygulanır?

Test piramidi, çok sayıda hızlı birim testin tabanda, daha az sayıda entegrasyon testinin ortada ve en az sayıda uçtan uca testin tepede yer aldığı bir test dağılım modelidir. Sigorta yazılımında bu piramidin merkezine tarife ve iş kuralı testleri eklenmelidir.

Uçtan uca testlerin sayısı sınırlı tutulmalıdır. Kullanıcı arayüzü üzerinden yürüyen testler kırılgandır ve yavaştır; tarife doğruluğu gibi konular arayüz yerine servis veya kural katmanında test edilmelidir.

Tarife ve fiyatlama testleri nasıl otomatikleştirilir?

Tarife testlerinin en güvenilir yöntemi, aktüerya ekibi tarafından onaylanmış bir referans veri setiyle (golden dataset) otomatik karşılaştırmadır. Her satırda risk girdileri ve beklenen prim yer alır; sistem aynı girdilerle hesaplama yapar ve sonuçlar tolerans içinde eşleşmezse test başarısız olur.

Bu yaklaşımı güçlendiren uygulamalar:

• Sınır değer senaryoları: Yaş, araç değeri, bina metrekaresi gibi faktörlerde basamak geçişlerini mutlaka kapsayın.
• Kombinasyon testleri: Tüm kombinasyonları denemek mümkün olmadığında ikili kombinasyon (pairwise) tekniğiyle anlamlı bir alt küme seçin.
• Versiyon karşılaştırması: Yeni tarife versiyonunu eski versiyonla aynı portföy örneği üzerinde çalıştırıp farkların beklenen etkiyle uyumlu olduğunu doğrulayın.
• Yuvarlama ve vergi kontrolü: Gider vergisi, katkı payları ve yuvarlama kurallarını ayrı senaryolarla test edin.

Fiyatlama motorunun mimarisi hakkında ayrıntı için sigorta fiyatlama motoru yazısına bakabilirsiniz. Kural tabanlı bir motor kullanıldığında test senaryoları da iş birimlerinin okuyabileceği tablolar olarak tutulabilir; bu, aktüerya ile yazılım ekibi arasındaki doğrulama döngüsünü kısaltır.

Entegrasyon testleri SBM ve diğer dış sistemler için nasıl kurgulanır?

Dış sistem entegrasyonları, taklit servisler (mock), sözleşme testleri ve karşı tarafın test ortamıyla yapılan kontrollü testlerin birleşimiyle doğrulanır. Amaç, dış sistem erişilemez olduğunda bile ekibin kendi tarafını güvenle test edebilmesidir.

• Taklit servisler: SBM ve TRAMER gibi servislerin beklenen yanıtlarını, hata kodlarını ve zaman aşımlarını taklit eden sanal servisler kurun.
• Sözleşme testleri: Mesaj alanlarının, zorunlu bilgilerin ve kod listelerinin karşı tarafın beklediği formatla uyumunu her derlemede doğrulayın.
• Hata senaryoları: Zaman aşımı, tekrar deneme, eksik yanıt ve mükerrer gönderim durumlarını mutlaka test edin.
• Mutabakat testleri: Gönderilen ve kabul edilen kayıtların sayı ve tutar olarak eşleştiğini kontrol edin.

Entegrasyon mimarisinin genel ilkeleri için sigorta API entegrasyonu rehberi tamamlayıcıdır.

Test verisi KVKK'ya uygun şekilde nasıl yönetilir?

Test ortamlarında gerçek müşteri verisi yerine maskelenmiş, anonimleştirilmiş veya sentetik veri kullanılmalıdır. 6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK), kişisel verinin amaçla sınırlı ve ölçülü işlenmesini gerektirir; üretim verisinin kopyalanıp geniş bir ekibin erişimine açılması bu ilkelerle bağdaşmaz.

Pratik bir test verisi stratejisi şu unsurları içerir:

• Kimlik numarası, ad, adres, telefon ve plaka gibi alanların geri döndürülemez şekilde maskelenmesi
• Sağlık ve hasar detayları gibi özel nitelikli verilerin test ortamına hiç taşınmaması veya sentetik veriyle değiştirilmesi
• Tarife testleri için gerçek portföyün dağılımını yansıtan ama kişiye bağlanamayan sentetik veri üretimi
• Test verisinin sürümlenmesi ve her test koşusunda aynı başlangıç durumuna dönülebilmesi
• Test ortamlarına erişimin rol bazlı kısıtlanması ve kayıt altına alınması

Bu konunun hukuki ve teknik boyutları KVKK uyumlu sigorta yazılımı yazısında ayrıntılı olarak ele alınıyor.

Test otomasyonunun değeri test sayısıyla değil, bir değişikliğin güvenle üretime alınabileceğine dair verdiği güvenin hızıyla ölçülür.

Sigorta yazılımında test otomasyonu adım adım nasıl kurulur?

Otomasyon, en yüksek riskli ve en sık tekrar eden alanlardan başlanarak aşamalı kurulmalıdır. Her şeyi aynı anda otomatikleştirmeye çalışmak, bakımı zor ve güvenilmez bir test havuzu üretir.

1. Risk haritası çıkarın. Hangi süreç hata verdiğinde en büyük finansal, müşteri veya mevzuat etkisi doğuruyor, belirleyin. Genellikle tarife, poliçeleştirme ve tahsilat ilk sıradadır.
2. Referans veri setlerini oluşturun. Aktüerya ve ürün ekipleriyle birlikte onaylı tarife senaryolarını hazırlayın.
3. Servis katmanı testlerini yazın. Teklif, poliçe, zeyil ve hasar servisleri için API testleri kurun.
4. Taklit servisleri devreye alın. Dış sistem bağımlılıklarını test ortamında izole edin.
5. Test verisi yönetimini kurun. Maskeleme ve sentetik veri üretim süreçlerini otomatikleştirin.
6. Sürekli entegrasyon hattına bağlayın. Testleri CI/CD (Continuous Integration / Continuous Delivery) hattında her değişiklikte çalıştırın ve başarısız testte dağıtımı durdurun.
7. Kritik uçtan uca akışları ekleyin. Yalnızca en önemli kullanıcı yolculuklarını arayüz testleriyle kapsayın.
8. Performans testlerini planlayın. Yenileme dönemleri, kampanyalar ve ay sonu gibi yoğun dönemleri simüle edin.
9. Ölçün ve iyileştirin. Kapsam, hata kaçış oranı ve test süresini düzenli izleyin; kırılgan testleri onarın veya kaldırın.

ProdayTech olarak sigorta projelerinde tarife ve kural testlerini, geliştirme başlamadan önce iş analistleri ve aktüerya ekibiyle birlikte kabul kriteri olarak tanımlamayı tercih ediyoruz; böylece test, gereksinimin doğrudan bir parçası haline geliyor. Gereksinim tarafı için sigorta projelerinde iş analizi yazısına göz atabilirsiniz.

Kalite güvence için kontrol listesi

• Tarife ve fiyatlama için onaylı referans veri seti var mı?
• Her kod değişikliğinde birim ve servis testleri otomatik çalışıyor mu?
• Dış sistemler için taklit servisler ve sözleşme testleri kuruldu mu?
• Test ortamlarında gerçek kişisel veri kullanılmıyor mu?
• Zamana bağlı senaryolar için sistem tarihi kontrol edilebiliyor mu?
• Yoğun dönemler için performans testi senaryoları tanımlı mı?
• Güvenlik testleri ve sızma testleri periyodik olarak yapılıyor mu?
• Üretimde bulunan her hata için bir regresyon testi ekleniyor mu?