Tek Doğru Kaynaktan Yapay Zeka ile Test Senaryosu Üretimi: Nasıl Çalışır, Neden Önemli

Kısaca: Yapay zeka destekli test araçlarının çoğu, test senaryolarını bir sohbet penceresine ne yapıştırırsanız ondan üretir. Bu yüzden çıktı hep biraz eksik kalır. Tek doğru kaynaktan üretim ise ürününüzün gerçekten tanımlandığı yerlere (Jira, Linear, Figma, OpenAPI, Postman, GitHub) bağlanır, bu kaynaklar arasında bir bağlam grafiği kurar ve ürününüzün bugün ne yaptığını yansıtan test senaryoları üretir, ardından bunları otomatik olarak saklar ve sürümler. Text2Test bunu MCP sunucusu üzerinden yapar.

ChatGPT'yi açarsınız. Bir kullanıcı hikayesi yapıştırırsınız. Karşınıza duvar gibi bir test senaryosu yığını çıkar. Sonra bunları Confluence'a kopyalar, yeniden biçimlendirir, önceliğe göre etiketler ve o hafta QA'i kim yürütüyorsa onunla paylaşırsınız.

Bunu 40 kez tekrarlayın, bir haftayı yakmış olursunuz. Ürününüz biraz karmaşıksa belki 10 günü.

Bugün erken aşama SaaS ekiplerinin çoğunda işleyen iş akışı bu. Test üretimi için yapay zekayı kullanacak kadar uyanık olan ama tesisat işini hâlâ elle yapmak zorunda kalan tek kişilik geliştiriciler ve iki kişilik kurucu ekipler. Test senaryolarını yapay zeka yazar. Bir insan da yapay zeka ile tablo arasında aracılık eder.

Zamanın, bağlamın ve kapsamın sessizce kaybolduğu yer işte o aracılık adımıdır.

Tek doğru kaynaktan test senaryosu üretimi nedir?

Tek doğru kaynaktan test senaryosu üretimi, test senaryolarını bir kişinin prompt'a yapıştırdığı metinden değil, doğrudan ürününüzün gerçek tanımını barındıran sistemlerden üretme pratiğidir. Bir özelliği sohbet modeline hafızanızdan anlatmak yerine, gereksinimlerinizin, tasarımlarınızın, API sözleşmelerinizin ve kodunuzun zaten yaşadığı araçları bağlarsınız ve yapay zeka bunları üretim anında okur. Model ürünün güncel halini gördüğü için, tek doğru kaynaktan yapay zeka ile test senaryosu üretimi ürünü birinin hatırladığı haliyle değil, şu anki haliyle yansıtır.

Asıl Sorun Test Senaryosu Yazmak Değil

Gerçekte neyin yavaş olduğunu netleştirelim. Modelin test senaryosu üretmesi saniyeler sürer. Darboğaz, bunun etrafındaki her şeydir: modele verilecek doğru spesifikasyonu bulmak, geçen seferden bu yana neyin değiştiğine karar vermek, çıktıyı başka birinin çalıştırabileceği şekilde yapılandırmak ve sonucu ekibin altı hafta sonra bulabileceği bir yerde saklamak. Daha hızlı bir model bunu çözmez, çünkü yavaş olan kısım hiçbir zaman model değildi.

Tohum aşamasındaki SaaS ekiplerinin çoğunda tek doğru kaynak üç dört araca dağılmış durumdadır. Kullanıcı hikayeleri Jira'da ya da Linear'da yaşar. API spesifikasyonları Postman'de ya da bir OpenAPI dosyasında durur. Arayüz akışları Figma prototipleri olarak ya da, daha sık görüldüğü gibi, bir Notion dokümanındaki gayriresmi açıklamalar olarak vardır. Resmin tamamını geliştirici kafasında taşır, yapay zeka ise yalnızca prompt penceresine yapıştırılan parçayı görür.

