Ajanik Testler - E2E test yığınında ajanların rolü

• Slack mühendislik ekibinin, ajan tabanlı E2E (uçtan uca) testlerin mevcut deterministik testlerin yerini alıp alamayacağını doğrulamak için 200'den fazla ajanik iş akışını çalıştırdığı deneyin sonuçları
• Geleneksel E2E testleri belirli UI yollarını zorunlu kılarken, ajanlar hedefin (goal) başarılıp başarılamadığını doğrular ve aynı sonuca farklı yollarla ulaşır
• Ajan çalıştırmaları çalıştırma başına 15–30 dolar maliyetli ve 10 dakikadan uzun sürse de, güvenilirlik açısından belirgin kullanım alanları var
• Playwright MCP yaklaşımı, CLI ve kod üretimi yaklaşımına göre daha düşük hata oranı ve daha az token kullanımı gösterdi; sonuçları belirleyen ana unsur çalıştırma ortamının kararlılığı oldu
• Ajanik testler mevcut testlerin yerini almıyor; bunun yerine test piramidinin en üstüne, keşif, hata ayıklama ve karmaşık davranış doğrulama katmanı olarak ekleniyor

---

Yolculuklardan hedeflere (From Journeys to Goals)

• Geleneksel E2E testleri, UI boyunca ilerleyen belirli bir yolculuğu (journey) doğrular → tıkla → tıkla → gir → assert
• Ajan tabanlı testler, "thread mesajı gönder" gibi bir talimatla ifade edilen hedefe ulaşılıp ulaşılamadığını doğrular → hedef → ajanın uyum sağlaması → sonucun doğrulanması
  • Temel fark: "Testler yolculuğu zorlar, ajanlar ise hedefi doğrular"
