Playwright MCP ve AI agent'lar: 2026'da testlerini gerçekten yazabilir mi?

Bu çeyrek takip ettiğim her QA Slack'inde aynı soru: *"AI'ı uygulamama doğrultup bir test suite'i alsam olmaz mı?"*

Playwright MCP ile cevap artık evet'e hayır'dan daha yakın. Ama "yakın" değil "evet" demek değil. Son iki haftada Playwright MCP'yi üç gerçek müşteri kod tabanında çalıştırdım — bir SaaS checkout akışı, bir B2B dashboard, bir marketplace. Olanları anlatayım.

Playwright MCP tam olarak nedir?

MCP (Model Context Protocol), bir AI agent'ın — Claude, GPT, Cursor, farketmez — Playwright ile doğrudan konuşmasını sağlıyor. Agent şunları yapabilir:

• Uygulamanı gerçek tarayıcıda açar
• İnsan gibi tıklar, yazar, scroll yapar
• Ekran görüntüsü değil, gerçek DOM'u okur
• Az önce yaptığına göre bir .spec.ts dosyası yazar
• O testi koşturur ve geçip geçmediğini izler

Ona *"çıkış yapmış bir kullanıcı için geçersiz kartla checkout akışını test et"* dersin, ürününde tıklar ve repo'na bir Playwright dosyası bırakır.

Bu gerçekten yeni bir şey. Geçen yıl bu bir demoydu. Bu yıl müşterilere fatura kestiğim bir araç.

Harika çalışan %20

Kritik yollar için smoke test'ler. Giriş, kayıt, checkout — net "başarı" ve "başarısızlık" durumları olan akışlar. Agent bunları çakıyor. Bir SaaS onboarding'inde 12 mutlu-yol testi 90 dakikanın altında yazdım.

Selector yazmak. Agent, kırılgan CSS selector'leri yerine getByRole, getByLabel, getByText seçiyor — varsayılan olarak. Review ettiğim junior mühendislerin çoğundan daha iyi.

Boilerplate. Page Object iskeletleri, fixture kurulumu, config dosyaları. Bir öğleden sonrayı yiyen her şey — 10 dakikada bitiyor.

Akışları dokümante etmek. Agent'tan yazdığı testi *açıklamasını* istediğimde, kullanıcı yolculuğunun okunabilir bir özetini alıyorum. Bu bile birden fazla devir toplantısını atlatmamı sağladı.

Hâlâ insan isteyen %80

Dinamik UI'larda flaky selector'ler. Animasyonla açılan modal? 3 saniye sonra kaybolan toast? Agent *şu an* çalışan ama CI'da %20 patlayan bir selector yazar. Bir günü doğru yerlere .waitFor() ve expect.poll() ekleyerek geçireceksin.

İş mantığı uç durumları. Agent "kullanıcı checkout yapabiliyor mu?" sorusunu test eder. "Kullanıcı $0.01'lik ürüne %100 kupon uygularken başka bir sekmede aynı ürünü sepete eklerse ne olur?" sorusunu test etmez. Hacker News'e düşmene mâl olacak hata türü işte bu.

Gerçekçi test verisi. Agent mutlu mutlu test@test.com ve password123 kodun her yerine yapıştırıyor. Testler arası paylaşımlı state, kirli veritabanı — paralel koşuların birbirini yiyecek.

Görsel regresyonlar. MCP piksel değil DOM görüyor. Sessizce 40px dışarı kayan bir buton? Hâlâ geçer.

Yetki ve rol matrisleri. "Bir admin'in görüp bir free kullanıcının göremediği ne?" Agent bir rol için bir test yazar ve biter sanır. Sen 12 istiyordun.

Gerçekten yayına çıkan workflow

İki hafta ve bazı sancılı CI sabahlarından sonra, müşteri işlerinde kullandığım döngü:

1. İnsan akışı sade Türkçe tanımlar. Test başına bir cümle. "Çıkış yapmış kullanıcı süresi dolmuş kartla checkout dener ve spesifik bir hata görür." 2. Agent taslağı yazar. Uygulamayı açar, tıklar, .spec.ts üretir. 3. İnsan selector'leri gözden geçirir. Kırılgan olanları değiştir. Dinamik içeriğe waitFor ekle. Değişken isimlerini proje kurallarına çevir. 4. Agent testi arka arkaya 20 kez koşturur. 20/20 geçerse CI'a girer. Bir kez flake olursa 3. adıma dön. 5. İnsan edge-case'leri ekler. Garip kupon matematiği, race condition'lar, "kullanıcı İstanbul'da 3G'de kırık ekranla olursa" senaryoları. Agent bunları hayal edemez. Sen edebilirsin.

Bu workflow beni sıfırdan test yazmaktan ~3-4x hızlandırıyor. 10x değil. Sana 10x satan sana flake-in-production satıyordur.

Ekibin için ne anlama geliyor?

Solo founder veya küçük ekipsen: kullan. Hemen. İlk haftanın ROI'si zaten yerinde. Tam zamanlı bir QA mühendisinin kapsamına ulaşmayacaksın ama bir hafta sonunda "sıfır test"ten "kritik yol korunuyor"a geçeceksin.

Mevcut bir suite'in varsa: toptan değiştirme. Agent, mevcut pattern'lerini okumakta kötü ve onları çoğaltmamakta daha kötü. *Yeni* akışlar için kullan, eskileri refactor etmek için değil.

Mevcut bir QA ekibin varsa: MCP'yi onlara yedek değil, araç olarak ver. Gördüğüm en iyi kullanım, bir senior QA'nın bir agent'la pair çalışması — agent yazar, insan düşünür. Çıktı üçe katlanıyor.

Rahatsız edici kısım

"AI, QA'nın yerini alacak" söylemlerinin çoğu, QA'nın gerçekte ne olduğunu kaçırıyor. Yazma kısmı — page.click('button') kısmı — hiçbir zaman değerli olan kısım değildi. Değerli olan *"ne ters gidebilir?"* sorusunu sormaktı. Agent bu soruyu soramıyor. Yalnızca senin zaten sormayı düşündüğün soruları cevaplayabiliyor.

Bu da AI test agent'larının QA'yı yok etmediği anlamına geliyor. QA'nın *alt yarısını* — yazma kısmını — yok ediyor ve bir QA mühendisinin kapsayabileceği alanın tavanını yükseltiyor. Düşünme kısmı hâlâ senin.

Founder'san bu aslında güzel haber. Yani her testi bir insanın gözden geçirdiği $1,500'lık Automation Starter, altı ay öncesine göre şimdi 3x daha fazla alan koruyor. Aynı fiyat, daha fazla koruma.

Playwright MCP'yi repo'na kurup ilk 20 testini çıkarmamı ister misin? Automation Starter rezerve et — $1,500, 2 hafta, suite senin.