Yapay zekanın ürettiği test senaryolarının "yakın ama tam değil" hissi vermesinin nedeni budur. Model kısmi bir görüntüyle çalışır. Ödeme akışının Stripe'tan gelen bir webhook'a bağlı olduğunu ya da onboarding akışının iki sprint önce yeniden tasarlandığını bilmez. Eksik bir resimden makul görünen test senaryoları üretir ve birisi boşlukları hafızasından elle doldurur.

Bu, işe yaramayı bırakana kadar işe yarar. Ve genellikle bir müşteri demosundan hemen önce işe yaramayı bırakır.

Burada "Tek Doğru Kaynak" Gerçekte Ne Anlama Geliyor

Tek doğru kaynak tek bir doküman değildir. Ürününüzün nasıl davranması gerektiğini tanımlayan, birbirine bağlı kaynakların bütünüdür. Tipik bir erken aşama SaaS için bu şunları kapsar:

Proje yönetim aracınızdaki gereksinimler ve kullanıcı hikayeleri. OpenAPI ya da Postman koleksiyonlarındaki API spesifikasyonları. Figma'daki arayüz tasarımları ve akışları. CI/CD pipeline'ınızdaki mevcut test sonuçları ve hata geçmişi. Ve GitHub ya da GitLab üzerinden kod tabanının kendisi.

Yapay zeka ile test senaryosu üretimi, yapıştırılmış tek bir paragraf yerine bu bağlamın tamamından çalıştığında çıktı kalitesi kökten değişir. Model bir kullanıcı yolculuğunu birden çok endpoint boyunca izleyebilir. Bir alanın son Figma revizyonunda yeniden adlandırıldığını görebilir. Tahmin etmek yerine OpenAPI spesifikasyonunuzdaki gerçek doğrulama kurallarına başvurabilir.

Bir test senaryosu üreticisini yapay zeka tabanlı bir test paketinden ayıran şey budur. Üretici size çıktı verir. Bağlı bir sistem size kapsam verir.

Tek Doğru Kaynaktan Yapay Zeka ile Test Senaryosu Üretimi Nasıl Çalışır

Süreç dört aşamadan oluşur ve bunları anlamak, sonuçların elle prompt yazmaktan neden bu kadar farklı olduğunu açıklar.

1. Aşama: Araçlarınızı bağlayın. Platform, ürününüzle ilgili doğrunun zaten yaşadığı araçlarla entegre olur. Kod ve CI durumu için GitHub. Gereksinimler için Jira ya da Linear. Arayüz akışları için Figma. API sözleşmeleri için OpenAPI. Her prompt için bağlamı elle derlemek yerine sistem onu otomatik olarak çeker.

2. Aşama: Bağlam grafiğini kurun. Bu, ne kadar elle prompt yazarsanız yazın ölçekli biçimde tekrarlayamayacağınız adımdır. Yapay zeka, kaynaklarınız arasındaki ilişkileri haritalar. Hangi kullanıcı hikayesinin hangi API endpoint'ine karşılık geldiğini, hangi Figma ekranının hangi rotaya denk düştüğünü ve hangi mevcut testlerin belirli bir akışı zaten kapsadığını bilir. Üretimi jenerik olmaktan çıkarıp akıllı kılan şey bu bağlam grafiğidir.

3. Aşama: Kapsamın farkında olarak üretin. Yapay zeka, bağlam grafiğinin tamamını kullanarak mutlu yolları (happy path), uç durumları, negatif senaryoları ve sınır koşullarını kapsayan test senaryoları üretir. Ama asıl önemlisi, bunu neyin zaten test edildiğini ve neyin edilmediğini bilerek yapar. Boşluklara öncelik verir. Spesifikasyonun değiştiği ama test senaryolarının güncellenmediği alanları işaretler. Gece yarısı ChatGPT'ye prompt yazan bir kurucunun istemeyi asla akıl etmeyeceği uç durumları üretir.

