"Sadece kasko ekranındaki bir alanın etiketini değiştirdik, trafik sorgusu neden etkilendi?" Yazılım geliştirmede bu tür sorular sık sorulur ve cevabı çoğu zaman paylaşılan bir bileşende saklıdır. Regresyon, daha önce doğru çalışan bir davranışın yeni bir değişiklikten sonra bozulması demektir. Regresyon testi ise bu bozulmayı yakalamak için mevcut davranışın her değişiklikte yeniden doğrulanmasıdır.
Teklif motoru, bir acente yazılımının en çok parçayı bir araya getiren bölümüdür. Bu yazıda regresyon testlerinin teklif motorunda nasıl ele alınabileceğini ve branş akışlarını neden ayrı ayrı doğrulamak gerektiğini anlatıyoruz.
Teklif motorunda regresyon neden sık görülür?
Teklif motorunda birçok branş ortak parçaları kullanır: müşteri bilgisi okuma, sigorta şirketlerine bağlantı kurma, yanıtları normalize etme, sonuçları sıralama ve sunma. Bu ortaklık geliştirmeyi hızlandırır; ancak bir ortak parçadaki değişiklik, onu kullanan tüm akışlara yayılır. Ayrıca her branşın kendine özgü kuralları vardır. Trafik sorgusunda araç ve sürücü bilgisi, kaskoda teminat seçenekleri ve araç değeri, DASK'ta ise adres ve yapı bilgileri belirleyicidir. Ortak parça ile branşa özgü kural arasındaki etkileşim, regresyonların en çok saklandığı yerdir.
Regresyon test setini kurmak
1. Altın senaryoları belirlemek
Her branş için, sonucu iyi bilinen temsilî senaryolar seçilir. Bunlar gerçek müşteri verisi değil, gerçek kullanımı yansıtan sentetik örneklerdir. Örneğin trafik için yeni tescilli bir araç, ikinci el bir araç ve ticari bir araç; DASK için farklı yapı tarzları ve inşa yıllarına sahip adresler gibi.
2. Beklenen çıktıyı tanımlamak
Teklif tutarları sigorta şirketinden geldiği için zamanla değişir; bu yüzden regresyon testi tutarın kendisini değil, akışın davranışını doğrular. Hangi adımların çalıştığı, hangi alanların doldurulduğu, eksik bilgi olduğunda nasıl bir uyarı verildiği ve sonuçların hangi yapıda sunulduğu kontrol edilir.
3. Dış servisleri taklit etmek
Her test çalıştırmasında gerçek sigorta şirketi servislerine gitmek hem yavaş hem de güvenilmezdir. Bunun yerine kaydedilmiş ya da elle hazırlanmış örnek yanıtlar kullanılır. Böylece test, motorun kendi davranışını izole biçimde ölçer.
4. Branşları ayrı çalıştırmak
Test seti branş bazında gruplanır ve her grup bağımsız raporlanır. Bir değişiklik yalnızca DASK testlerini kırıyorsa, bu durum raporda tek bakışta görünür. Tek ve devasa bir test paketinde ise hangi akışın etkilendiğini bulmak zaman alır.
Neyi test etmeli, neyi etmemeli?
- Test edilmeli: Zorunlu alan kontrolleri, branşa özgü doğrulama kuralları, şirket yanıtlarının ortak formata dönüştürülmesi, hata durumlarında kullanıcıya gösterilen mesajlar, sonuçların sıralanma mantığı.
- Dikkatli olunmalı: Sigorta şirketinden gelen tutarlar, kampanya bilgileri ve zamanla değişen teminat seçenekleri sabit beklenti olarak yazılmamalıdır; aksi hâlde testler sürekli yanlış alarm verir.
- Gereksiz: Ekran düzenindeki piksel düzeyindeki farklar, regresyon testinin değil görsel test araçlarının konusudur.
Bir regresyon nasıl yakalanır? Örnek akış
Ekip, kasko teklifinde teminat seçimlerini daha okunur hâle getirmek için yanıt normalizasyon katmanında bir düzenleme yapıyor olsun. Düzenleme kasko testlerinden geçiyor. Ancak aynı katmanı kullanan trafik akışında, bazı şirketlerin yanıtındaki boş bir alan artık farklı yorumlanıyor ve sonuç listesinde bir şirket görünmez oluyor. Branş bazında ayrılmış regresyon seti, trafik grubunda tek bir senaryonun kırıldığını gösterir. Değişiklik canlıya çıkmadan düzeltilir ve bu senaryo kalıcı olarak test setine eklenir.
Bu örnekteki kritik nokta, testin kasko değişikliği sırasında trafiği de kontrol etmesidir. Yalnızca değişen alanı test etmek, regresyonu yakalamaz.
Test setini canlı tutmak
Regresyon setleri zamanla eskiyebilir. Kullanılmayan senaryolar birikir, yeni şirket entegrasyonları eklenmez. Setin değerini korumak için birkaç alışkanlık faydalıdır:
- Canlıda yaşanan her hata için, düzeltmeyle birlikte o hatayı yakalayacak bir test eklemek.
- Yeni bir sigorta şirketi entegrasyonu eklendiğinde, her branş için en az bir senaryo yazmak.
- Uzun süredir hiç başarısız olmamış ve artık var olmayan bir özelliği test eden senaryoları ayıklamak.
- Test sürelerini izlemek; set çok yavaşlarsa geliştiriciler onu çalıştırmaktan kaçınmaya başlar.
Acente kullanıcısına yansıması
Regresyon testlerinin amacı, acentenin aynı müşteri için dün aldığı sorgu deneyimini bugün de aynı güvenle yaşamasıdır. Teklif programı geliştikçe yeni özellikler eklenir; ancak mevcut akışların istikrarı korunmadıkça bu yenilikler değer üretmez. Özellikle yoğun yenileme dönemlerinde bir branşın akışında yaşanacak beklenmedik bir aksaklık, ekip için ciddi bir iş yükü anlamına gelir.
Yazılım sağlayıcınızın test yaklaşımını merak ediyorsanız, branşların ayrı ayrı doğrulanıp doğrulanmadığını ve canlıda yaşanan hataların test setine nasıl geri beslendiğini sorabilirsiniz. Kendi senaryolarınızla denemek için demo talebi de iyi bir başlangıçtır.
Kırmızı sonuç her zaman hata değildir
Regresyon testi başarısız olduğunda ilk refleks kodu düzeltmek olur. Oysa bazen değişen şey, beklenen davranışın kendisidir. Örneğin ürün kararıyla DASK akışına yeni bir zorunlu alan eklenmişse, eski senaryolar doğal olarak kırılır. Bu durumda yapılması gereken, testi susturmak değil, beklentiyi bilinçli olarak güncellemek ve bu güncellemeyi aynı değişiklik içinde incelemeye sunmaktır.
Bu ayrımı netleştirmek için başarısız bir regresyon testini değerlendirirken şu üç soru sorulabilir:
- Bu davranış değişikliği bilinçli bir kararın sonucu mu?
- Değişiklik yalnızca hedeflenen branşı mı etkiliyor, yoksa başka akışlara da mı yayılmış?
- Kullanıcıya görünen sonuç, ürün ekibinin beklediği sonuçla aynı mı?
İlk sorunun yanıtı hayırsa ortada gerçek bir regresyon vardır. Yanıt evet olsa bile ikinci soru, etkinin sınırlarını kontrol etmeyi hatırlatır.
Beklentinin bilinçli olarak güncellendiği durumlarda, değişikliğin gerekçesini test dosyasının yanında kısaca not etmek de faydalıdır. Aylar sonra aynı senaryoya bakan bir geliştirici, beklentinin neden değiştiğini bu nottan anlayabilir ve geçmişteki bir ürün kararını yanlışlıkla geri almaz.
Sonuç
Teklif motorunda regresyon testi, ortak bileşenlerin getirdiği verimliliği risk hâline gelmekten korur. Trafik, kasko ve DASK akışlarını kendi senaryolarıyla ayrı ayrı doğrulamak; değişikliklerin etkisini görünür kılar ve sorunların kaynağını hızla bulmayı sağlar.