Bir acente yazılımının teklif ekranında gördüğünüz her sonuç, arka planda bir sigorta şirketinin servisinden gelen yanıtın okunup yorumlanmasıyla oluşur. Bu yanıtın yapısı, iki taraf arasında yazılı ya da yazısız bir anlaşmadır: Hangi alan hangi isimle gelecek, tarih hangi biçimde yazılacak, hata durumunda ne döndürülecek? Bu anlaşmaya yazılım dünyasında sözleşme denir. Sözleşme testi ise bu anlaşmanın hâlâ geçerli olup olmadığını otomatik olarak kontrol eden test türüdür.
Sorun nereden çıkar?
Sigorta şirketleri kendi sistemlerini zaman zaman günceller. Bir alanın adı değişebilir, zorunlu olmayan bir bilgi zorunlu hâle gelebilir ya da sayısal bir değer metin olarak dönmeye başlayabilir. Bu değişiklikler şirketin kendi ekranlarında hiçbir sorun yaratmazken, o servise bağlanan yazılımlarda teklifin hiç görünmemesine veya yanlış yorumlanmasına yol açabilir.
Klasik birim testleri bu tür sorunları yakalayamaz; çünkü yazılımın kendi içindeki mantığı doğrudur. Sorun, iki sistemin sınırındadır. Uçtan uca testler ise yakalayabilir ama her çalıştırmada gerçek servise gitmek yavaş, kırılgan ve bazen mümkün değildir. Sözleşme testi bu iki uç arasındaki boşluğu doldurur.
Sözleşme testi nasıl çalışır?
Temel fikir basittir: Entegrasyonun beklediği istek ve yanıt yapısı açıkça tanımlanır, ardından bu tanım iki yönden doğrulanır.
Tüketici tarafı
Acente yazılımı, servisin tüketicisidir. Tüketici tarafında, yazılımın gerçekten kullandığı alanlar ve bu alanların türleri bir sözleşme dosyasına yazılır. Yazılım bu sözleşmeye uygun örnek yanıtlarla test edilir. Örneğin teklif yanıtında prim tutarının sayısal, poliçe başlangıç tarihinin belirli bir tarih biçiminde gelmesi beklendiği burada kayda geçer.
Sağlayıcı tarafı
Sağlayıcı, yani servisi sunan taraf, bu sözleşmeye karşı doğrulanır. Sigorta şirketinin sistemine doğrudan müdahale edilemediği durumlarda bu doğrulama, düzenli aralıklarla servise kontrollü örnek istekler gönderip dönen yanıtın sözleşmeyle karşılaştırılması şeklinde yapılır. Yapı farklıysa test başarısız olur ve ekip, kullanıcılar etkilenmeden önce uyarılır.
Trafik, kasko ve DASK için ayrı sözleşmeler
Branşlar arasındaki fark, sözleşme testlerinde de korunmalıdır. Trafik sorgusunda plaka ve ruhsat bilgileri, kasko sorgusunda bunlara ek olarak araç değeri ve teminat seçimleri, DASK sorgusunda ise adres kodu, yapı tarzı ve inşa yılı gibi bilgiler öne çıkar. Her biri ayrı bir sorgu akışı olduğu için tek bir genel sözleşme yerine branş ve şirket bazında ayrı sözleşmeler tutmak daha sağlıklıdır. Böylece bir şirketin DASK servisinde yaptığı değişiklik, trafik akışını gereksiz yere alarma geçirmez.
İyi bir sözleşmenin özellikleri
- Sadece kullanılanı kapsar: Yazılımın okumadığı alanları sözleşmeye eklemek, gereksiz kırılmalara yol açar.
- Türleri ve biçimleri belirtir: Alanın varlığı kadar, sayı mı metin mi olduğu ve hangi biçimde geldiği de önemlidir.
- Hata yanıtlarını içerir: Başarısız bir sorguda dönen yapı da sözleşmenin parçasıdır; kullanıcıya anlamlı mesaj gösterebilmek buna bağlıdır.
- Sürümlüdür: Sözleşme değiştiğinde eski sürüm kaybolmaz; değişikliğin ne zaman ve neden yapıldığı izlenebilir.
Bir uyumsuzluk yakalandığında ne olur?
Sözleşme testinin değeri, uyarının ne kadar erken geldiğiyle ölçülür. Örnek bir senaryo düşünelim: Bir şirketin kasko servisinde teminat listesinin yapısı değişmiş olsun. Düzenli çalışan sözleşme testi bu farkı yakalar, ilgili ekibe bildirim düşer ve hangi alanın değiştiği raporda açıkça görünür. Ekip uyarlamayı yapar, testler yeniden yeşile döner ve düzeltme olağan yayın hattından canlıya taşınır. Bu sırada acente kullanıcısı ya hiçbir şey fark etmez ya da yalnızca o şirketin kasko sonucunun geçici olarak gösterilemediğine dair açık bir bilgi görür.
Sözleşme testi olmayan bir yapıda ise aynı değişiklik, ancak bir kullanıcı garip bir sonuç gördüğünde ve destek talebi açtığında fark edilir. Aradaki süre, yanlış ya da eksik tekliflerle geçen zamandır.
Acente açısından pratik karşılığı
Çok sayıda sigorta şirketiyle çalışan bir acente için entegrasyonların istikrarı, teklif programının güvenilirliğiyle doğrudan ilişkilidir. Sözleşme testleri bu istikrarın görünmeyen sigortasıdır. Değerlendirme yaparken yazılım sağlayıcınıza şu soruyu yöneltmek faydalı olabilir: "Bir sigorta şirketi servisini değiştirdiğinde bunu siz mi önce fark edersiniz, yoksa biz mi?"
Bu sorunun yanıtı, entegrasyonların nasıl izlendiğini ve acente yazılımının değişikliklere ne kadar hızlı uyum sağladığını gösterir.
Sözleşme testlerini yayın hattına bağlamak
Sözleşme testleri iki farklı zamanda çalıştırıldığında en yüksek değeri üretir. Birincisi, yazılım ekibinin kendi değişiklikleri sırasındadır: Entegrasyon kodunda yapılan her düzenleme, birleştirme isteğiyle birlikte sözleşmeye karşı doğrulanır. Böylece ekip, şirketin beklediği istek yapısını yanlışlıkla bozmaz. İkincisi, zamanlanmış kontrollerdir: Kod değişmese bile dış servis değişebileceği için sözleşmeler düzenli aralıklarla sağlayıcı tarafına karşı yeniden denenir.
Sık karşılaşılan tuzaklar
- Aşırı katı eşleştirme: Yanıttaki alanların sırasını ya da yazılımın kullanmadığı ek alanları kontrol etmek, gereksiz alarm üretir.
- Örnek yanıtların eskimesi: Testlerde kullanılan kayıtlı yanıtlar, sağlayıcının güncel yapısıyla düzenli olarak karşılaştırılmazsa yanlış bir güven duygusu yaratır.
- Kimlik doğrulama adımının unutulması: Oturum açma ya da yetki belirteci alma adımları da sözleşmenin parçasıdır; bu adımdaki bir değişiklik tüm branşları birden etkileyebilir.
Bu tuzaklardan kaçınmak, sözleşme testlerinin gürültü değil gerçek sinyal üretmesini sağlar.
Sözleşme testlerinin bir diğer faydası da yeni bir sigorta şirketi entegrasyonu eklenirken ortaya çıkar. İlk günden yazılan sözleşme, entegrasyonun neye dayandığını belgeleyen yaşayan bir doküman işlevi görür. Ekipte o entegrasyonu ilk kez inceleyen bir geliştirici, hangi alanların kullanıldığını ve hangi hata durumlarının beklendiğini sözleşmeyi okuyarak hızla öğrenir.
Özet
Sözleşme testi, iki sistem arasındaki beklentileri yazılı ve doğrulanabilir hâle getirir. Sigorta şirketi entegrasyonları gibi kontrolün tamamen yazılım ekibinde olmadığı alanlarda, sorunları kullanıcıya ulaşmadan yakalamanın en verimli yollarından biridir. Branş bazında ayrı tutulan, yalnızca kullanılan alanları kapsayan ve düzenli çalışan sözleşmeler, teklif akışlarının öngörülebilirliğini korur.