4. Aşama: Saklayın, sürümleyin ve bakımını yapın. Üretilen test senaryoları platformun içinde yaşar: özelliğe göre düzenlenmiş, önceliğe göre etiketlenmiş, kaynak gereksinimine geri bağlanmış halde. Bir spesifikasyon değiştiğinde etkilenen test senaryoları yeniden üretim için işaretlenir. Sessizce bayatlayan Confluence sayfaları yok. 47. satırı iki ay önce kullanımdan kaldırılmış bir akışa atıfta bulunan tablolar yok.

Text2Test MCP Sunucusu Bunu Nasıl Yapıyor

Text2Test, yazılım testi için özelleşmiş yapay zeka modelleri kullanır ve araçlarınıza bir MCP sunucusu üzerinden bağlanır. Text2Test MCP sunucusunu tek doğru kaynağınıza bağlayın, dört aşamanın tamamını o yürütsün: kaynaklarınız arasında bağlam grafiğini kurar, kapsamın farkında olarak test senaryoları üretir ve test paketini otomatik olarak saklar, sürümler ve bakımını yapar. Kopyala yapıştır yok. Yeniden biçimlendirme yok. Üç ay önceki bir ürünü anlatan bayat bir Confluence sayfası yok.

Bir testi kelimelerle anlatmayı mı tercih edersiniz? Text2Test düz metinden test senaryosu üretimini de destekler. Böylece herhangi bir dilde yazılmış bir cümle, çalışan deterministik bir teste derlenir. Bir adım kod gerektirdiğinde otomatik test script'i üretimi onu düz metin bir açıklamadan yazar ya da kendi Playwright script'inizi yapıştırırsınız.

Tohum Aşamasındaki SaaS Ekipleri İçin Neden Önemli

Bu acıyı en keskin hisseden ekipler, kaybedecek en çok şeyi olanlardır. Tek başına bir kurucusunuz ya da iki teknik kurucu ortaksınız. Hızlı geliştiriyorsunuz. Muhtemelen her gün deploy ediyorsunuz. Ve takvimde, berbat etmeyi göze alamayacağınız bir müşteri demosu var.

Eski iş akışının size maliyeti şöyle.

Zaman. Test senaryolarını bir sohbet modeliyle elle üretmek, sonra biçimlendirip saklamak, 15 ila 20 özelliği olan bir ürün için 7 ila 10 gün sürer. Bu, kurucu bir ekibin kelimenin tam anlamıyla sahip olmadığı bir zamandır.

Kapsam boşlukları. Bir sohbet modeline tek bir kullanıcı hikayesiyle prompt verdiğinizde o hikayenin test senaryolarını alırsınız. Hikayeler arasındaki etkileşimlerin, özelliklerin birleşme biçiminden doğan uç durumların ya da üçüncü pivotunuzdan sonra önem kazanan regresyon senaryolarının test senaryolarını almazsınız.

Bayat dokümantasyon. Confluence sayfaları ve tablolar kendilerini güncellemez. Ocakta yazdığınız test senaryoları, nisanda artık var olmayan bir ürünü anlatır. Ama birileri onları hâlâ referans olarak kullanıyordur ve bu sahte güven, hiç test olmamasından daha tehlikelidir.

Demo kaygısı. Cuma günü bir özellik yayınlayıp pazartesi demo yapmış her kurucu bu duyguyu bilir. Son merge ödeme adımını bozdu mu? Onboarding akışı hâlâ çalışıyor mu? Güncel ve kapsamlı bir test kapsamı olmadan toplantıya bilerek değil, umarak girersiniz.

Tek doğru kaynaktan yapay zeka ile test senaryosu üretimi günleri dakikalara sıkıştırır ve umudun yerine veriyi koyar.

Uç Durumlar ve Ana Akışlar: Yapay Zeka Gerçekte Ne Üretiyor

