Yapay zeka ile test, bilgi tabanı kadar iyidir: RAG, test standartları ve kodu özetlemek

Test yazan bir model yalnızca ona verdiğiniz kadarını bilir. İki ekip aynı modeli kullanıp çok farklı testler alabilir; çünkü fark nadiren modeldedir. Fark, arkasındaki bilgidedir: gereksinimler, iş kuralları, belgeler, kayıtlar ve kod. RAG (retrieval-augmented generation, yani getirerek zenginleştirilmiş üretim), bu bilginin model testi yazdığı anda ona ulaşma yoludur. RAG'i kötü beslerseniz agent kendinden emin ama yanlış testler yazar.

Yapay zeka ile testin pratikte işe yarayıp yaramayacağına üç şey karar verir: doğru beslenen bir bilgi tabanı, test standartlarınıza uyan testler ve modele ulaşmadan önce özetlenen kaynak kod.

1. Bilgi tabanı sizin test dayanağınızdır

Test diliyle bilgi tabanı, test dayanağıdır: testlerin türetildiği malzeme. Yapay zeka ile test için içinde şunlar olmalı:

• Sürüm bilgisiyle birlikte gereksinimler ve kabul kriterleri.

• Hafızada değil, yazılı olarak iş kuralları, limitler ve hata mesajları.

• API sözleşmeleri ve ekran akışları.

• Geçmiş hatalar ve nasıl düzeltildikleri; çünkü hatalar aynı yerlerde toplanır.

• Mevcut test case'leri; böylece agent kapsamı tekrar etmek yerine genişletir.

Dışarıda bıraktıklarınız da en az bunlar kadar önemli. Güncelliğini yitirmiş belgeler, yarım kalmış taslaklar ve aynı kuralın üç ayrı sürümü, getirme adımına üç farklı cevap verir; agent yanlış olanı seçebilir. Hangi kaynağın esas olduğunu işaretleyin, her belgeye tarih koyun ve artık doğru olmayanı kaldırın.

2. RAG'i doğru besleyin

Bilgi tabanı ancak getirme adımı doğru parçayı doğru anda getirirse işe yarar. Farkı birkaç kural yaratır:

• Boyuta göre değil, anlama göre bölün. Her parçada bir gereksinim, bir uç nokta ya da bir ekran olması, kuralı bağlamıyla birlikte tutar. Sabit boyutlu parçalar kuralları ortadan böler.

• Üst bilgi ekleyin. Ürün alanı, sürüm, kaynak türü ve sahibi, getirme adımının sıralamadan önce süzmesini sağlar.

• Her adımda kaynağı gösterin. Bir adım hangi parçadan geldiğini gösteremiyorsa testte yeri yoktur. Getirme bir şey bulamazsa agent tahmin etmek yerine bunu söylemelidir.

• Getirmeyi ölçün. Gereksinimlerden bir örnek alın ve doğru parçanın gelip gelmediğine bakın. Gelmiyorsa daha iyi prompt'lar testleri düzeltmez.

• Güncel tutun. Bir kayıt değiştiğinde ya da kod birleştirildiğinde dizini yeniden oluşturun. Eskimiş bir dizin geçen çeyreğin ürününü test eder.

3. Test standartları hâlâ geçerli

Agent'ın yazdığı bir test, bir kişinin yazdığıyla aynı standardı karşılamalı. Kurumunuz ISO/IEC/IEEE 29119'u ya da ISTQB yaklaşımını izliyorsa, bu standardı bir gözden geçirenin aklında değil, bilgi tabanında ve agent'ın talimatlarında tutun.

• Her case'in bir kimliği, ön koşulları, adımları, beklenen sonucu ve kapsadığı gereksinime bir bağlantısı olsun.

• Tasarım teknikleri bilerek seçilsin: limitler için sınır değer analizi, girdiler için denklik sınıfları, kural kombinasyonları için karar tabloları, akışlar için durum geçişleri. Kendi hâline bırakılan bir model yalnızca mutlu yolu yazar.

• Adlandırma, öncelik ve şablonlar test yönetim aracınızın beklediğiyle uyumlu olsun.

• Düzenlemeye tabi sektörlerde bir case'teki her değişiklik ve her koşu için denetim izi tutulsun.

Sonra üretilen case'lerden bir örneği, insanların yazdığı case'ler için kullandığınız kontrol listesiyle gözden geçirin.

4. Kaynak kodun tamamını modele veremezsiniz

Büyük bir bağlam penceresi bile gerçek bir ürünün kod depolarını alamaz; çok fazla metin verilen model de ortadaki ayrıntıları kaçırır. Kaynak kodun test için kullanılmadan önce özetlenmesi gerekir.

• Katman katman özetleyin: önce depo, sonra servis ya da modül, sonra dosya. Her modül için amacını, dışa açık arayüzlerini, veri modellerini, iş kurallarını, bağımlılıklarını ve hata yönetimini kaydedin.

• Testin ihtiyaç duyduğu bilgileri koruyun. "Tutar limite eşit ya da büyükse incelemeye gider" kuralını atlayan bir özet, sınır değer testini de kaybeder. Doğrulama kuralları, limitler, durum kodları ve hata mesajları özetlemeden sağ çıkmalı.

• Yalnızca değişeni güncelleyin. Deponun tamamını değil, bir commit'in dokunduğu dosyaları yeniden özetleyin.

• Özetle kaynağı birleştirin. Test yazılırken modele ilgili modüllerin özetlerini ve değişikliğin dokunduğu fonksiyonların gerçek kodunu birlikte verin.

• Seçerken çalışma zamanı verisini kullanın. Çalışma zamanı kapsamı, bir akışın gerçekte hangi kodu çalıştırdığını gösterir. Bağlama neyin girmesi gerektiği konusunda dosya adlarından daha iyi bir rehberdir.

Cunda'da bunu nasıl uyguluyoruz?

TestingOps agent'ları kod depolarınızı, takip araçlarınızı ve belgelerinizi okur ve her test adımını orada bulduklarına dayandırır. Her adım kanıtını gösterir; kanıt yoksa agent tahmin etmek yerine bunu söyler. Bir bilgi grafiği gereksinimleri case'lere, case'leri sonuçlara bağlar; neyin kapsandığını ve neyin hiç koşmadığını görürsünüz. CoverOps her testin çalışan servislerde hangi satırları çalıştırdığını kaydeder; böylece bir akışın gerçekte hangi koda ulaştığını görürsünüz. İkisi de bulutta, özel bulutta ya da on-prem çalışır; bilgi tabanı kendi ağınızda kalabilir.

Kısa bir kontrol listesi

• Her gereksinim ve kural için esas kabul edilen, tarihli tek bir kaynak var mı?

• Bilgi tabanı anlama göre bölünmüş ve üst bilgiyle etiketlenmiş mi?

• Üretilen her adım kaynağını gösteriyor mu?

• Test standardınız agent'ın talimatlarına yazılmış mı?

• Kaynak kod, limitler ve kurallar korunarak katman katman özetleniyor mu?

• Kayıtlar ve kod değiştiğinde dizin güncelleniyor mu?

Daha geniş bir resim için yapay zeka ile test otomasyonu rehberimizi okuyun.