Yapay zekayla test senaryosu nasıl üretilir: istem, denetim ve test verisi

Yapay zeka test üretiminde neyi hızlandırır, neyi hızlandırmaz

Büyük dil modelleri, bir gereksinimden çok sayıda test fikri çıkarmakta iyidir. Bir kullanıcı hikâyesini, bir API tanımını ya da bir fonksiyonun kodunu verdiğinizde, kimsenin aklına gelmeyen birkaç uç durumu da listeye ekleyebilir. Asıl kazanç, boş sayfayla başlama maliyetinin ortadan kalkmasıdır. Taslak hazırdır, sizin işiniz onu mühendis gözüyle elemektir.

Yapay zeka şunları üretmez: ürünün gerçek iş kuralını, sizin sisteminizdeki istisnaları, "bu alan neden zorunlu" sorusunun yanıtını. Bu bilgiyi siz vermezseniz model, genel internet bilgisinden makul görünen ama sizin sisteminizde yanlış olan beklenen sonuçlar yazar. Bu nedenle sağlıklı bir akışta model fikir ve taslak üretir, beklenen sonucu doğrulayan kişi insan kalır.

Pratik bir ayrım: modelden "ne test edilmeli" listesi ve "bu girdi için hangi veri kombinasyonları denenmeli" sorusunun yanıtını isteyin. "Bu davranış doğru mu" kararını ise gereksinim belgesine ve ürün sahibine bırakın.

Girdiyi hazırlamak: kabul kriteri, kural ve bağlam

Üretilen senaryoların kalitesi, verdiğiniz girdinin kalitesini aşamaz. İstemde (prompt) şunlar bulunmalıdır:

• Özelliğin tek cümlelik amacı ve kullanıcı rolü
• Kabul kriterleri, tercihen "verildiğinde, olduğunda, o zaman" biçiminde
• Alan kuralları: zorunlu mu, hangi biçim, hangi alt ve üst sınır
• Bilinen istisnalar ve yasaklı durumlar
• Test ortamının sınırları: hangi veri hazır, hangi servis taklit ediliyor
• İstediğiniz çıktı biçimi: tablo, madde listesi ya da doğrudan test kodu

Gizli bilgiyi istemden uzak tutun. Müşteri adı, kimlik numarası, gerçek e-posta ya da üretim ortamından kopyalanmış kayıtlar istem içine yapıştırılmaz. Gerçek kayıt yerine alanın yapısını ve kuralını anlatın; örnek değerleri model üretsin. Kurumunuzun yapay zeka kullanım politikası varsa hangi aracın hangi veriyle kullanılabileceği orada yazar, ona uyun.

Adım adım iş akışı: istemden çalışan teste

Şu sıra, küçük ve büyük ekiplerde işe yarayan bir akıştır.

Bağlamı verin ve önce senaryo başlıklarını isteyin, ayrıntıyı değil. Başlık düzeyinde bir liste okumak kolaydır ve eksik kategori hemen görünür.

Kategorilere göre genişletmesini isteyin: olumlu akış, olumsuz akış, sınır değerler, boş ve eksik girdi, yetki farkları, eşzamanlı işlemler. Model bu kategorilerden birini atlıyorsa açıkça sorun.

Her senaryo için ön koşul, adımlar ve beklenen sonuç alanlarını doldurtun. Beklenen sonuçları gereksinimle tek tek karşılaştırın. Burada yakalanan her uyuşmazlık, sürece değer katan asıl iştir.

Eleme. Birbirinin kopyası olan, aynı sınıfın tekrarını yapan ve ürünün zaten desteklemediği durumlara ait senaryoları silin. Eşdeğerlik sınıfları ve sınır değer mantığı, hangisinin gereksiz olduğunu görmenin en sağlam yoludur.

Aktarma. Kalan senaryoları test yönetim aracınıza ya da otomasyon koduna aktarın. Kod istiyorsanız, projenizin mevcut test kalıplarını (isimlendirme, yardımcı fonksiyonlar, bekleme stratejisi) örnek olarak istemde verin. Aksi halde model her seferinde farklı bir stil üretir ve ortaya bakımı zor bir test yığını çıkar.

Örnek: sepet indirim kuralı için senaryo üretimi

Örneğin bir e-ticaret ekibi şu kuralı test edecek olsun: kupon kodu yalnızca belirli bir kategoride geçerli, belirli bir tutarın üzerindeki sepetlerde uygulanır ve başka bir kuponla birleştirilemez. Modele bu kuralı, tutar eşiğini ve kategori listesini verirsiniz.

Modelden gelen taslakta olumlu akış (uygun sepet, geçerli kupon), olumsuz akış (eşiğin altında sepet, süresi dolmuş kupon), sınır değer (eşiğin tam üstünde ve tam altında tutar), birleştirme yasağı (başka bir kuponun reddedilmesi) ve sepet değiştiğinde indirimin yeniden hesaplanması gibi başlıklar çıkar. Bunların bir kısmı beklediğiniz şeylerdir; değerli olan, listede olmayan birkaç tanesidir: sepetten ürün çıkarılınca eşiğin altına düşülmesi, farklı kategorideki ürünle karışık sepet, kupon uygulandıktan sonra para birimi değişimi.

İnsan denetiminde şunları yakalarsınız: model "iade edilen üründe indirim geri alınır" diye bir beklenen sonuç yazmışsa bunun gerçek iş kuralı olup olmadığına ürün sahibi karar verir. Model adım adım yazdığı için emin görünür; ama bu kural belgenizde yoksa o senaryo ya sorulacak bir soruya ya da silinecek bir satıra dönüşür.

