Tarayıcı otomasyonu üç nesilden geçti. Her nesil, öncekinin darboğazını çözerken yeni darboğazı başka bir noktaya taşıdı. Araç adlarını ezberlemekten çok, her neslin hangi sorunları açık bıraktığını anlamak önemlidir.
Tarayıcı otomasyonu yirmi yılı aşkın süredir kullanılıyor ve bu süreçte üç ana yaklaşım öne çıktı. İlginç olan, her neslin farklı bir sorun sınıfını çözmesi ve çözdükten sonra darboğazın başka bir noktaya taşınmasıdır.
Birinci nesil: işletim sistemi düzeyinde birinin fareyi hareket ettirdiğini taklit etmek
İlk otomasyon yöntemleri aslında tarayıcının içinde çalışmıyordu; işletim sistemi düzeyinde çalışıyordu. Betik fareyi hareket ettiriyor, tuşlara basıyor; tarayıcı ise bu girdileri pasif biçimde alıyordu.
Avantajı genellikti: ekranda görünen her şeyle etkileşime girebiliyordu; web sayfası, istemci uygulaması ya da eski masaüstü yazılımı olması fark etmiyordu ve tarayıcının herhangi bir arayüz sunması gerekmiyordu. Bedeli de oldukça açıktı. Betik ekran koordinatlarını temel alıyordu; çözünürlük değiştiğinde, sistem ölçeklendirmesi ayarlandığında veya pencere taşındığında aynı işlem yanlış yere tıklayabiliyordu. Sayfanın gerçekten yüklenip yüklenmediğini de bilmiyor, sabit bekleme sürelerine güvenmek zorunda kalıyordu. Paralellik daha da zordu: bir makinede yalnızca bir fare ve klavye bulunduğu için on ortam on makine gerektiriyordu.
Bu neslin geride bıraktığı sorun basitti: sayfayı göremiyordu.
İkinci nesil: ekranı atlayıp doğrudan tarayıcıyla konuşmak
WebDriver’ın ortaya çıkışı otomasyonu piksel düzeyinden öğe düzeyine taşıdı: ekrandaki 800. pikselin konumu yerine sayfadaki belirli bir öğe aranıyordu. Aynı kod farklı tarayıcıları sürebiliyor ve farklı dillerde yazılabiliyordu. Bu da daha sonra test alanında standart hâline gelmesinin nedenlerinden biriydi.
Daha sonra tarayıcı hata ayıklama protokollerine dayalı çözümler bu yaklaşımı çok daha ileri taşıdı. Puppeteer ve Playwright ailesi tarayıcı motoruyla doğrudan iletişim kurar ve sayfanın iç durumuna erişebilir: öğelerin hazır olmasını otomatik beklemek, istekleri yakalayıp yeniden yazmak, açık durumdaki bir tarayıcı örneğine bağlanmak, başsız çalışmak ve birden fazla bağlamı paralel açmak. Bugün olağan kabul edilen birçok özellik bu aşamada tamamlandı.
Bu nesil kontrol ve kararlılık sorunlarını çözdü, ancak iki başka problem bıraktı. Birincisi, betiklerin hâlâ insanlar tarafından sabit biçimde yazılmasıydı. Sayfa yapısı değiştiğinde veya bir seçici bozulduğunda koda dönmek gerekiyordu ve bakım maliyeti proje büyüklüğüyle birlikte artıyordu. İkinci sorun daha temeldi: sistem nasıl işlem yapılacağını yönetiyordu, işlemi yapanın nasıl göründüğünü değil. Protokol üzerinden doğrudan bağlantı kontrolü daha hassas hâle getirir, ancak iletişim yöntemini değiştirmek otomasyonun bıraktığı izleri ortadan kaldırmaz. Çok kararlı çalışan bir betik bile dışarıdan hâlâ betik gibi görünebilir.
Üçüncü nesil: adımları insanlar tek tek yazmıyor ve sorun yeniden yer değiştiriyor
Üçüncü nesilde değişen kontrol yöntemi değil, karar verme yöntemidir. İlk iki nesilde insanların her adımı açıkça yazması gerekiyordu: hangi düğmeye tıklanacağı, hangi alanın doldurulacağı ve hangi sıranın izleneceği. Model tabanlı nesilde ise hedefi verirsiniz, model yolu kendi planlar ve sayfa tasarımı değiştiğinde yeni giriş noktasını bulabilir.
Böylece seçicinin nasıl yazılacağı veya ne kadar bekleneceği gibi eski ayrıntılar giderek daha az kritik hâle gelir. Ancak yeni sorunlar hemen ortaya çıkar.
Temel nokta şu: modelin kendisi web sayfasına erişmez. Sayfayı açan, kaynakları yükleyen ve oturum durumunu koruyan yine tarayıcıdır. Bu nedenle bir görev kararsız çalışmaya başladığında sebep çoğu zaman modelin yanlış karar vermesi değil, altında çalışan yürütme ortamıdır: birden fazla görev aynı tarayıcıyı paylaşır ve çerezler ile önbellek birbirine karışır; fingerprint özellikleri çok benzerdir ve platform bu görevlerin aynı makineden geldiğini düşünür; hesaplar görevler arasında kullanılır ve tek bir anormallik birçok görevi etkiler; ortamların geçici olarak oluşturulup iş bitince geri alınması gerekir, ancak birleşik bir zamanlama yoktur. Model nasıl yapılacağını çözerken, nerede yapılacağı yeni darboğaz hâline gelir.
Mimaride ortaya çıkan ek katman
Üç nesle birlikte bakıldığında fark, hangisinin daha ileri olduğu değildir; her nesil öncekinin çözemediğini devralmak zorundadır. İlk iki nesilde ortam önemli bir sorun değildi, çünkü kendi makinenizdeki tarayıcı kullanılıyordu. Agent aşamasında ise görevler toplu, eşzamanlı ve gözetimsizdir; bu nedenle ortam açıkça yönetilmelidir: her görev bağımsız bir ortamda çalışır, fingerprintler ve oturumlar birbirine karışmaz; oturum açma durumu görevler arasında korunur, böylece her seferinde tekrar giriş yapmak gerekmez; IP, saat dilimi ve dil birlikte eşleştirilir; ortamlar hesaplama kaynakları gibi ihtiyaç halinde oluşturulur ve geri alınır.
PurpleMark tam bu katmanda çalışır; tarayıcı ortamlarını zamanlanabilir kaynaklara dönüştürerek Agent’ın görev mantığına odaklanmasını sağlar.
Bu çerçeve seçimi de kolaylaştırır. Kurumsal test yığınları ve mevcut betik varlıkları kendi yollarında kalabilir; istek düzeyinde kontrol gerektiren karmaşık web uygulamaları protokol tabanlı nesle uygundur; model tarafından planlanan ve uzun süre kararlı çalışması gereken görevlerde ise ilk iki neslin teknolojileri yine kullanılabilir, ancak ortam katmanı ayrıca çözülmelidir. Senaryonuzda işlemlerin gerçek bir kullanıcı tarafından yapılıyormuş gibi görünmesi gerekiyorsa, bunu hangi nesil kullanılırsa kullanılsın otomasyon framework’ü tek başına sağlayamaz.
Teknik yolun dışında bir sınır daha vardır: otomatik işlemler hedef platformun kurallarına ve yerel yasalara uymalıdır. Teknik olarak çalışması, iş açısından uygun olduğu anlamına gelmez.
