DevOps ve Yazılım Kalitesi

Uçtan Uca Test Otomasyonu ile Acente Paneli Senaryoları

InsureHub Ekibi
19 Ağustos 2026

Bir kullanıcının acente paneline girip yeni bir müşteri oluşturması, ardından bu müşteri için teklif başlatması ve sonucu kaydetmesi birkaç dakikalık bir iştir. Ancak bu birkaç dakika boyunca arayüz, kimlik doğrulama servisi, veritabanı, teklif motoru ve bildirim altyapısı birlikte çalışır. Uçtan uca test, bu zincirin tamamını gerçek bir kullanıcı gibi baştan sona deneyen test türüdür.

Test piramidinde uçtan uca testin yeri

Yazılım testleri genellikle bir piramit olarak düşünülür. Tabanda çok sayıda hızlı birim testi, ortada bileşenlerin birlikte çalışmasını kontrol eden entegrasyon testleri, tepede ise az sayıda ama kapsamlı uçtan uca test bulunur. Uçtan uca testler en gerçekçi olanlardır; ancak yavaş çalışır, bakım ister ve küçük arayüz değişikliklerinden etkilenebilir. Bu yüzden her şeyi uçtan uca test etmek yerine, işin kalbindeki kritik yolculukları seçmek gerekir.

Acente paneli için kritik yolculuklar

Hangi senaryoların otomatikleştirileceğine karar verirken şu soru yol gösterir: "Bu akış çalışmazsa acente o gün işini yapabilir mi?" Bu soruya hayır cevabı verilen akışlar önceliklidir:

  1. Oturum açma ve iki aşamalı doğrulama: Kullanıcının sisteme girebilmesi her şeyin ön koşuludur.
  2. Müşteri kaydı oluşturma ve arama: Yeni kayıt, mükerrer kontrolü ve arama sonuçlarında görünme.
  3. Branş bazında teklif başlatma: Trafik, kasko ve DASK için ayrı senaryolar; her biri kendi zorunlu alanları ve adımlarıyla.
  4. Teklifin müşteri kartına bağlanması: Oluşturulan teklifin geçmişte doğru yerde görünmesi.
  5. Yetki sınırları: Alt kullanıcının erişmemesi gereken bir ekrana gerçekten erişemediğinin doğrulanması.

Tarayıcı otomasyonu nasıl çalışır?

Uçtan uca testler, gerçek bir tarayıcıyı ekransız modda çalıştıran otomasyon araçlarıyla yazılır. Test betiği sayfayı açar, alanları doldurur, düğmelere tıklar ve ekranda beklenen sonucun görünüp görünmediğini kontrol eder. Modern araçlar sayfanın yüklenmesini, öğelerin görünür hâle gelmesini ve ağ isteklerinin tamamlanmasını otomatik olarak bekleyebilir. Bu, testlerin sabit bekleme süreleriyle dolup taşmasını önler.

Kararlı seçiciler kullanmak

Testlerin en sık kırılma nedeni, ekrandaki öğelerin bulunma biçimidir. Bir düğmeyi rengine, sırasına ya da görünen metnine göre bulmak, tasarım değiştiğinde testi bozar. Bunun yerine öğelere test amacıyla eklenmiş kalıcı tanımlayıcılar ya da erişilebilirlik rolleri üzerinden ulaşmak çok daha dayanıklıdır. Bu yaklaşımın yan faydası, arayüzün ekran okuyucular için de daha anlaşılır hâle gelmesidir.

Her testin kendi verisi

Testler birbirine bağımlı olmamalıdır. "Önce müşteri oluşturma testi çalışsın, sonra teklif testi o müşteriyi kullansın" yaklaşımı, birinci test başarısız olduğunda ikincisini anlamsız kılar. Her test ihtiyaç duyduğu müşteriyi ve kullanıcıyı kendisi hazırlamalı, iş bitince de temizlemelidir.

Kırılgan testlerle mücadele

