Bir QA mühendisi bir kullanıcı hikayesinin bir parçasını LLM'e yapıştırıp test senaryosu istediğinde, model çıktıyı yalnızca prompt'ta bulunanlara dayanarak üretir. O prompt'un dışında kalan her bağlam parçası, yani bir Slack yazışmasında, bir tasarım yorumunda, standup'ta sözlü alınmış bir kararda ya da kurumsal hafızada duran her şey istatistiksel tahminle doldurulur. Çıktı kapsamlı görünür. Boşluklar ise görünmezdir.
Yalnızca LLM'e dayalı test senaryosu üretiminin temel sorunu budur: model, kendisine söylenmeyen şeyi test edemez.
LLM'in Ürettiği Test Senaryoları Neden Eksiksiz Görünür Ama Değildir
Her QA mühendisinin tanıdığı bir an vardır.
Bir kullanıcı hikayesini LLM'e yapıştırırsınız. Test senaryosu üretmesini istersiniz. Gelen çıktı etkileyici görünür. Yapılandırılmış. Kapsamlı. Mutlu yolu (happy path), birkaç uç durumu, bazı negatif senaryoları kapsar. İlerleme kaydettiğinizi hissedersiniz.
Sonra yayına alırsınız. Ve test senaryolarında hiç yer almayan bir şey bozulur.
Model yapıştırdığınız şey konusunda yanıldığı için değil. Siz resmin yalnızca bir kısmını yapıştırdığınız için.
Model, tasarımcının üç hafta önce bir yoruma ne eklediğini bilmez. Ürün yöneticisinin standup'ta ne söylediğini bilmez. Bu özelliğin geçen sprintten bilinen ve ekibin farklı biçimde ele almaya karar verdiği bir uç durumu olduğunu bilmez. Prompt'un dışındaki her şey olasılıkla doldurulur. Ortaya çıkan şey makuldür. Gerçek test senaryoları gibi okunur. Ama yapıştırmadığınız kısımlara dair tahminler üzerine kuruludur.
Boşlukları hafızanızdan dolduran sizsiniz. Model yalnızca bunu görünmez kılar.
Yapay Zeka ile Test Üretiminde Oracle Problemi
Yazılım testi araştırmalarında bunun bir adı var: oracle problemi.
Test oracle'ı, bir testin doğru biçimde geçip geçmediğini ya da başarısız olup olmadığını belirleyen mekanizmadır. Testleri koddan ürettiğinizde oracle kodun kendisidir. Kodda bir hata varsa testler bu varsayımı devralır ve kendinden emin biçimde geçer. Bu, 50 QA Uzmanına Sorduk. %61'i Aynı Yanıtı Verdi (İngilizce) yazımızda ele aldığımız senaryonun ta kendisi: yapay zekanın testleri gereksinimlerden yazıp yazmaması gerektiğini sorduğumuzda çoğunluk evet dedi, çünkü gereksinime dayalı üretim tam da bu tuzaktan kaçınıyor.
Google'ın mühendislik araştırması, CI test hatalarının %84'ünün gerçek ürün regresyonlarından değil, kararsız (flaky) ya da yanlış tanımlanmış testlerden kaynaklandığını ortaya koydu. Bunun önemli bir bölümü, en baştan doğru tanımlanmamış testlerden geliyor.
Kapsamlı görünen bir test senaryosu, eksik olduğu açıkça belli olan bir test senaryosundan daha tehlikelidir. Bir test senaryosu eksiksiz göründüğünde onu sorgulamayı bırakırsınız. Kapsama güvenirsiniz. Yayına alırsınız.
Bu, Hacim Kapsam Değildir. Hız Strateji Değildir. yazımızda anlattıklarımızla doğrudan bağlantılı. Yapıştırılmış bir metin parçasından 500 test senaryosu üretmek kapsam değildir. Büyük hacimli, makul görünen tahminlerdir. Ödeme spesifikasyonunu yapıştırdığınızda ödeme akışı çalışır. Peki kartının süresi dolmuş bir kullanıcının aynı anda indirim kodu uygulamaya çalıştığı uç durum? O, dört ay öncesine ait bir yorum zincirinde duruyor ve sohbet penceresini açtığınızda aklınızda bile değildi.
Boşluklar Neden Sessizce Doldurulur
Bunu yakalamayı zorlaştıran şey, modelin neyi varsaydığını bilmemenizdir.
Boşluklar sessizce doldurulur. Çıktı eksiksiz görünür. Onu okursunuz ve bağlamın tamamını bilen beyniniz, boşlukları kapsanmamış oldukları halde kapsanmış gibi okur.
Bu, yeterliyle yetinme (satisficing) olarak adlandırılan, belgelenmiş bir bilişsel yanlılıktır. Bir şey yeterince iyi göründüğünde onda neyin yanlış olduğunu aramayı bırakırız. Yapay zekanın ürettiği test senaryoları, tam da bu kadar yapılandırılmış ve kapsamlı göründükleri için bu yanlılığı tetikler.
Sonuç, hak etmediğiniz bir güven veren bir test paketidir. Dürüst Olmayan Testlerin Gizli Maliyeti yazımızda ele aldığımız gibi, bu yersiz güvenin ölçülebilir bir maliyeti vardır. Sektör araştırmaları, çoğu ekibin en başta hiç geçmemesi gereken hataları araştırmaya yılda 80 bin ile 200 bin dolar arasında harcadığını gösteriyor.
Nasıl Düzeltilir: Tek Doğru Kaynağınızdan Başlayın
İlk refleks prompt'u iyileştirmektir. Daha fazla bağlam eklemek. Hikayenin daha fazlasını yapıştırmak. Uç durumlar konusunda daha net olmak. Bunun sınırlı bir faydası olur. Ama yapısal sorunu çözmez: yazıya dökmediğiniz bağlamı yakalayan test senaryolarına prompt yazarak ulaşamazsınız.
Gerçek çözüm, testleri ekibinizin zaten üzerinde çalıştığı kaynaklardan üretmektir. Eksiksiz olacak şekilde yazılmış Jira ticket'ları. Amaçlanan davranışı yansıtan Figma tasarımları. Sistemin ne yapması gerektiğini tanımlayan API dokümantasyonu. Hafızadan yeniden kurulmuş değil, bilinçli olarak oluşturulmuş gereksinimler.
Tek Doğru Kaynaktan Yapay Zeka ile Test Senaryosu Üretimi: Nasıl Çalışır, Neden Önemli yazımızda açıkladığımız gibi, test senaryoları yapıştırılmış bir metin parçasından değil, bağlı bir tek doğru kaynaktan üretildiğinde tahmin ortadan kalkar. Model, mühendislerinizin özelliği geliştirirken okuduğu şeyin aynısını okur. İmplementasyonu teyit eden testler ile doğruluğu geçerleyen testler arasındaki fark budur.
Öne Çıkanlar
- Prompt'lardan test senaryosu üreten LLM'ler yalnızca prompt'ta olanı test edebilir. Geri kalan her şey tahmindir.
- Makul görünen test senaryoları, eksik olduğu açıkça belli olanlardan daha tehlikelidir, çünkü yeterliyle yetinme eğilimini tetikler ve eleştirel incelemeyi bastırır.
- Oracle problemi, koddan üretilen testlerin koddaki hataları devralması demektir. Bu testler doğruluğu geçerlemek yerine implementasyonu teyit eder.
- Çözüm daha iyi bir prompt değildir. Testleri bağlı ve eksiksiz bir tek doğru kaynaktan üretmektir: Jira, Figma, API dokümanları ya da düz metin gereksinimler.
- Test ile kod birbirinden bağımsız olduğunda testler hataları gerçekten yakalayabilir. Aynı varsayımları paylaştıklarında aynı kör noktaları da paylaşırlar.
Sıkça Sorulan Sorular
LLM'ler iyi test senaryoları üretebilir mi?
Evet, eksiksiz ve doğru girdi verildiğinde. LLM'in ürettiği test senaryolarının kalitesi, kaynak materyalin eksiksizliğiyle doğru orantılıdır. Bir kullanıcı hikayesinin bir parçası eksik testler üretir. Eksiksiz ve bağlı bir gereksinim ise doğru testler üretir.
Yapay zekanın ürettiği testler bir hata olduğunda bile neden geçer?
Çünkü testler hatayla aynı kaynaktan üretilmiştir. Testleri hatalı bir koddan üretirseniz, testler hatalı kodun ne yaptığını tarif eder ve ona karşı geçer. Oracle problemi budur: test ve implementasyon aynı yanlış varsayımı paylaşır.
Test senaryosu üretimi için en iyi tek doğru kaynak nedir?
Tasarım dosyaları (Figma), gereksinim ticket'ları (Jira), API dokümantasyonu ve implementasyondan bağımsız yazılmış düz metin davranış tanımları. Kodun şu anda ne yaptığını değil, ürünün ne yapması gerektiğini yansıtan her şey.
Text2Test'in ChatGPT'ye bir prompt yapıştırmaktan farkı nedir?
Text2Test, yapıştırılmış metin parçalarına dayanmak yerine doğrudan tek doğru kaynaklarınıza bağlanır. Test senaryoları eksiksiz Jira ticket'larından, Figma tasarımlarından ya da düz metin gereksinimlerden üretilir ve implementasyona göre teyit edilmek yerine gerçek ürün üzerinde çalıştırılır.
Kaynaklar: Google Engineering Blog, kararsız testler üzerine yazı (Micco, 2016), Tricentis State of Testing 2024, LambdaTest Future of QA Survey 2024.