Çoklu Kombinasyonlar ve Pairwise Testing: Yapay Zeka Sistemlerini Test Etmenin Akıllı Yolu

QA olarak şu soruyla kaç kez karşılaştınız: “Bu konfigürasyonları nasıl test edeceğiz?” ve cevap her seferinde “hepsini” olamaz.

Son 4–5 senedir Sigortacılık sektöründe test alanında çalışıyorum. Açıkçası, fonksiyonel testlerde kombinasyon kapsamından söz etmek, hatta o hesaba girmek çoğu zaman mümkün olmuyor. Çoğunlukla sınır değerleri, iş kritikliğine dayalı risk analizi ve tecrübeye dayalı alan bilgisiyle olası hata kümelerini hedef alarak test planı oluşturuyorum.

Yaklaşık bir yıldır büyük bir sistem değişiminin Pazarlama Kanalları bölümünde Test Lead olarak görev alıyorum. Çok fazla paydaş, çok fazla beklenti ve bunların tam ortasında kronik bir kaynak sıkıntısı. Bir noktadan sonra şunu fark ettim: riskin gerçek boyutunu ve ihtiyaç duyulan kaynağı şeffaf, matematiksel bir şekilde ortaya koymazsam, argümanlar havada kalıyor.

Pairwise testi adını daha önce duymuştum ama içi boş bir kelimeydi benim için. Oldukça sağlam bir temeli olduğunu gördüm. Ilgimi cekince derinlemesine okumalar yaptim. Bir yazi kaleme alarak sizi de bu yöntemle tanıştırmak istedim.

Makaleyi yazarken bir de tarayıcıda çalışan, kurulum gerektirmeyen pairwise hesaplayıcı geliştirdim. Hem Türkçe hem ingilizce kullanabilirsiniz. Parametrelerinizi girip tek tıkla minimum test setini üretebilir, sonucu CSV olarak indirebilirsiniz. **→ Hesaplayıcıyı deneyin .**

Taguchi’nin Fabrikasından Yazılım Testine: Kısa Bir Tarih

Pairwise testing’in kökü yazılım dünyasında değil, 1950'lerin Japonya’sında yatıyor.

Japon mühendis Genichi Taguchi, o yıllarda üretim tesislerinde ciddi bir problemle boğuşuyordu: bir ürünün kalitesini etkileyen onlarca parametre vardı “sıcaklık, basınç, malzeme türü, işlem süresi” ve bunların tüm kombinasyonlarını denemek hem imkânsız hem de ekonomik açıdan saçmaydı. Taguchi’nin çözümü, istatistikçiler Bose ve Bush’un 1940'larda geliştirdiği ortogonal dizileri (orthogonal arrays) üretime uyarlamaktı (Bose & Bush, 1952). Fikir basitti: her parametre çiftini en az bir kez kapsayan dengeli bir deney tasarımı yap; tüm kombinasyonları tek tek deneme.

Bu matematiksel fikrin yazılım testine taşınması 1985 yılında gerçekleşti. Mandl, derleyici (compiler) testinde yaşanan kombinasyonel patlamayı çözmek için ortogonal dizileri yazılıma uyarladı ve “bu yaklaşımın test kapsamını korurken test senaryosu sayısını dramatik biçimde azalttığını” deneysel olarak gösterdi (Mandl, 1985). Bu çalışma, pairwise testing’in yazılım alanındaki ilk akademik kaydı olarak kabul edilmektedir.

Fikir yerini bulmuştu; ama gerçek ivmeyi kazanması için on yıl daha beklemesi gerekecekti.

Endüstriyel Ölçek: AETG ve 1997

1990'larda AT&T’nin araştırma kolu Bellcore’da bir ekip, pairwise testing’i elle uygulanabilir olmaktan çıkarıp otomatikleştirdi. Cohen, Dalal, Fredman ve Patton (1997), AETG (Automatic Efficient Test Generator) sistemini tanıttıkları çalışmalarında “verilen parametre uzayı için minimum test seti üretmenin NP-zor bir problem olduğunu, ancak greedy algoritmaların pratikte yeterince küçük setler ürettiğini” ortaya koydu (Cohen et al., 1997, s. 440). AETG, yalnızca bir araç tanıtımı değil; aynı zamanda “neden ikili kombinasyonlar yeterli olabilir?” sorusunu sistematik biçimde yanıtlayan ilk kapsamlı çalışmaydı.

Ama asıl 2004 de bilimsel olarak hataların yaklaşık %85'i, en fazla iki parametrenin etkileşiminden kaynaklandigi gösterildiginde bu yöntem kitlesel ölcekte kullanima girdi.

“Yüzde Seksen Beş” Bulgusu: Kuhn (2004)