Bazen geçen bazen kalan testlere kırılgan test denir ve ekibin otomasyona olan güvenini en hızlı aşındıran şey bunlardır. Kırılganlığın yaygın nedenleri şunlardır:

  • Sabit sürelerle bekleme yapılması,
  • Testlerin aynı veriyi paylaşması,
  • Dış servislere bağımlılık,
  • Tarih ve saate bağlı mantıkların sabitlenmemesi.

Kırılgan bir test tespit edildiğinde onu görmezden gelmek yerine karantinaya almak, nedenini bulmak ve düzelttikten sonra ana sete geri döndürmek sağlıklı bir alışkanlıktır.

Başarısız testten öğrenmek

Uçtan uca test başarısız olduğunda neyin yanlış gittiğini anlamak, birim testine göre daha zordur. Bu nedenle iyi bir otomasyon altyapısı başarısızlık anında ekran görüntüsü, sayfanın o anki yapısı, ağ istekleri ve mümkünse kısa bir video kaydı saklar. Geliştirici, testi yeniden çalıştırmadan sorunun hangi adımda ve neden oluştuğunu bu kayıtlardan görebilir.

Web ve mobil arasında tutarlılık

Acente ekipleri aynı işi bazen web panelinden bazen mobil uygulamadan yapar. Uçtan uca testlerin bir bölümünün iki kanalı birlikte kapsaması, örneğin web panelinde oluşturulan bir müşterinin mobil uygulamada aynı bilgilerle göründüğünü doğrulaması, veri tutarlılığı açısından değerlidir. Mobil testler farklı araçlarla yazılsa da senaryoların aynı iş diliyle tanımlanması bakımı kolaylaştırır.

Acente için ne anlama gelir?

Uçtan uca testler, acentenin her gün tekrarladığı temel işlerin her yeni sürümde otomatik olarak denendiği anlamına gelir. Müşteri kaydından teklife uzanan akışın kesintisiz çalışması, acente CRM verisinin güvenilirliği ve ekibin yazılıma olan güveni için belirleyicidir. Bir yazılımı değerlendirirken, sağlayıcının hangi akışları otomatik test ettiğini sormak ve kendi kritik yolculuklarınızı bu listeyle karşılaştırmak faydalı bir egzersizdir.

Testler ne zaman ve nerede çalışmalı?

Tüm uçtan uca testleri her değişiklikte çalıştırmak geliştirme hızını düşürebilir. Bu yüzden testler genellikle katmanlara ayrılır:

  • Duman seti: Oturum açma ve her branşta bir teklif başlatma gibi en temel birkaç senaryo, her birleştirme isteğinde dakikalar içinde çalışır.
  • Tam set: Yetki senaryoları, uç durumlar ve web ile mobil arası tutarlılık kontrolleri, günde bir kez ya da yayın öncesinde hazırlık ortamında çalışır.
  • Canlı ortam kontrolleri: Yayın sonrasında, test hesabıyla ve veri değiştirmeyen salt okunur senaryolarla sistemin temel işlevlerinin çalıştığı doğrulanır.

Canlı ortamda çalışan kontrollerde ekstra özen gerekir: Gerçek sigorta şirketlerine sorgu gönderilmemeli, gerçek müşteri kaydı oluşturulmamalı ve test hesabının yetkileri yalnızca bu kontrollerle sınırlı tutulmalıdır. Bu katmanlı yaklaşım, hem hızlı geri bildirim hem de kapsamlı güvence sağlar.

Katmanlar arasındaki sınır sabit değildir. Canlıda yaşanan bir sorun tam sette yakalanabilecekken yakalanmadıysa, ilgili senaryo duman setine taşınabilir. Tersine, uzun süredir hiçbir sorun yakalamayan ve yavaş çalışan bir duman senaryosu tam sete alınarak geri bildirim döngüsü hızlandırılabilir. Bu düzenli ayar, setin değerini korur.

Kısaca

Uçtan uca test otomasyonu, acente panelini gerçek bir kullanıcının gözünden düzenli olarak dener. Az sayıda ama doğru seçilmiş senaryo, kararlı seçiciler, bağımsız test verisi ve zengin hata kayıtlarıyla kurulduğunda, yeni sürümlerin temel işleri bozmadığına dair güçlü bir güvence sağlar.