Geçen hafta Text2Test uygulamasının tüm arayüzünü sıfırdan yeniden kurduk. Her sayfayı. Giriş, dashboard, test editörü, plan sihirbazı, sonuçlar, ayarlar, faturalandırma. Hepsini Claude Design üzerinde yaptık.

Statik mockup'lar değil. Her sayfa tamamen etkileşimli. Gerçek durumlar, gerçek akışlar, baştan sona tıklayarak gezebileceğiniz gerçek bileşenler. Ürünün bir resmi değil, çalışan bir prototipi.

Claude Design, ekranlardan eksiksiz bir handoff dokümanı üretti. Her bileşen, her durum, her akış yazıya döküldü. Onu Claude Code'a bıraktık, MCP sunucumuz Text2Test'e bağladı ve dakikalar içinde 137 yapısal test senaryosu geri geldi. Her biri blocker, critical ya da major olarak önceliklendirilmiş. Her biri mutlu yol (happy path), uç durum ya da negatif olarak sınıflandırılmış.

Etkileşimli olması neden önemliydi

Statik bir mockup size bir ekranın nasıl göründüğünü söyler. Etkileşimli bir prototip ise ne yaptığını söyler. Test üretimi için bütün fark buradadır.

Giriş formu doğrulama durumları olan gerçek bir bileşen olduğunda model, boş gönderimin hata gösterdiğini, hatalı biçimlendirilmiş bir e-postanın reddedildiğini, parola alanının bir minimum uzunluğu olduğunu görebilir. Bu durumlar test senaryolarının ta kendisidir. Düz bir görsel bir avuç jenerik kontrol üretirdi. Etkileşimli yapı uç durumları da üretti, çünkü uç durumlar gerçekten oradaydı ve okunabiliyordu.

Kaynak ne kadar zenginse kapsam da o kadar zengin olur. Etkileşimli bileşenler, ekran görüntülerinden çok daha zengin bir kaynaktır.

Handoff dokümanı neden önemliydi

Claude Design bize yalnızca görsel bir dosya vermedi. Her ekranı, her bileşeni, her etkileşimi, her durum geçişini anlatan yapılandırılmış bir doküman üretti. Text2Test'e verdiğimiz şey tasarım dosyasının kendisi değil, bu dokümandı.

Bu önemli, çünkü handoff dokümanı taşınabilir. Claude Code da okuyabilir, MCP sunucumuz da, sürecin devamındaki herhangi bir araç da. Tasarım niyeti ile makinenin okuyabildiği yapı arasındaki köprüdür.

Fiilen, tasarım kendi spesifikasyonunu üretti.

Tasarımdan test üretmek neden önemli

Test senaryoları hep ürünün ardından yazıldı. Bir tasarımcı mockup'ı teslim eder. Bir mühendis onu geliştirir. Bir QA mühendisi ticket'ı okur, tasarım dosyasını açar ve gördüklerini test senaryolarına çevirir. Bazen Gherkin. Bazen düz metin. Bazen script tabanlı bir araç.

Kapsam boşlukları işte bu çeviriden doğar. Tasarımcı boş durumun nasıl görünmesi gerektiğini biliyordu. Mühendis hatırladı. Ticket'ta bundan söz edilmedi. QA mühendisi bunun için hiç test yazmadı. Hata yayına çıktı.

Tek doğru kaynak tasarımın kendisi olursa bu çeviri adımı ortadan kalkar. Test planı, birinin ürüne dair yorumunu değil, gerçek ürünü yansıtır.

Gerçekte ne oldu

Etkileşimli yeniden tasarımları Claude Design üzerinde tamamladık. Her ekran gerçek bileşenlerle ve gerçek durumlarla, wireframe'lerle değil.

Claude Design handoff dokümanını üretti. Onu, MCP sunucumuzun Text2Test'e bağlı olduğu Claude Code'a bıraktık.

Tek bir prompt. Test senaryolarını üret.

137 tane geri geldi. Yapılandırılmış halde. Her birinde:

Öncelik: blocker, critical ya da major
Kategori: ana akış, uç durum ya da negatif
Adımlar: düz metinle yazılmış, çalıştırılmaya hazır
Beklenen sonuç: kullanıcının görmesi gereken şey

Bir QA mühendisinin ekran başında bir saat geçirdikten sonra yazacağı şeyler. MCP bunu dakikalar içinde yaptı ve uç durumları atlamadı.

Asıl değişim

Bugün yapay zeka destekli test araçlarının çoğu, geliştirilmiş bir ürünü alıp onun için test yazmaya çalışır. Canlı sayfaya bakar, seçicileri ayrıştırır, neyin önemli olduğunu çıkarsamaya çalışır. Niyetten değil, çıktıdan yola çıkarlar.

Test planı tasarımın kendisinden üretildiğinde niyetten yola çıkarsınız. Ekibin var olması konusunda anlaştığı şeyden. Mühendisin geliştirmesi gereken şeyden.

Bağlı, yapay zeka tabanlı test derken kastettiğimiz bu. Test paketiniz ürününüzden ayrı değildir. Ürünün inşa edildiği kaynağın aynısından üretilir.

Sırada ne var

Claude Design kaynaklardan yalnızca biri. Yol haritamız aynı MCP katmanı üzerinden Figma, Jira, GitHub ve OpenAPI spesifikasyonlarını kapsıyor. İlke aynı. Ürününüzle ilgili doğru nerede yaşıyorsa, testleriniz oradan üretilmelidir.

Bir SaaS ürünü geliştiriyor ve hızlı yayına çıkıyorsanız, bu QA döngünüzün nasıl göründüğünü değiştirir. Göz atmaya değer.