Pairwise testing’in bugün bir standart olarak kabul görmesinin arkasında ağırlıklı olarak bu makale yatıyor:

Kuhn, D.R., Wallace, D.R., & Gallo, A.M. (2004). Software Fault Interactions and Implications for Software Testing. IEEE Transactions on Software Engineering, 30(12), 418–421.

NASA ve NIH dahil çeşitli kurumların gerçek hata veri tabanlarını inceleyen bu çalışma, temel bir soruya ampirik cevap verdi: Bir yazılım hatası, kaç parametrenin yanlış kombinasyonundan kaynaklanır?

Kuhn ve arkadaşları, inceledikleri sistemlerdeki hataları kombinasyon derinliğine göre sınıflandırdı ve şu tabloyu ortaya çıkardı (Kuhn et al., 2004, s. 419):

Kombinasyon Derinliği Hataların Oranı 1 parametre tek başına ~%35, 2 parametrenin kombinasyonu ~%50, 3 parametrenin kombinasyonu ~%10, 4 ve üzeri parametre ~%5

Yazarlara göre bu bulgular, “test kaynaklarının büyük çoğunluğunun iki faktörlü etkileşimleri kapsayan test setlerine yönlendirilmesinin rasyonel bir strateji olduğunu güçlü biçimde desteklemektedir” (Kuhn et al., 2004, s. 420). Yani gerçek sistemlerdeki hataların yaklaşık %85'i, en fazla iki parametrenin etkileşiminden kaynaklanıyordu.

Bu bulgu pairwise testing’e hem teorik bir zemin hem de pratik bir meşruiyet kazandırdı. İkili kombinasyonları kapsayan bir test seti, tüm kombinasyonların küçük bir fraksiyonunu oluştursa da hataların büyük çoğunluğunu yakalamaya yeterliydi.

Kuhn ve ekibi bu araştırmayı sonraki çalışmalarında genişleterek t-way testing kavramını geliştirdi. Güvenlik kritik sistemlerde 3-way veya 4-way kapsamın daha uygun olabileceğini gösterdiler; ancak “iki faktörlü etkileşim testinin genel yazılım sistemleri için maliyet-etkin bir taban oluşturduğu” sonucunu korudular (Kuhn & Reilly, 2002, s. 3).

Bu araştırmanın pratik uzantısı olarak Microsoft, Czerwonka liderliğinde PICT (Pairwise Independent Combinatorial Testing) adlı ücretsiz aracı geliştirdi. Czerwonka (2006), PICT’in endüstriyel kullanımını aktardığı çalışmasında “gerçek dünya projelerinde pairwise test setlerinin exhaustive testlere kıyasla %90'a varan hacim azaltımı sağladığını, buna karşın hata tespit oranlarının yüksek kaldığını” bildirdi (Czerwonka, 2006, s. 5).

Yazılım Testinde Kullanım Alanları

Pairwise testing, her test senaryosu için her parametre kombinasyonunu denemek yerine tüm ikili kombinasyonları en az bir kez kapsayan minimum test setini oluşturmayı hedefler. ISTQB müfredatı bu tekniği, “tüm girdi parametrelerinin tüm kombinasyonlarını test etmenin pratik olmadığı durumlarda sistematik kapsam sağlamak için kullanılan bir siyah kutu test tasarım tekniği” olarak tanımlar (ISTQB CTFL Syllabus, 2023, s. 47).

Klasik yazılım testinde en çok şu senaryolarda görürüz:

• Tarayıcı/işletim sistemi/cihaz matrisleri: Chrome × Windows × Masaüstü, Safari × macOS × Dizüstü gibi kombinasyonlar pairwise ile yönetilir.
• API parametre testleri: Onlarca giriş parametresi olan REST API’larda tüm kombinasyonlar yerine ikili kapsamla başlanır.
• Konfigürasyon testleri: Farklı veritabanı, sunucu ve uygulama sürümlerinin bir arada çalışma senaryoları.
• Form validasyonu: Çok sayıda alan içeren formda geçerli/geçersiz değerlerin kombinasyonları.

Yapay Zeka Testinde Neden Farklı Bir Yeri Var?

Geleneksel yazılım sistemleri deterministik davranır: aynı girdi, aynı çıktı. Ancak yapay zeka ve makine öğrenmesi sistemleri, model ağırlıkları, hiperparametreler, veri ön işleme adımları, dağıtım ortamı ve çalışma zamanı konfigürasyonlarının karmaşık etkileşimiyle davranış sergiler. Bu durum kombinasyonel test problemini çok daha kritik bir hale getirir.