• Tüm iş akışı (giriş → arama → sonuç → sıfırlama) sabit kalsa da, gerçek işlem sırası her seferinde değişti
  • Farklı giriş yöntemleri (arama önerisine tıklama vs Enter ile girme)
  • Farklı gezinme kalıpları (aramayı yeniden çalıştırma vs mevcut durumu yeniden kullanma)
  • Eklenen veya atlanan adımlar (ek tıklamalar, snapshot'lar, ara işlemler)
• Bu esneklik, güvenilirlik, maliyet ve çalışma süresi açısından bazı ödünleşimleri beraberinde getiriyor

• Ortaya çıkan soru

  • Çalıştırma başına 15–30 dolar maliyetli ve 10 dakikadan uzun süren bu yaklaşımın modern test iş akışına girip giremeyeceği temel soru oldu
  • 200'den fazla çalıştırmanın sonucunda, bunun geleneksel testlerden temelde farklı olduğu ama yüksek güvenilirlik ve net kullanım alanları sunduğu görüldü
  • Kod yazmayı, başarısızlıkları ayıklamayı ve UI'yi doğrudan manipüle etmeyi mümkün kılan büyük dil modeli (LLM) ilerlemeleri, yeni bir yürütme modelini mümkün hale getirdi

Deney düzeni (Our Experiment)

• Güvenilirlik, çalışma hızı ve maliyeti ölçmek için farklı yapılandırmalarda 200'den fazla otomatik çalıştırma yapıldı

• Çalıştırma modelleri (üç yaklaşım)

  • Agent + Playwright MCP: Ajan, önceden tanımlı tarayıcı eylemleriyle (öğe tıklama, giriş yapma, DOM durumunu okuma vb.) tarayıcıyla etkileşime girer ve kalıcı bağlamı (DOM snapshot'ları ve loglar) korur
  • Agent + Playwright CLI: Kabukta Playwright CLI komutlarını çalıştırarak işlemleri her seferinde tek adım halinde yürütür; güncellenmiş UI durumuna bakıp sonraki eyleme karar verir
  • Generated Playwright Tests: Yapay zeka ajanı, doğal dil açıklamasından deterministik Playwright kodu üretir; bunu standart E2E test olarak çalıştırır ve geçene kadar yinelemeli olarak iyileştirir

• Deney ortamı

  • MCP ve CLI ajan modeli: Claude Sonnet 4.5
  • Üretici Playwright test modeli: Claude Opus 4.6
  • Çalıştırma: etkileşimsiz Claude Code (claude -p)
  • Tarayıcı araçları: Playwright MCP, Playwright CLI
  • Ortam: Slack Dev API MCP; tüm deneyler, production dışı veriler içeren bir test workspace'inde yürütüldü

• Test akışları (iki karmaşıklık seviyesi)

  • Thread Reply (basit): Kanal oluşturma, mesaj gönderme, thread yanıtı verme ve thread durumunu doğrulama içeren yaklaşık 15–20 adımlı iş akışı
  • Search Discovery (orta karmaşıklık): Arama terimi girme, sonuçlarda gezinme, görünümler arasında geçiş (arama, kanal, thread) ve beklenen sonucu doğrulama içeren yaklaşık 25–30 adımlı iş akışı

• Girdi biçimleri

  • Doğal dil (NL): İş akışını ve beklenen sonucu, insanların okuyabileceği adım adım bir liste olarak anlatan talimatlar
  • Yapılandırılmış YAML: Aynı iş akışını adım, eylem, hedef ve beklenen sonuç olarak açıkça tanımlayan yapısal biçim
    • Fark ayrıntı düzeyinde değil, ifade biçiminde: doğal dilin ajan tarafından yorumlanıp eşlenmesi gerekirken, YAML bu eşlemeyi daha açık tanımlar

• Deney matrisi

  • Her yapılandırma 20 kez çalıştırıldı; toplam 5 deney (MCP-NL, MCP-YAML, CLI-NL, CLI-YAML, üretilmiş test-NL), Thread Reply ve Search Discovery akışlarının ikisine de uygulandı

Gözlemler (What We Observed)

• Sonuç özeti

  • Agent (Playwright MCP): hata oranı %0 (thread reply) / yaklaşık %12 (search discovery), ortalama 5–8 dakika
  • Agent (Playwright CLI): hata oranı yaklaşık %12 / yaklaşık %20, ortalama 9–11 dakika
  • Generated Playwright Tests: hata oranı yaklaşık %8 / yaklaşık %48, ortalama 3 dakika

• Güvenilirlik (Reliability)

  • Akış karmaşıklaştıkça güvenilirlik farkı daha belirgin hale geldi
  • Playwright MCP en kararlı yaklaşım oldu — basit senaryolarda neredeyse %0 hata oranı, karmaşık akışlarda bile %0–12 aralığı
  • Playwright CLI daha yüksek hata oranına sahipti (yaklaşık %12–20); bunların çoğu model akıl yürütmesinden değil, kimlik doğrulama işleme, gezinme zamanlaması ve oturum kararsızlığı gibi çalıştırma sorunlarından kaynaklandı
  • Üretilmiş testler basit akışlarda iyi sonuç verdi (yaklaşık %8), ancak karmaşık iş akışlarında ciddi biçimde kötüleşti (yaklaşık %48)
    • Tamamen yanlış değillerdi; genellikle akışın %70–80'ine kadar ilerleyip son etkileşim veya assert aşamasında başarısız oldular
    • Başarısızlığın nedeni UI durum değişkenliği ve soyutlama uyumsuzluğuydu — gevşek tanımlanmış doğal dil akışlarından üretildiler ve mevcut page object soyutlamalarını yeniden kullanarak hassas öğe hedeflemeyi zorlaştırdılar
  • Karmaşıklık arttıkça güvenilirlik farkı büyüdü; MCP gibi ajan-native yürütme modelleri daha kararlı göründü
    • MCP, uygulamanın gerçek zamanlı ve kararlı görünümünü korurken; CLI her adımda snapshot'lardan durumu yeniden kuruyor, bu da akış uzadıkça tutarsızlık birikimine yol açıyor
    • MCP, aynı oturum içinde önceki başarılı etkileşimleri yeniden kullanıyor gibi görünüyor; CLI ise her adımda yeniden başlıyormuş hissi veriyor (bu açıkça ölçülmedi)

• Hız (Speed)

  • Üretilmiş testler tutarlı biçimde en hızlı yöntem oldu (yaklaşık 3 dakika); MCP yaklaşık 5–8 dakika, CLI yaklaşık 9–11 dakika
  • Üretilmiş test rakamları, test üretimi + çalıştırmayı içeriyor; her test bir kez üretildikten sonra 5 kez çalıştırılıp ortalaması alındı
    • Gerçek saf çalıştırma çok daha hızlıydı — thread reply yaklaşık 32 saniye, search discovery yaklaşık 45 saniye
    • Tekrarlı çalışan CI ortamlarında, tek seferlik üretim maliyeti ihmal edilebilir hale gelir ve deterministik testler verimli biçimde ölçeklenir
  • Ajan iş akışlarında her çalıştırmada yeniden maliyet oluşur — her adım, UI durumunu gözlemleme, sonraki eylem üzerine akıl yürütme, eylemi yürütme ve sonucu doğrulama içerir

• Uyarlanabilirlik (Adaptability)

  • Aynı eylem sırasını izleyen çalıştırmalar yalnızca yaklaşık %20 oldu; çoğunda aynı hedefe götüren farklı geçerli UI yolları bulundu
    • Menüyü farklı sırada açmak
    • Biraz farklı UI öğeleri seçmek
    • Alternatif gezinme akışları kullanmak
  • Ölçüm için çalıştırmalar arası action signature karşılaştırıldı — ajanın yaptığı araç çağrıları ve UI eylemlerinin sıralı listesi
    • Karşılaştırma öncesi normalizasyon yapıldı: parametreler, bekleme/snapshot eylemleri ve eşdeğer araç varyasyonları (fill vs type) birleştirildi; böylece yalnızca anlamlı farklar hesaplandı
  • Nihai sonuç doğru olsa bile çoğu zaman eylem sırası farklıydı — geleneksel E2E tek bir deterministik yolculuğu zorunlu kılarken, ajanlar arayüzü keşfederek hedef duruma ulaşılıp ulaşılmadığını doğruluyor

• Maliyet ve kaynağı (Cost and Where It Comes From)

  • Ajan çalıştırmaları genellikle çalıştırma başına 15–30 dolar maliyetli; bu da geleneksel testlerden çok daha pahalı
  • Aynı search discovery akışı için token kullanımı analizi
    • MCP (Opus 4.6) yaklaşık 3.8M, MCP (Sonnet 4.5) yaklaşık 3.5M, MCP (Haiku 4.5) yaklaşık 5.7M
    • CLI (Opus 4.6) yaklaşık 6M, Code Gen (Opus 4.6) yaklaşık 7M
  • Hangi modelin kullanıldığından çok, nasıl çalıştırıldığı daha önemli — Haiku daha fazla token kullansa da, tüm MCP yaklaşımları CLI ve Code Gen'den daha az token kullandı
  • Claude Code'un oturum yürütme biçimi analiz edildiğinde, temel API'nin stateless olduğu ve bu nedenle her turda tüm sistem prompt'unun ve tüm konuşma geçmişinin yeniden gönderildiği görüldü
    • Maliyeti model çıktısından çok, bağlamın ne kadar hızlı biriktiği ve tur sayısı belirliyor
  • Tur sayıları: MCP (Opus/Sonnet) yaklaşık 40, MCP (Haiku) yaklaşık 60, CLI (Opus) yaklaşık 85, Code Gen (Opus) yaklaşık 70
    • CLI'de her tarayıcı etkileşimi eylem, bekleme, snapshot, okuma ve öğe sorgulama gibi birden fazla komuta bölünüyor; bu yüzden ortalama 85 tur gerekiyor
    • MCP, etkileşimi ve durum döndürmeyi tek bir round-trip içinde birleştiriyor
    • Her ek tur, tüm sistem prompt'u maliyetini ve önceki konuşma bağlamının yeniden gönderilme yükünü artırıyor
  • Bağlamı dolduran unsurlar
    • MCP ve CLI: tarayıcı snapshot'ları ana payload'u oluşturuyor — Playwright MCP'nin döndürdüğü accessibility tree snapshot'ları sonraki tüm turlarda birikiyor
    • Code Gen: her yeniden denemede tüm hata izleri, assert başarısızlıkları ve DOM durumu içeren test runner çıktıları birikiyor
  • Maliyetin büyük kısmı zaten görülmüş içeriğin yeniden gönderilmesinden geliyor; tur başına yeni bilgi miktarı çok küçük
  • Token kullanımı henüz optimize edilmiş değil; önerilen azaltma yöntemleri arasında prompt caching, context compaction ve snapshot sıklığını azaltma yer alıyor
  • Maliyet nedeniyle bugün için yüksek frekanslı CI çalıştırmalarından çok, hedefli hata ayıklama ve keşif amaçlı testler için daha uygun; gelecekte model ve araçlarla iyileşebilir

• Altyapının önemi (MCP vs CLI)

  • Yalnızca model değil, yürütme ortamı da güvenilirliği ciddi biçimde etkiliyor — MCP'de %0–12, CLI'de %12–20 hata oranı
  • CLI hatalarının çoğu kimlik doğrulama ve gezinme sorunlarından (giriş hataları, timeout'lar, oturum kararsızlığı) kaynaklandı; bunlar ajan akıl yürütmesinden değil, çalıştırma katmanından doğan sorunlardı
  • Playwright MCP, yapılandırılmış tarayıcı primitive'leri ile ajan araç çağrısı iş akışının sıkı entegrasyonunu sağlarken; CLI, ajan ile tarayıcı arasına ek bir katman yerleştiriyor
  • Paralelleştirme farkı: MCP'de eşzamanlı çalıştırma daha kolay, CLI'de paralelleştirme zor olduğu için çoğu çalışma sıralı yapılıyor
  • Güvenilirlik, hız ve maliyet yalnızca modele değil, çalıştırma ortamının kararlılığına ve tasarımına bağlı

• Yürütme yeteneğinin sınırları (Execution Capability Boundaries)

  • Bu deney, tek oturumlu UI iş akışlarına odaklandı
  • Workspace'ler arası akışlar veya birden fazla tarayıcı penceresi açan iş akışları, yürütme modeli seçimini en az ajan kadar önemli hale getiren başka zorluklar getiriyor
    • MCP'de uzun akışlarda gözlem döngüleri arttıkça maliyet sorunu oluşabilir
    • CLI'de çoklu tarayıcı oturumlarını yönetmek, koordinasyon karmaşıklığı ve yüksek token kullanımı yaratabilir
  • Her iki yaklaşım da bunu destekleyebilir, ancak ödünleşimleri farklı; bu deneyde incelenmedi, fakat değerlendirme ekipleri için önemli bir nokta

Test piramidinde ajanik testlerin yeri

• Ajanik testler mevcut yaklaşımın yerini almaz; onun üstüne yeni bir yetenek katmanı ekler

• Deterministik E2E testleri

  • CI'da hızlı ve tekrarlanabilir regresyon kontrolleri için en uygun yaklaşım
    • İnsan tarafından yazılabilir veya yapay zeka tarafından üretilebilir
    • Hızlı ve tekrarlanabilir, CI dostu
    • Düşük operasyonel maliyet
    • Belirli UI yolculuklarını zorunlu kılar

• Ajanik testler

  • Sabit bir script'i çalıştırmak yerine hedeften başlar — UI'yi gözlemler, mevcut durumu çıkarımlar, istenen sonuca nasıl ulaşacağını belirler
    • Karmaşık UI davranışlarını keşfetme
    • Flaky iş akışlarında hata ayıklama
    • Production hatalarını yeniden üretme

• Ajanik katmanı içeren test piramidi

  • Sistem perspektifinden bakıldığında, ajanik testler de E2E ile aynı seviyede gerçek kullanıcı iş akışlarını UI üzerinden doğrular; fark, iş akışının yürütülme biçimidir
  • Gelecekte en etkili test stratejisi ikisini birleştirecek gibi görünüyor — deterministik testler CI için kararlı temel sağlarken, ajanik testler piramidin en üstünde keşif, hata ayıklama ve karmaşık davranış doğrulamasını üstlenecek