Test Otomasyonunda MCP: Yapay Zekaya Eller ve Gözler Vermek

Bir QA uzmanının Claude Code + MCP ile test otomasyonunu hızlandırma, kaliteyi koruma ve projeyi “akıllandırma” üzerine notları.

Test otomasyonuyla uğraşan herkes bilir: işin büyük kısmı aslında test düşünmek değil, testi ayakta tutmaktır. Locator aramak, aynı kalıp kodu bir kez daha yazmak, kopyalayıp yapıştırdığın senaryoyu projeye uydurmak… Zihnin değil, ellerin yorulduğu işler.

Son aylarda iş akışıma giren bir şey, bu dengeyi ciddi biçimde değiştirdi: MCP. Eskiden sprintlere yayılan otomasyon işleri artık günler içinde, üstelik review ve doğrulama dahil tamamlanabiliyor. Bu yazıda ne öğrendiğimi, nelere dikkat ettiğimi ve yarın kendi projenizde nasıl deneyebileceğinizi anlatmak istiyorum — pazarlama dili olmadan, bir QA’in gözünden.

MCP nedir? (Bir cümle + bir benzetme)

MCP (Model Context Protocol), yapay zekanın dış araçlara — tarayıcıya, Jira’ya, veritabanına — tek bir standart üzerinden bağlanmasını sağlayan açık bir protokol.

En sevdiğim benzetme USB-C. Eskiden her cihazın kendi kablosu vardı; telefon ayrı, yazıcı ayrı. USB-C geldi, hepsi tek porta takılır oldu. MCP de yapay zeka için o evrensel port. Yeni bir araç eklemek, yeni bir entegrasyon yazmak değil; aynı prize takmak.

İkinci benzetme bence daha da anlatıcı: odaya kapatılmış zeki bir çalışan düşünün. Ne kadar zeki olursa olsun, odadan size sadece fikir verebilir — “şunu şöyle yapardım” der ama hiçbir şeye dokunamaz. Bilgisayarını, tarayıcısını, sistem erişimini verdiğinizde ise işi kendisi yapmaya başlar. MCP, yapay zekaya o erişimi veren şey.

Kısacası: modelin beyni zaten var; MCP ona eller ve gözler veriyor.

Kritik ayrım: Claude Code zaten projeyi tanıyor — MCP’nin farkı ne?

Bu, en çok karıştırılan nokta — ben de başta karıştırdım.

Claude Code’u terminalde proje klasörünüzde çalıştırdığınızda dosyalarınızı zaten okuyabiliyor: Page Object’lerinizi, step tanımlarınızı, konfigürasyonları. Bu MCP değil; Claude Code’un yerel dosya ve terminal erişimi. Yani statik proje bilgisi.

MCP’nin fark yarattığı yer, repoda olmayan şeyler.

Kaynak kod size component’leri söyler. Ama gerçek render edilmiş DOM, gerçek element ID’leri, mobilde hangi butonun görünür olduğu, dinamik class hash’leri — bunlar çalışma anında oluşur, repoda durmaz. Playwright MCP, yapay zekaya o canlı sayfayı görme imkânı verir: tarayıcıya bağlanır, DOM’u inceler, gerçek ID’yi bulur, tıklar.

Bunu ilk gördüğümde açıkçası bir süre ekrana bakakaldım. Locator’ı kafadan tahmin etmiyor — sayfanın gerçeğine bakıyor. Kararlı, flaky olmayan testlerin sırrı da tam olarak bu: locator bir tahmin değil, canlı DOM’dan okunan gerçek.

Aynı mantık Jira için de geçerli: kabul kriterini ticket’tan kopyala-yapıştır yapmıyorum; doğrudan Jira MCP ile okunuyor. Araya insan eli girmeyince aktarım hatası da sıfırlanıyor.

Bağlam her şeyi değiştirir

Aynı isteği iki farklı ortama verin: “Bir tıklama içeren test senaryosu yaz.”

Bağlamsız bir sohbet size çalışan görünümlü bir kod verir — ama sıfırdan yeni bir click metodu yazar, çünkü projenizde zaten duran metodu görmez. Locator’ları tahmin eder. Sonuç: projeye uydurmak için beş-altı prompt daha, kod tekrarı, zaman ve token kaybı. Bunu yaşayarak öğrendim.

Bağlamlı Claude Code ise mevcut click metodunuzu görür ve onu kullanır. Locator stratejinizi bilir. İlk turda projeye uyan kod çıkarır.

Hızın asıl kaynağı da bu. Yapay zeka “daha hızlı yazdığı” için değil, mekanik iş ortadan kalktığı için hızlanıyorsunuz — locator arama, boilerplate, kopyala-yapıştır-düzelt döngüsü yok. Düşünme kısmı hâlâ sizde. İyi ki de öyle.

Kuralları bir kere yazın: CLAUDE.md

İlk haftalarda her prompt’a aynı şeyleri yazıyordum: “Thread.sleep kullanma, unique locator kullan, şu tag’leri ekle…” Bir noktada fark ettim ki kendimi tekrarlıyorum — tam da otomasyonun çözmesi gereken şeyi elle yapıyorum.

Çözüm: hepsini projenin köküne bir CLAUDE.md dosyasına taşımak. Claude Code bu dosyayı her oturumda otomatik okuyor. Benim dosyamda neler var:

• Bağlamı küçük tut — hangi iş hangi dosyalara bakar; tüm repoyu açmak yok.
• Locator öncelik merdiveni — #id → prefix → class → XPath (son çare). Ve bir "kesinlikle yapma" listesi: hash'li class, pozisyon bazlı locator.
• Bekleme kuralı — Thread.sleep asla; polling/retry, waitForVisible.
• Kod tekrarı checklist’i — yeni step yazmadan önce: mevcut step var mı? Helper var mı? Aynı selector başka isimle var mı?
• Tag taksonomisi — regresyon, smoke, öncelik ve bug tag’lerinin ne zaman kullanılacağı.
• MCP kuralları — sayfa keşfinde önce tüm form ID’lerini çek, gerçek ortamda form göndermeden önce onay iste, dummy data kullan.

Sonuç: prompt’larım kısaldı, çıktı tutarlılaştı. Kuralı bir kez yazdım, yapay zeka her seferinde uyguluyor.

Üç katmanı şöyle özetliyorum: MCP araçları verir, CLAUDE.md kuralları verir, agent (Claude Code) ikisini birleştirip işi yapar.

Asıl büyük efor: regresyonu ayakta tutmak

Şimdi gelelim bence en az konuşulan ama en çok zaman yiyen konuya.

QA’in otomasyonda en büyük eforlarından biri, regresyon setlerindeki yüzlerce senaryonun her an çalışabilir ve güncel kalmasını sağlamak. Ürün durmuyor: sürekli yeni geliştirmeler, değişen akışlar, değişen DOM yapısı. Ve her değişiklik, bir yerlerde bir senaryoyu kırıyor.

Klasik bakım döngüsünü bilirsiniz: sabah rapora bakarsınız, kırmızılar var. Hata hangi senaryoda? Hangi adımda? Hata türü ne — element mi bulunamadı, timeout mu, assertion mı patladı? Sebebi UI değişikliği mi, gerçek bug mı, yoksa o gün ortamın keyifsizliği mi? Sonra fix, sonra tekrar koşturup doğrulama… Tek tek bakıldığında küçük işler; toplamda saatlerinizi alan, üstelik insanı en çok yıpratan efor. Çünkü yaratıcı değil, dedektiflik kısmı bile bir süre sonra mekanikleşiyor.

MCP burada devreye girince döngü şuna dönüşüyor: yapay zeka cucumber report’a bağlanıyor, fail’leri tarıyor, hata loglarını okuyor, fail’in adımını ve türünü tespit ediyor. Locator kırıldıysa Playwright MCP ile canlı sayfaya bağlanıp güncel DOM’dan doğru locator’ı buluyor, CLAUDE.md’deki locator merdivenine uygun şekilde düzeltiyor ve testi koşturup yeşile döndüğünü doğruluyor.

Oku → teşhis et → düzelt → doğrula döngüsü kapandığında, bakım “sabahı yiyen iş” olmaktan çıkıp dakikalar süren bir kontrol haline geliyor. Ve dürüst olmak gerekirse, hız kadar şunu da seviyorum: bakımın mekanik kısmı gidince, geriye gerçekten dikkat isteyen fail’ler kalıyor — gerçek bug’lar. Yani dikkatim, dikkat edilmesi gereken yere gidiyor.

Hız tamam, ya kalite ve istikrar?

“Hızlı yazılan otomasyon güvenilir olur mu?” sorusu haklı bir soru. Evet, oluyor. Nasıl ölçüyorum:

• Unique locator’lar — kırılgan XPath değil, canlı DOM’dan doğrulanmış kararlı seçiciler.
• Thread.sleep yok — polling ve retry; flaky’liğin bir numaralı panzehiri.
• Kabul kriterine bağlı assertion’lar — “bir şeyler render oldu” değil, spesifik kontroller.
• Data isolation — testler birbirinin verisini ezmiyor.
• Spec-first üretim — önce senaryo listesi, gözden geçirme, sonra kod. Spec’i değiştirmek bedava; kodu değiştirmek pahalı.

Ve en önemlisi: üretilen her metodu, step’i, locator’ı kontrol ediyorum; testleri çalıştırıp yeşil gördükten sonra işi bitmiş sayıyorum. Yapay zeka üretiyor, sorumluluk bende.

Yarın deneyebileceğiniz 5 adım

1. Claude Code’u proje kökünde açın, küçük bir işle başlayın. Dosyalarınızı zaten okuyacaktır.
2. CLAUDE.md yazın. Locator stratejiniz, bekleme kurallarınız, tag’leriniz, kod tekrarı checklist’iniz. Her satır için test: “Bunu silsem yapay zeka hata yapar mı?” Yapmazsa silin — kısalık bir performans gereksinimidir.
3. Playwright MCP’yi bağlayın, ilk iş olarak bir sayfanın tüm form element ID’lerini çıkarttırın. Canlı DOM’un farkını ilk burada hissedeceksiniz.
4. Spec-first çalışın: önce senaryo listesi isteyin, gözden geçirin, sonra kod yazdırın. Doğrudan koda atlatmayın.
5. Her şeyi MCP yapmayın. mvn, git, dosya işleri zaten terminalden hallolur. MCP'yi repoda olmayan şeylere saklayın: canlı tarayıcı, Jira, test raporları, veritabanı.

Kapanış

MCP’yi özel kılan şey bence şu: yapay zekayı bir “soru-cevap aracı” olmaktan çıkarıp, sizin araçlarınızla çalışan bir çalışma arkadaşına dönüştürüyor. Tarayıcınızı görüyor, raporunuzu okuyor, ticket’ınızı anlıyor — ve siz kuralları bir kez doğru yazdıysanız, sizin standartlarınızda iş çıkarıyor.

Eğer test otomasyonuyla uğraşıyorsanız, MCP’ye bir hafta sonu verin. İlk canlı DOM keşfini gördüğünüzde ne demek istediğimi anlayacaksınız.