Agentic Testing: Yazılım Yaşam Döngüsünde Testin Yeni Dönemi

Klasik test otomasyonu deterministik bir betiktir: şu butona tıkla, şu metni bekle. Betiği insan yazar, uygulama değişince insan düzeltir. Agentic testing (ajan tabanlı test) ise bir hedefle başlar: kullanıcı sepete ürün ekleyip ödeme adımına gelebilmeli. Ajan uygulamayı keşfeder, adımları kendisi çıkarır, çalıştırır, sonucu yorumlar ve gerekirse planı günceller.

Farkı şöyle özetleyebiliriz: otomasyon nasıl sorusunu insandan alır, ajan ise ne sorusunu insandan alıp nasıl kısmını kendisi çözer. Bu, test kapsamını genişletmeyi ucuzlatıyor ama yeni bir risk getiriyor. Ajanın yorumladığı başarı, sizin kastettiğiniz başarı olmayabilir.

Pratik ayrım: agentic testing, betiksiz keşif testleri ve test üretimi için güçlü; deterministik regresyon testinin yerini almıyor, onu üretiyor ve bakımını yapıyor. Üretilen test yine de kodda duran, tekrar çalıştırılabilir bir artefakt olmalı.

Son 12 ayda agentic testing deneysel olmaktan çıktı.

Araç tarafında Playwright 1.56 (Ekim 2025) planner, generator ve healer agent'larını getirdi. Ocak 2026'daki 1.58 Playwright CLI ve skill desteğini ekledi; Nisan 2026'daki 1.59 agent'ların test debug etmesi için --debug=cli, komut satırından Trace inceleme, ekran kaydıyla çalışma kanıtı ve LLM'e uygun kısa aria snapshot modunu sundu. Temmuz 2026'daki 1.62 ile Playwright MCP sunucusu ve CLI doğrudan Playwright paketine dahil oldu.

Benimseme tarafında Stack Overflow 2026 anketine göre (30.903 yanıt) geliştiricilerin %58'i test yazmak ya da iyileştirmek için AI kullanıyor. SmartBear'ın Q3 2026'da 1.436 kişiyle yaptığı ankette katılımcıların %65'i test kapsamının en az %41'ini AI'ın ürettiğini ya da bakımını yaptığını söylüyor; %84'ü AI testlerini en az bir insan incelemesinden geçiriyor, %46'sı AI ile üretilmiş kodun production'da hata verdiğini yaşamış.

DORA'nın Mayıs 2026 ROI raporu da aynı noktaya basıyor: AI benimsemesinin getirdiği geçici verim düşüşünün nedenlerinden biri test ve değişiklik onay süreçlerini uyarlama ihtiyacı.

Ekim 2025'te yayımlanan Playwright 1.56, üç yerleşik ajan tanımı getirdi. Planner uygulamayı keşfeder ve specs klasörüne Markdown formatında bir test planı yazar; girdi olarak bir istek, ortamı hazırlayan bir seed test ve isteğe bağlı bir ürün gereksinim dokümanı alır. Generator bu planı alıp seçicileri ve doğrulamaları canlı uygulamada kontrol ederek tests klasörüne Playwright testleri üretir. Healer ise başarısız bir testi tekrar oynatır, arayüzdeki karşılık gelen elementi bulur ve bir düzeltme önerir; düzeltemezse testi atlanmış olarak işaretleyebilir.

Kurulum npx playwright init-agents komutuyla yapılıyor ve ajan tanımları VS Code, Claude Code ve opencode gibi hedefler için üretiliyor. Önemli bir not: Playwright sürümünü güncellediğinizde ajan tanımlarını da yeniden üretmeniz öneriliyor; 2026'da 1.59 ve 1.62 sürümleri agent'ların kullandığı CLI ve MCP katmanını epey değiştirdi.

Bu yapının değeri ara çıktılarda: Markdown plan insan tarafından okunup onaylanabilir, üretilen test de normal kod incelemesinden geçer. Ajan karar verir, ama kararın izi repoda kalır.

Kendini onaran test fikri cazip: buton id'si değişti, ajan yeni elementi buldu, test yeşile döndü. Ama burada ciddi bir tuzak var. Test kırıldığında iki olasılık vardır: ya test eskidir ya da uygulama bozulmuştur. Healer ajanı bu ikisini her zaman ayırt edemez.