Elle prompt yazmanın en yaygın eksiklerinden biri uç durum kapsamıdır. Bir kurucu ChatGPT'ye bir kullanıcı hikayesi yapıştırdığında genellikle ana akışı ve bir avuç bariz negatif durumu geri alır. Geçersiz e-posta biçimi. Boş bırakılmış zorunlu alan. Belki bir zaman aşımı senaryosu.

Ama gerçek ürünler daha az bariz yollarla bozulur. Bağlı bir yapay zeka sistemi, aynı kaynağa aynı anda erişen eşzamanlı kullanıcı oturumları için, geçerli JSON döndüren ama beklenmedik boş (null) alanlar içeren API yanıtları için, UTC'de çalışan ama kullanıcının yerel ayarında bozulan saat dilimine bağlı mantık için ve yalnızca özellikler belirli bir sırayla kullanıldığında ortaya çıkan durum geçişleri için test senaryoları üretir.

Bir demoyu çökerten senaryolar bunlardır. Ve bağlamın farkında olan bir sistemin yakaladığı senaryolar da tam olarak bunlardır, çünkü ürününüzün nasıl çalıştığının tam resmini görebilir.

Confluence'ı Test Deposu Olarak Kullanmayı Bıraktığınızda Ne Değişir

Test senaryolarını statik dokümanlardan çıkarıp bağlı bir platforma taşımak, iş akışını üç somut biçimde değiştirir.

Birincisi, test senaryoları güncel kalır. Bir gereksinim değiştiğinde platform o gereksinimden türetilen her test senaryosunu işaretler. Bir tabloda elle arama yapmak yerine tek bir işlemle yeniden üretirsiniz.

İkincisi, kapsam görünür hale gelir. Hangi özelliklerin test senaryosu olduğunu, hangilerinin olmadığını görebilirsiniz. Hangi test senaryolarının aktif gereksinimlere bağlı olduğunu, hangilerinin kullanımdan kalkmış spesifikasyonlara atıfta bulunduğunu görebilirsiniz. Kapsam boşlukları görünmez olmaktan çıkar.

Üçüncüsü, ekip aynı sayfada kalır. İki kişilik kurucu ekipler için platform, QA konusunda ortak tek doğru kaynak haline gelir. İki kurucu da neyin test edildiğini, neyin edilmediğini ve neyin değiştiğini görebilir. Demo sabahı yaşanan "Onu sen test ettin sanıyordum" konuşmaları biter.

Test Senaryosu Üreticisinden Yapay Zeka Tabanlı Test Paketine Geçiş

Piyasa, test senaryosu üreten araçlarla dolu. Çoğu, zaten elle yaptığınız aynı yapay zeka çağrısının etrafına sarılmış bir kabuktan ibaret. Üzerine bir arayüz ekliyorlar. Belki CSV olarak dışa aktarmanıza izin veriyorlar.

Anlamlı değişim üretimde değil. Bağlantıda. Yapay zeka tabanlı bir test paketi araçlarınıza bağlanır, kaynaklarınız arasındaki ilişkileri anlar, bağlamla üretir ve ürününüz geliştikçe test senaryolarının bakımını yapar. Üretim başlangıç noktasıdır. Değerin katlanarak büyüdüğü yer bakım, izlenebilirlik ve kapsam zekasıdır.

Mevcut iş akışınız spesifikasyonları bir sohbet penceresine yapıştırıp sonuçları bir dokümana kopyalamaktan ibaretse, QA'in zor kısmını elle yapıyorsunuz demektir. Yapay zeka yalnızca kolay kısmında yardımcı oluyor.

Soru, yapay zekanın test senaryosu yazıp yazamayacağı değil. Yazabildiği ortada. Soru, test senaryolarınızın nereden geldiklerini bilip bilmediği, ürününüz değiştiğinde güncellenip güncellenmediği ve bir sonraki deploy'unuzdan önce gerçekten önemli olan senaryoları kapsayıp kapsamadığıdır.

Tek doğru kaynaktan üretimin çözdüğü şey budur.

Sıkça sorulan sorular