ISTQB’nin AI Testing (CT-AI) sertifikasyon müfredatı, pairwise testing’i özellikle yapay zeka sistemlerinin konfigürasyon testinde “tercih edilen kombinasyonel teknik” olarak konumlandırır ve “AI sistemlerinin büyük parametre uzaylarının exhaustive kapsam yerine pairwise gibi kombinasyonel yaklaşımlar gerektirdiğini” açıkça ifade eder (ISTQB CT-AI Syllabus, 2021, s. 38).

Kuhn et al.’ın (2004) bulgularının AI bağlamındaki önemi burada belirginleşiyor. Bir güvenlik filtresi tek başına doğru çalışabilir; belirli bir dil modeliyle birlikte kullanıldığında beklenmedik bir boşluk ortaya çıkabilir. Hataların %85'inin ikili kombinasyonlardan kaynaklandığı gerçeği, bu tür etkileşim hatalarının sistematik biçimde yakalanabileceğini göstermektedir.

Somut Örnek: Bir AI Chatbot’u Test Etmek

Bir AI chatbot geliştirdiğimizi düşünelim. Sistem şu parametrelerle konfigüre edilebiliyor:

Parametre Değerler Sayı Dil Modeli LM1, LM2, LM3, LM4, LM5 5 Yanıt Tonu Resmi, Yarı-resmi, Samimi, Teknik 4 Bağlam Penceresi 2K token, 4K token, 8K token 3 Güvenlik Filtresi Temel, Gelişmiş 2

Exhaustive test: 5 × 4 × 3 × 2 = 120 test senaryosu

Pairwise test: yaklaşık ~20 test senaryosu

PICT çıktısı şuna benzer bir tablo üretir:

Bu tabloda herhangi iki parametrenin değer çiftine bakın — “LM3 + Gelişmiş Güvenlik” veya “8K + Teknik Ton” — en az bir satırda karşılaşacaksınız. Czerwonka’nın (2006) aktardığı pratik deneyimle örtüşür biçimde, 120 kombinasyon yerine ~20 ile tüm ikili etkileşimler kapsanmış olmaktadır.

Sonuç: Neden Yeterli Olduğunu Bilmek

Pairwise testing’i sıradan bir kısaltma yöntemi olmaktan çıkaran şey, Kuhn ve arkadaşlarının (2004) ortaya koyduğu ampirik temele dayanmasıdır. “Tüm hataların %85'i en fazla iki parametrenin birleşiminden kaynaklanır” bulgusu, bu tekniğin neden işe yaradığını açıklamaktadır.

Yazarlara göre, “t-way testinin değeri yalnızca test hacmini azaltmaktan ibaret değildir; asıl değer, en yüksek hata riski taşıyan etkileşimlerin öncelikli biçimde kapsanmasını sağlamasındadır” (Kuhn et al., 2004, s. 421). AI sistemlerinin artan konfigürasyon karmaşıklığı göz önünde bulundurulduğunda, bu yaklaşım artık isteğe bağlı bir teknik olmaktan çıkmış; sistematik bir zorunluluk haline gelmiştir.

Makaleyi yazarken bir de tarayıcıda çalışan, kurulum gerektirmeyen pairwise hesaplayıcı geliştirdim. Parametrelerinizi girip tek tıkla minimum test setini üretebilir, sonucu CSV olarak indirebilirsiniz. **→ Hesaplayıcıyı deneyin.**

Kaynaklar

Bose, R.C., & Bush, K.A. (1952). Orthogonal arrays of strength two and three. Annals of Mathematical Statistics, 23(4), 508–524.

Cohen, D.M., Dalal, S.R., Fredman, M.L., & Patton, G.C. (1997). The AETG system: An approach to testing based on combinatorial design. IEEE Transactions on Software Engineering, 23(7), 437–444. https://doi.org/10.1109/32.605761

Czerwonka, J. (2006). Pairwise testing in the real world: Practical extensions to test-case scenarios. Proceedings of the 24th Pacific Northwest Software Quality Conference, 1–8.

Kuhn, D.R., & Reilly, M.J. (2002). An investigation of the applicability of design of experiments to software testing. Proceedings of the 27th Annual NASA Goddard Software Engineering Workshop, 91–95.

Kuhn, D.R., Wallace, D.R., & Gallo, A.M. (2004). Software fault interactions and implications for software testing. IEEE Transactions on Software Engineering, 30(12), 418–421. https://doi.org/10.1109/TSE.2004.24

Mandl, R. (1985). Orthogonal Latin squares: An application of experiment design to compiler testing. Communications of the ACM, 28(10), 1054–1058. https://doi.org/10.1145/4372.4375

ISTQB. (2021). Certified Tester AI Testing (CT-AI) syllabus v1.0. International Software Testing Qualifications Board.

ISTQB. (2023). Certified Tester Foundation Level (CTFL) syllabus v4.0. International Software Testing Qualifications Board.