Test verisi üretimi: gerçekçi, tutarlı ve güvenli

Test verisi, yapay zekanın en az riskle en çok zaman kazandırdığı alandır. Alan tanımını (tür, biçim, sınır, bağımlılık) verip sentetik kayıt isteyebilirsiniz: adres biçimleri, uzun ve özel karakterli isimler, boş ve aşırı uzun metinler, geçersiz tarih kombinasyonları, Türkçe karakter içeren değerler.

Dikkat edilecek noktalar:

• Kayıtlar arası tutarlılık: sipariş tablosu ile müşteri tablosunu ayrı ayrı ürettirirseniz yabancı anahtarlar tutmaz. İlişkili kayıtları aynı istemde, ilişkiyi tarif ederek isteyin.
• Tekrarlanabilirlik: ürettiğiniz veriyi dosyaya kaydedin ve sürüm kontrolüne alın. Her test koşusunda yeniden üretilen veri, hatayı yeniden üretmeyi imkânsız kılar.
• Gerçekçi olmayan ama geçerli değerler: model sıklıkla "çok düzgün" veri üretir. Gerçek dünyadaki kirli veriyi (baştaki boşluklar, çift boşluk, farklı büyük küçük harf) özellikle isteyin.
• Kişisel veri: gerçek kişilere ait görünen kimlik ya da telefon numaralarını test ortamına almayın. Biçimi doğru ama kimseye ait olmayan değerler kullanın.

Kod üretirken yardımcı bir betik de isteyebilirsiniz: veriyi doğrudan değil, veriyi üreten küçük bir betiği modelden alın, betiği gözden geçirin, sonra siz çalıştırın. Böylece üretim sürecini denetleyebilir ve tohum değerle aynı veriyi yeniden üretebilirsiniz.

Üretilen testi denetlemek: kontrol listesi

Üretilmiş bir test, çalışıyor olması nedeniyle doğru değildir. Her üretilen testte şu soruları sorun:

• Beklenen sonuç gereksinime dayanıyor mu, yoksa modelin tahmini mi?
• Test gerçekten bir şey doğruluyor mu? Hiçbir koşulda başarısız olamayan bir doğrulama (örneğin sonucun boş olmadığını denetleyip içeriğe bakmamak) kapsamı şişirir ama koruma sağlamaz.
• Test, uygulamanın iç yapısına aşırı bağlı mı? Her küçük yeniden düzenlemede kırılan testler ekibe yük olur.
• Aynı davranışı birden çok test mi doğruluyor?
• Test verisi her çalıştırmada aynı mı, bağımsız mı?

Teste gerçek bir sınama yapmak için mutasyon testi fikrini kullanabilirsiniz: koddaki bir koşulu bilerek bozun ve testin başarısız olup olmadığına bakın. Başarısız olmuyorsa test o satırı korumuyor demektir. Kapsam raporu da yararlıdır; ama yüksek kapsam tek başına kalite göstergesi değildir. Kapsam raporunda boş kalan bölgeleri modele gösterip hedefli senaryo isteyebilirsiniz, ardından yine aynı denetimi uygulayın.

Sık yapılan hatalar ve nasıl önlenir

Yapay zekanın ürettiği testlerde tekrar eden sorunlar vardır.

Gereksinimsiz üretim: Model, belgede olmayan davranışı uydurur. Önlem: her beklenen sonuç için kaynak gösteren bir sütun isteyin, kaynağı gösteremeyen satırı silin ya da soruya çevirin.

Aşırı sayıda senaryo: Çok sayıda senaryo görmek verimlilik izlenimi verir, ama gözden geçirilmeyen senaryo teknik borçtur. Önlem: önce öncelik sırası isteyin, riskli alanlara yoğunlaşın.

Kırılgan seçiciler ve bekleme düzeni: Model, arayüz testlerinde sabit bekleme ya da kırılgan konum bilgileri kullanabilir. Önlem: projenizin standart seçici ve bekleme kalıbını istemde zorunlu kılın.

Güncelliği kaybeden bağlam: Gereksinim değişti, istem eski kaldı. Önlem: istem şablonunu da kod gibi sürüm kontrolünde tutun.

Gizlilik ihlali: Üretimden alınan örnek kayıt isteme yapıştırılır. Önlem: istem şablonuna "gerçek veri kullanma" kuralını yazın ve kurum politikasına bağlayın.

Mindset bağlamı: bu beceri hangi ekip için

Test senaryosu üretimi, QA mühendisleri kadar geliştiriciler ve ürün analistleri için de geçerli bir beceridir; çünkü senaryonun kalitesi gereksinimin netliğiyle başlar. Yapay Zeka Destekli Kod İnceleme ve Test Üretimi programı, test üretimini ve kapsam boşluğunu kapatmayı ele alır; modül başlıkları arasında test verisi ve sahte nesne üretimi, kırılgan test üretiminin önlenmesi ve mutasyon testiyle test kalitesinin ölçülmesi yer alır. Test Otomasyonu ve QA Temelleri ise senaryo tasarım tekniklerini ve otomasyon aracı seçimini işler. Bu programlar birlikte, hem senaryoyu iyi tasarlamak hem de üretilen çıktıyı denetlemek isteyen yazılım ekipleri için bir temel oluşturur.