Senaryo: ödeme sayfasında Siparişi Onayla butonu yanlışlıkla devre dışı kaldı. Healer, ekranda benzer görünen Sepete Dön butonunu bulup testi geçirirse, gerçek bir regresyonu sessizce gizlemiş olur. Bu, kırmızı testten daha tehlikeli bir yeşil testtir.

Korunma yolları somut. Healer'ın yaptığı her değişiklik otomatik merge edilmesin, pull request olarak gelsin. Doğrulama satırlarının, yani expect ifadelerinin ajan tarafından gevşetilmesi ayrı bir uyarı tetiklesin. Playwright dokümantasyonu da healer'ın işlevi bozuk bulduğunda testi atlayabildiğini söylüyor; atlanan test sayısını CI raporunda ayrı bir metrik olarak izleyin, sıfırdan farklıysa birisi baksın.

Test oracle (test kâhini), bir çıktının doğru olup olmadığına karar veren mekanizmadır. Ajan bir formu doldurup gönderebilir; ama gelen 4.250 TL toplamın doğru olup olmadığını nereden bilecek? Bu bilgi kodda değil, iş kuralında yaşıyor.

Ajanın test üretiminde en zayıf olduğu yer burası. Ekranda görüneni doğrulayan, yani mevcut davranışı beklenen davranış sayan testler üretmeye eğilimli. Bu, hatalı davranışı teste kilitlemek demek. Literatürde buna snapshot körlüğü de denebilir.

Çözüm, ajana kâhini dışarıdan vermek. Ürün gereksinim dokümanını, kabul kriterlerini ya da birkaç örnek girdi ve beklenen çıktı tablosunu planner'a girdi yapın. Örneğin: 3 ürün, yüzde 10 kupon, 1.000 TL üzeri kargo bedava. Ajan bu tablodan sınır değer testleri türetebilir. İnsan kâhini tanımlar, ajan kapsamı genişletir; iş bölümü bu şekilde sağlıklı.

Agentic testing'in ikinci anlamı, ajanların kendisini test etmek. LLM tabanlı bir özellik aynı girdiye her seferinde aynı cevabı vermez; assertEquals burada çalışmaz. Bunun yerine eval (değerlendirme) setleri kullanılıyor: temsilci girdiler, kabul edilebilir çıktı aralığı ve bir puanlama yöntemi.

Puanlama üç katmanda yapılabilir. Deterministik kontroller: çıktı geçerli JSON mu, zorunlu alan var mı, yasaklı kelime geçiyor mu. Model tabanlı değerlendirme: başka bir modelin bir rubriğe göre puanlaması, yani LLM-as-judge. İnsan değerlendirmesi: küçük ama düzenli bir örneklem.

Pratik eşik: Anthropic'in Ocak 2026 tarihli eval rehberi gerçek hatalardan türetilmiş 20-50 görevle erken başlamayı öneriyor; set büyüdükçe her prompt veya model değişikliğinde CI'da çalıştırıp geçme oranını sürümler arası kıyaslayın. Aynı rehber pass@k (k denemeden en az biri başarılı) ile pass^k (k denemenin hepsi başarılı) ayrımını da hatırlatıyor; müşteriye dönük bir akışta tutarlılık, yani pass^k daha anlamlı. Tek bir başarısız vakaya değil, oranın düşmesine bakın. Üretimde görülen her hatayı yeni bir eval vakasına çevirmek, setin zamanla gerçekçi kalmasını sağlar.

Agentic testing'i SDLC'ye eklerken en sık hata, onu her commit'te tam keşif modunda çalıştırmak. Keşif pahalı ve yavaştır; her çalıştırma model çağrısı demek. Daha iyi bir yerleşim üç katmanlı: pull request'te sadece ajanın daha önce ürettiği deterministik testler koşar; gece çalışan bir işte planner yeni akışları keşfeder ve aday test önerir; healer yalnızca kırılan testler için tetiklenir.

İnsan rolü kaybolmuyor, yer değiştiriyor. Test mühendisi betik yazmaktan çok plan onaylıyor, kâhin tanımlıyor ve ajanın önerdiği değişiklikleri inceliyor. Bu bir beceri değişimi: test tasarımı, risk analizi ve alan bilgisi daha değerli hale geliyor.

Anti-pattern: ajanın ürettiği yüzlerce testi incelemeden repoya almak. Test sayısı kalite metriği değildir. Bin tane yüzeysel test, on tane kritik akış testinden daha az güven verir ve CI süresini uzatır.