Testi kim test edecek

AI Çağında Kalite Mimarisi (Bölüm 3): Test Kodunu Yapay Zeka Yazıyorsa, Testi Kim Test Edecek?

Hasbihal #1: AI Çağında Kalite Mimarisi: SDET’ in Evrimi

Bölüm 3: Test Kodunu Yapay Zeka Yazıyorsa, Testi Kim Test Edecek?

Yazılım geliştirme ekiplerinde son aylarda hızla yayılan tehlikeli bir rehavet var: “Fonksiyonu Copilot’a yazdırdım, hemen altına birim testlerini (unit test) ve API test senaryolarını da ürettirdim. Kod kapsama oranımız (code coverage) yüzde 90’a çıktı, demek ki güvendeyiz!”

Peki gerçekten güvende miyiz?

17 yıllık mühendislik ve kalite liderliği tecrübemle açıkça ifade edeyim: Kod kapsama oranının yüksek olması, o testlerin sistemdeki gerçek hataları yakalayabileceği anlamına gelmez. Hele ki o test kodunu bir yapay zekaya yazdırmışsanız, büyük bir “sahte güvenlik illüzyonu” içinde olabilirsiniz.

Romalı şair Juvenal’in ünlü sorusu bugün modern yazılım mimarisinin tam kalbine yerleşmiş durumda: “Quis custodiet ipsos custodes?” Yani; “Muhafızları kim denetleyecek?”

Yapay zekanın ürettiği test kodunu kim test edecek?


Büyük Yanılgı: Yeşil Yanan Testler Neden Aldatıcıdır?

Büyük Dil Modelleri (LLM) bir koda test yazarken temelde şu iki yapısal körlüğe düşer:

  1. Doğrulama Yanılsaması (Confirmation Bias): Model, fonksiyonu üretirken yaptığı mantıksal bir hatayı veya eksik kabulü, o fonksiyona test yazarken de “doğru mantık” olarak varsayar. Yani kendi hatasını kendi yazdığı assertion ile meşrulaştırır.
  2. Tautological Tests (Totolojik / Boş Testler): Yapay zeka tarafından üretilen birçok test senaryosu, sistemin gerçek iş mantığını doğrulamak yerine sadece kodun çökmeden çalıştığını veya fonksiyonun döndüğü rastgele bir değeri doğrular. Test her zaman yeşil yanar (pass eder), ancak üretim ortamındaki ölümcül bir mantık hatasını yakalama gücü sıfırdır.

Peki bu döngüyü nasıl kıracağız? AI tarafından üretilen testlerin kalitesini ve doğruluğunu matematiksel olarak nasıl denetleyeceğiz?

İşte bu noktada modern test mühendisliğinin iki ileri düzey silahı devreye giriyor: Mutasyon Testi (Mutation Testing) ve Metamorfik Testler (Metamorphic Testing).


1. Mutasyon Testi: Testinizi “Yapay Hatalarla” Sınayın

Geleneksel test yaklaşımında hedef, test senaryolarıyla koddaki hataları bulmaktır. Mutasyon testinde ise denklem tersine döner: Kaynak kodun içine bilerek ve isteyerek küçük yapay hatalar (mutantlar) enjekte edilir ve şu soru sorulur:

“Yapay zekanın yazdığı test süiti bu hatayı fark edip kırmızıya dönecek mi, yoksa uyumaya devam mı edecek?”

Nasıl Çalışır? • Kaynak koddaki bir büyüktür işareti (>) küçüktür (<) ile değiştirilir. • Mantıksal bir ‘AND’ operatörü ‘OR’ yapılır. • Bir döngü sayacı veya sınır değeri 0 yerine 1 yapılır.

Eğer test süiti bu değişikliği yakalayıp patlarsa, mutant “öldürülmüş” (killed) olur; yani testiniz güçlüdür. Ancak kod değiştiği halde yapay zekanın yazdığı test hala yeşil yanmaya devam ediyorsa, mutant “hayatta kalmıştır” (survived).

Bu durum, AI tarafından yazılan o testin aslında hiçbir şeyi gerçek anlamda doğrulamadığının matematiksel kanıtıdır. Modern bir CI/CD boru hattında kod kapsamına (line coverage) değil, “Mutasyon Skoruna” (Mutation Score) bakılmalıdır.


2. Metamorfik Testler: Doğru Cevabı Bilmediğimizde Sistemi Nasıl Test Ederiz?

Yapay zekanın kendisini veya karmaşık makine öğrenmesi algoritmalarını test ederken karşımıza “Test Oracle Problemi” çıkar. Yani sistemin üretmesi gereken mutlak doğru sonucun ne olduğunu önceden bilemeyiz.

Örneğin, bir e-ticaret öneri motorunu, büyük bir arama algoritmasını veya otonom sürüş karar mekanizmasını test ederken tek tek assertion yazamazsınız.

Metamorfik test bu düğümü şu ilkeyle çözer: Tek bir çıktının mutlak değerine odaklanmak yerine, iki farklı girdinin çıktıları arasındaki mantıksal ilişkiyi (Metamorphic Relation) test edin.

Basit Bir Örnek: Bir navigasyon yazılımını test ettiğinizi düşünün. A noktasından B noktasına en kısa yolu hesaplattınız ve sistem “12 kilometre” dedi. Doğru cevabın gerçekten 12 km olup olmadığını elinizle hesaplayamazsınız (Oracle yoktur).

Ancak şu metamorfik kuralı koyabilirsiniz: “Eğer yol ağına fazladan yeni ara sokaklar eklersem, yeni rota kesinlikle 12 kilometreden daha uzun olamaz.” Eğer sistem yeni sokaklar eklendiğinde en kısa yola 15 km derse, algoritmanın hatalı olduğunu kesin olarak kanıtlarsınız.

Yapay zekanın ürettiği arama, öneri ve karar destek sistemlerini test ederken geleceğin kalite mimarlarının en büyük kozu bu metamorfik ilişkileri kurgulamaktır.


Test Mühendisinin Yeni Rolü: “Kalite Güvencesinden Güvenilirlik Mimarisine”

Yapay zeka araçları birim test kodunu saniyeler içinde yazabilir. Bu bir tehdit değil, test mühendisleri için tarihin en büyük özgürleşme fırsatıdır.

Çünkü artık saatlerce oturup basit getter/setter fonksiyonlarına test script’i yazmak zorunda değiliz.

Geleceğin SDET ve Test Mühendisliği rolü şu 3 kritik sorumluluğa evriliyor:

  1. Sentetik Hata Mimarisi: Mutasyon testi araçlarını (PITest, Stryker, Mutmut) CI/CD süreçlerine entegre edip AI tarafından yazılan testlerin çürüklüğünü denetlemek.
  2. Metamorfik Kuralları Tasarlamak: Sistemin iş mantığını ve alan bilgisini (domain knowledge) girdi-çıktı ilişkilerine dönüştürmek.
  3. Güvenlik Kapılarını Beklemek: Yeşil yanan testlerin sahte konforuna kapılmadan, sistemin uç durumlardaki dayanıklılığını garanti altına almak.

Özetle: Bırakın test kodunun ilk taslağını yapay zeka yazsın. Ancak o testin sistemi koruyup koruyamayacağını denetleyecek mimari zeka, her zaman yetkin bir test mühendisinin zihninde olacaktır.


Yazılım test mühendisliği süreçlerinde ileri düzey doğrulama stratejileri, otomasyon mimarileri ve liderlik pratiklerini ele aldığım 320 sayfalık “Yazılım Test Mühendisliği” kitabımda bu konuların metodolojik detaylarını bulabilirsiniz.

Yorum bırakın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir