Tarayıcı Ajanıyla Site Durum Tespiti Nasıl Yapılır?

Satışlar düşüyor, destek ekibine “Ödeme yapamıyorum” mesajları geliyor; fakat siteyi kendi bilgisayarınızda açtığınızda her şey normal görünüyor. Ürün sayfası yükleniyor, sepete ekleme düğmesi çalışıyor ve ödeme formu karşınıza çıkıyor. O hâlde sorun nerede?

Belki düğme yalnızca dar bir mobil ekranda sabit kampanya çubuğunun altında kalıyordur. Belki adres doğrulama isteği zaman aşımına uğruyor, arayüz ise bu hatayı kullanıcıya göstermiyordur. Belki oturum açmış müşteriler eski bir çerez nedeniyle döngüye giriyordur. Ya da sayfa teknik olarak açılıyor, fakat ödeme adımına ulaşmak o kadar uzun sürüyordur ki kullanıcıların bir bölümü beklemekten vazgeçiyordur.

“Site açılıyor” bu ihtimallerin hiçbirini elemez. Çünkü bir web sitesinin sağlığı, ana sayfanın ekrana gelmesinden değil, belirli bir kullanıcının belirli koşullarda hedeflediği işi tamamlayabilmesinden anlaşılır.

Tarayıcı kullanan yapay zekâ ajanları burada yeni bir gözlem aracı sunuyor. Resmî ürün belgeleri; ajanların tarayıcı oturumunda sayfalar arasında çalışabildiğini, canlı sayfa durumunu inceleyebildiğini ve uygun araçlarla geliştirici sinyallerine erişebildiğini gösteriyor. Chrome’un ajanlara yönelik DevTools yaklaşımı da ekranın yanında konsol, ağ istekleri ve performans izleri gibi teknik kanıtların incelenmesini mümkün kılıyor. Fakat tarayıcıya erişmek tek başına güvenilir teşhis üretmez. Ajanın hangi yolu izleyeceğini, neyi kanıt sayacağını ve nerede duracağını bizim tanımlamamız gerekir.

Bu yazıda tarayıcı ajanını “siteyi gez ve sorun bul” komutuyla başıboş bırakmayacağız. Onu dijital bir gizli müşteri gibi çalıştıracağız: gerçek bir kullanıcı rolü üstlenecek, tanımlı bir yol izleyecek, gördüğü belirtiyi teknik kanıtlarla ilişkilendirecek ve doğrulamadığı tahminleri arıza diye sunmayacak.

“Site çalışıyor” yerine kullanıcı yolunu tanımlamak

Bir site aynı anda hem çalışıyor hem bozuk olabilir. Ana sayfa çalışırken arama bozulabilir; masaüstünde çalışan sepet mobilde kullanılamayabilir; yeni ziyaretçi ödeme yapabilirken oturum açmış müşteri hata alabilir. Bu yüzden gözlem biriminiz “site” değil, kullanıcı yolu olmalıdır.

Kullanıcı yolu, bir başlangıç durumundan ölçülebilir bir sonuca giden geçişler dizisidir. İyi tanımlanmış bir yol şu dört unsuru içerir:

Kim: Yeni ziyaretçi, mevcut müşteri, yönetici veya belirli bir abonelik grubundaki kullanıcı.
Hangi ortamda: Ekran boyutu, tarayıcı, dil, ağ koşulu ve oturum durumu.
Ne yapmak istiyor: Ürün bulmak, sepete eklemek, form göndermek veya hesabına erişmek.
Başarının kanıtı: Yalnızca bir düğmeye basılması değil, beklenen son durumun gerçekten oluşması.

Örneğin “Mobil siteyi kontrol et” zayıf bir görevdir. Ajan onlarca sayfayı gezebilir, görünür birkaç kusur bulabilir ve asıl gelir kaybını kaçırabilir. Aynı isteğin ölçülebilir hâli şöyledir:

390 × 844 piksel görünümde, oturum açmamış ve Türkçe dilini kullanan bir ziyaretçi olarak “Filtre Kahve 500 g” ürününü arama sonucundan aç. Bir adet ürünü sepete ekle, misafir ödeme akışını başlat ve kart bilgisi girmeden önceki sipariş özeti ekranına ulaş. Başarı kanıtı; sepette doğru ürünün, bir adet miktarın, teslimat ücretinin ve nihai tutarın görünmesidir. Gerçek sipariş oluşturma, ödeme başlatma veya müşteri iletişimi yasaktır.

Bu tanım ajana yalnızca ne yapacağını söylemez; testi nerede bitireceğini ve hangi eylemleri yapmaması gerektiğini de öğretir. Böylece “ödeme düğmesini gördüm” ile “ödeme öncesi özet durumuna ulaştım” arasındaki fark korunur.

Teşhisin üç seviyesi: belirti, olası neden, doğrulanmış arıza

Tarayıcı ajanlarının en yararlı olabileceği yerlerden biri, farklı kanıt türlerini aynı zaman çizgisinde birleştirmektir. Aynı özellik onları ikna edici ama erken sonuçlara da götürebilir. Konsolda kırmızı bir hata görmek, kullanıcının yaşadığı sorunun nedenini bulduğumuz anlamına gelmez. Hata sayfanın başka bir bölümüne ait olabilir veya akışı hiç etkilemeyebilir.

Bu nedenle her bulguyu üç seviyeden biriyle etiketlemek gerekir:

Seviye	Ne söyler?	Örnek	Gerekli dil
Belirti	Kullanıcının gözlenebilir deneyimini	“Devam et” düğmesine basıldıktan sonra ekran 12 saniye değişmedi.	“Gözlendi”
Olası neden	Belirtiyle ilişkili makul açıklamayı	Aynı anda adres doğrulama isteği beklemede kaldı.	“İlişkili olabilir”
Doğrulanmış arıza	Tekrar üretim ve karşılaştırmayla desteklenen nedeni	İstek zaman aşımına uğradığında arayüz hata göstermiyor; başarılı yanıtta sonraki adım açılıyor.	“Kanıtlandı”

Aradaki fark küçük görünse de ekip kararını değiştirir. Belirti, inceleme başlatır. Olası neden, yeni bir test doğurur. Doğrulanmış arıza ise düzeltme işine dönüşebilir.

Pratik karar kuralı şudur: Ajan tek bir koşuda yalnızca ekrandaki donmayı ve ağ isteğinin beklediğini gördüyse “ağ isteği soruna neden oldu” dememelidir. Aynı yolu temiz oturumda yeniden denemek, başarılı ve başarısız koşuları karşılaştırmak ya da kontrollü test ortamında ilgili yanıtın etkisini sınamak gerekir. Üretim ortamında veri veya yanıt değiştirmek ise sıradan durum tespitinin yetki sınırını aşar.

Tek ekran görüntüsü değil, kanıt paketi

Ekran görüntüsü kullanıcıya ne olduğunu gösterir; çoğu zaman neden olduğunu göstermez. Konsol hatası teknik bir ipucu verir; kullanıcının etkilenip etkilenmediğini tek başına kanıtlamaz. Ağ kaydı başarısız isteği bulur; isteği hangi etkileşimin başlattığını anlatmak için zaman çizgisine ihtiyaç duyar. Güvenilir teşhis bu parçaları aynı olay çevresinde toplar.

İyi bir kanıt paketi en az şu öğeleri içerir:

Başlangıç koşulları: Sayfa adresi, ekran boyutu, dil, oturum türü ve test zamanı.
Tekrar üretim adımları: Yoruma açık olmayan, sıralı kullanıcı eylemleri.
Görsel durum: Sorunun görüldüğü anda ekran görüntüsü ve mümkünse ilgili öğenin durumu.
Ağ kanıtı: Akışla ilişkili isteğin yolu, durum sonucu ve yaklaşık süresi; hassas başlıklar veya kişisel veriler hariç.
Konsol kanıtı: Olay zamanına karşılık gelen hata; ilgisiz günlüklerden ayrılmış biçimde.
Süre ve geçiş: Tıklama ile beklenen ekran değişimi arasında geçen süre.
Son durum: Akış tamamlandı mı, engellendi mi, yoksa sonuç belirsiz mi?

Burada daha fazla veri her zaman daha iyi değildir. Bütün oturumun ham ağ kaydını paylaşmak, içinde kimlik belirteçleri veya kişisel veriler bulunabileceği için güvenlik riski yaratır. Ajanın görevi kanıtı yığmak değil, gerekli parçayı seçip hassas alanları dışarıda bırakmaktır.

Doldurulmuş kanıt kaydı

Test kimliği	MOB-CHECKOUT-017
Rol ve ortam	Oturum açmamış ziyaretçi; Türkçe; 390 × 844 görünüm; normal ağ koşulu
Hedef	Bir adet Filtre Kahve 500 g ürünüyle ödeme öncesi sipariş özetine ulaşmak
Gözlenen belirti	Adres adımındaki “Devam et” düğmesinden sonra yükleniyor göstergesi kaybolmadı ve özet açılmadı
İlgili teknik sinyal	Düğme tıklamasından hemen sonra başlayan adres doğrulama isteği başarısız sonuçlandı
Konsol	Aynı zaman aralığında adres yanıtının işlenemediğini belirten hata kaydı oluştu
Kullanıcıya gösterilen mesaj	Yok
İlk sınıflandırma	Etkileşimi engelleyen hata; olası ağ/yanıt işleme arızası
Doğrulama durumu	İkinci temiz oturumda aynı adım tekrar başarısız oldu; nedenin kesinleştirilmesi için sunucu kaydıyla eşleştirme gerekiyor
Yasak eylemler	Kart bilgisi girilmedi, sipariş oluşturulmadı, üretim verisi değiştirilmedi

Bu kayıt sorunu olduğundan büyük göstermiyor. İki kez tekrarlandığını, fakat sunucu tarafındaki kök nedenin henüz kanıtlanmadığını açıkça söylüyor. Böyle bir dürüstlük, hızlı ama yanlış teşhisten daha değerlidir.

Dört hata sınıfı, dört farklı inceleme yolu

Her sorunda bütün araçları çalıştırmak maliyetli ve gürültülüdür. Önce belirtinin sınıfını belirleyip sonra uygun araca yönelmek daha etkilidir.

1. İçerik ve durum hataları

Yanlış fiyat, eski kampanya metni, kayıp ürün görseli veya tutarsız sepet toplamı bu gruptadır. Önce görünür metin ve sayfa durumu karşılaştırılır. Karar kuralı basittir: Aynı veri iki ekranda farklı görünüyorsa kaynağı tahmin etmek yerine iki durumu da kaydedin. Örneğin ürün sayfasında 420 TL, sepette 470 TL görülüyorsa “veritabanı bozuk” denmez; fiyatın değiştiği geçiş belgelenir.

2. Etkileşim ve erişilebilirlik hataları

Düğmenin tıklanamaması, klavyeyle ulaşılamaması, görünür etiketi olmayan form alanı veya açılıp kapanmayan menü bu sınıfa girer. Görsel inceleme burada yeterli olmayabilir. Öğenin erişilebilirlik ağacındaki adı, odak sırası ve etkin durumu incelenmelidir. Chrome DevTools’un erişilebilirlik araçları, görsel olarak var olan bir öğenin yardımcı teknolojiler açısından nasıl temsil edildiğini araştırmaya yardım eder.

Uygulama testi olarak ajan yalnız fareyle değil, klavye akışıyla da aynı hedefe gitmeyi deneyebilir. Ancak sonuç “site erişilebilirdir” gibi geniş bir hükme dönüştürülmemelidir. Tek bir yolun klavyeyle tamamlanması, bütün sitenin erişilebilir olduğunu kanıtlamaz.

3. Performans hataları

Sayfanın açılması ile kullanılabilir olması aynı şey değildir. Kullanıcı düğmeyi görse bile uzun süre etkileşime geçemeyebilir; içerik sonradan yer değiştirip yanlış öğeye basmasına yol açabilir. Böyle durumlarda performans izi, zaman çizelgesi ve ağ sıralaması gerekir.

Tek koşudaki süreyi evrensel gerçek gibi sunmamak önemlidir. Cihaz yükü, önbellek, coğrafi konum ve ağ koşulları sonucu etkiler. Bu yüzden “ödeme sayfası her kullanıcıda yavaştır” yerine “tanımlanan mobil koşulda üç koşunun ikisinde adres geçişi belirlenen kabul eşiğini aştı” denmelidir. Eşik de iş ihtiyacına göre testten önce belirlenmelidir.

4. Ortam ve oturum hataları

Çerezler, oturum durumu, izinler, dil veya bölge ayarı belirli kullanıcıların farklı davranış görmesine neden olabilir. Buradaki en güçlü yöntem karşılaştırmadır: temiz oturum ile mevcut oturum, mobil görünüm ile masaüstü görünüm veya Türkçe ile başka bir dil aynı yol üzerinde sınanır.

Mevcut oturumları kullanabilen tarayıcı ajanları gerçekçi testler için yararlı olabilir; fakat bu aynı zamanda hesabın yetkilerini devralabilecekleri anlamına gelir. Durum tespiti için düşük yetkili test hesabı, sınırlı veri ve ayrı bir tarayıcı profili tercih edilmelidir. Yönetici hesabıyla gözlem yapmak, teşhis görevine gereksiz bir zarar kapasitesi ekler.

Ajan hangi aracı ne zaman seçmeli?

Tarayıcı ajanı önünde kabaca üç çalışma yüzeyi bulunabilir: ekrandaki arayüz, tarayıcı geliştirici sinyalleri ve sitenin ajanlara sunduğu yapılandırılmış işlevler. WebMCP yaklaşımı, web uygulamasının belirli araçları yapılandırılmış biçimde ajana sunmasına imkân verir. Bu, ajanın her işi ekrandaki koordinatlara basarak yapması gereğini azaltabilir. Fakat yapılandırılmış bir aracın bulunması, görsel kullanıcı deneyimini gereksiz kılmaz.

Araç seçimi için şu karar sırası kullanılabilir:

Soru “Kullanıcı ne görüyor ve neye basabiliyor?” ise ekran ve erişilebilirlik durumu incelenir.
Soru “Tıklamadan sonra hangi teknik olay başarısız oldu?” ise ağ, konsol ve gerektiğinde performans izi kullanılır.
Soru “Sayfanın sunduğu belirli işlem güvenilir biçimde nasıl çağrılır?” ise mevcutsa yapılandırılmış web aracı değerlendirilebilir.
Soru “Arka uçtaki kayıt gerçekten değişti mi?” ise tarayıcı gözlemi yetmez; ayrı ve yetkili bir sistem kanıtı gerekir.

Örneğin sepete ekleme işlevini yapılandırılmış bir araçla çağırmak, aracın doğru yanıt verdiğini gösterebilir. Fakat gerçek kullanıcı düğmesi mobilde görünmüyorsa müşteri sorunu çözülmüş sayılmaz. Tersine, düğmenin animasyon göstermesi de ürünün sunucu tarafında sepete eklendiğini kanıtlamaz. Aynı işlevin arayüz ve sistem katmanlarındaki kanıtları farklıdır.

Uçtan uca uygulama: mobil sepetten ödeme öncesine

Şimdi yaklaşımı küçük bir e-ticaret ekibinin yaşayabileceği duruma uygulayalım. Destek taleplerinde mobil kullanıcıların “adres adımında kaldığı” söyleniyor. Ekip gerçek ödeme yapılmadan sorunun kapsamını öğrenmek istiyor.

Sözleşmeyi yazın: Test ürünü, ekran boyutu, dil, oturum durumu, başlangıç adresi, başarı kanıtı ve yasak eylemler önceden tanımlanır.
Temiz başlangıç oluşturun: Ayrı test profili kullanılır; sepette eski ürün bulunmadığı doğrulanır. Test hesabı gerekiyorsa yalnız gerekli yetkilere sahip olur.
Yolu bir kez kullanıcı gibi izleyin: Ajan ürün arar, ürün sayfasını açar, sepete ekler ve adres adımına gelir. Her geçişte beklenen ve gözlenen durum kaydedilir.
Belirti oluştuğunda durumu dondurun: Rastgele yeniden tıklamak yerine ekran, etkin öğe, yüklenme göstergesi, süre ve adres çubuğu kaydedilir.
Teknik sinyalleri zamanla eşleştirin: Son etkileşimden hemen sonra başlayan ağ istekleri ve konsol kayıtları incelenir. İlgisiz eski hatalar ayıklanır.
Kontrollü tekrar yapın: Aynı yol temiz oturumda yeniden denenir. Sonra yalnızca bir değişken, örneğin ekran genişliği değiştirilir. Birden fazla koşulu aynı anda değiştirmek karşılaştırmayı bozar.
Bulguyu sınıflandırın: Mobilde iki kez oluşan, masaüstünde oluşmayan hata “mobil koşulla ilişkili tekrar üretilebilir engel” olarak raporlanabilir. Kök neden kanıtlanmadıysa ayrıca belirtilir.
Zarar sınırında durun: Sipariş verme, ödeme başlatma, gerçek müşteriye mesaj gönderme veya üretim kaydını değiştirme yapılmaz.

Bu süreç sonunda ekip yalnızca “mobil ödeme bozuk” cümlesi almaz. Hangi kullanıcı yolunun, hangi adımda, hangi koşulda bozulduğu; kullanıcının ne gördüğü; hangi teknik sinyalin olayla çakıştığı ve hangi sorunun hâlâ açık olduğu anlaşılır. Geliştirici incelemeye daha dar bir alandan başlar, ürün yöneticisi etkinin kapsamını görür, destek ekibi de müşteriye neyin bilindiğini abartmadan anlatabilir.

İyi bir durum tespiti raporunun kabul ölçütleri

Tarayıcı ajanının raporunu teslim almadan önce şu kontrol listesini uygulayın:

Test edilen kullanıcı rolü ve ortam açıkça yazılmış mı?
Başarı koşulu görünür bir son durumla tanımlanmış mı?
Tekrar üretim adımları başka bir kişinin uygulayabileceği kadar somut mu?
Belirti ile tahmin edilen neden ayrı tutulmuş mu?
Teknik kayıtlar kullanıcıdaki etkiyle aynı zaman çizgisinde ilişkilendirilmiş mi?
Kaç tekrar yapıldığı ve hangi değişkenin değiştirildiği belirtilmiş mi?
Kişisel veriler, oturum belirteçleri ve hassas başlıklar rapordan çıkarılmış mı?
Gerçek sipariş, mesaj veya veri değişikliği gibi yan etkiler önlenmiş mi?
Kesinleşmeyen noktalar “açık soru” olarak görünür mü?
Rapor, geliştiriciye bir sonraki doğrulama adımını söylüyor mu?

Bu maddelerden biri eksikse rapor bütünüyle değersiz olmayabilir; fakat güven düzeyi düşürülmelidir. Özellikle ekran görüntüsü bulunup başlangıç koşulları bilinmiyorsa sorun tekrar üretilemeyebilir. Ağ hatası bulunup kullanıcı etkisi gösterilmemişse yanlış öncelik verilebilir.

Tarayıcı ajanı neyin yerini tutmaz?

Tarayıcı ajanı kullanıcı yolunu keşfetmek ve kanıt toplamak için güçlüdür; kapsamlı izleme altyapısının, sunucu günlüklerinin, analitik verinin veya erişilebilirlik uzmanının yerini tek başına tutmaz. Bir ajan belirli bir akışta sorun görmemiş olabilir; bu, diğer cihazlarda veya gerçek trafik altında sorun olmadığı anlamına gelmez. Aynı şekilde tek bir başarısız koşu da bütün müşterilerin etkilendiğini göstermez.

En sağlıklı iş bölümü şöyledir: Analitik ve destek kayıtları şüpheli yolu gösterir; tarayıcı ajanı yolu kontrollü biçimde tekrar üretip kanıt paketler; geliştirici veya ilgili uzman kök nedeni sistem verileriyle doğrular; düzeltmeden sonra aynı sözleşme yeniden çalıştırılır. Böylece ajan karar veren son otorite değil, belirsiz bir şikâyeti incelenebilir vakaya dönüştüren gözlemci olur.

Bugün başlayabileceğiniz küçük deney

İlk deneme için bütün sitenizi taratmayın. Gelire, üyeliğe veya destek yüküne doğrudan bağlı tek bir yol seçin. Örneğin “mobil ziyaretçinin iletişim formunu başarıyla göndermesi” yeterlidir. Başlangıç koşulunu, beş ila sekiz adımı, başarı kanıtını ve yasak eylemleri yazın. Ajanın yalnızca bu yolu izlemesini, her adımda beklenen ve gözlenen durumu kaydetmesini isteyin.

Sonra rapora tek bir soru sorun: Bu bulguyu hiç görmemiş bir ekip arkadaşı, aynı koşullarda yeniden üretebilir mi? Cevap hayırsa daha fazla özerklik değil, daha iyi görev sözleşmesi ve daha düzenli kanıt gerekir.

Dijital gizli müşterinin değeri çok sayıda sayfaya hızla tıklamasında değildir. Gerçek kullanıcı yolunu teknik sinyallerle birleştirip “bir şeyler ters” şikâyetini sınırları belli bir vakaya dönüştürmesindedir. Site sağlığını ana sayfanın açılıp açılmadığıyla değil, kullanıcı niyetinin kanıtlanabilir biçimde tamamlanıp tamamlanmadığıyla ölçmeye başladığımızda tarayıcı ajanı da gösterişli bir otomasyondan güvenilir bir teşhis aracına dönüşür.

Dijital Gizli Müşteri: Tarayıcı Ajanıyla Site Durum Tespiti Yapmak