Kazanimlar:
- Yapay zekanın QA sürecinin neresinde gerçek zaman kazandırdığını, neresinde 'yayına hazır mı' gibi kalite kararlarının insana kaldığını görev risk düzeyine göre ayırt edebilme
- Sahte-geçiş (false pass) riskini tanıyıp her yapay zeka testini kodu kasten bozarak sınayan bir doğrulama disiplini uygulayabilme
- Test verisini, kişisel veriyi ve anahtarları koruma ile güvenlik testini yalnızca yetki dâhilinde ve savunma amaçlı yapma alışkanlığını edinebilme
Bir sürüm gecesi düşünün. Yüzlerce test çalıştı, hepsi yeşil yandı, ekip rahatladı ve yazılım canlıya çıktı. Ertesi sabah müşteri ödeme ekranının çöktüğünü bildirdi. Testler yeşildi ama hatayı görmemişti. İşte kalite güvence (QA — quality assurance, yani yazılımın istenen kalitede olduğunu sistematik biçimde güvence altına alan disiplin) mesleğinin en sinsi kâbusu budur: yeşil yanan ama aslında hiçbir şeyi doğrulamayan test. Yapay zeka (YZ — geçmiş veriden örüntü çıkarıp metin ve kod üreten yazılım) bu mesleğe girdiğinde hem büyük bir hızlanma hem de tam olarak bu kâbusun büyümüş bir hâli gelir. Bu modülün en baştaki sözü nettir: YZ bir test asistanı, taslak üreticisi ve fikir çoğaltıcısıdır; "bu yazılım yayına hazır mı" kararını imzalayan test uzmanı sizsiniz.
Bu ilk ünitede araca değil, disipline odaklanacağız. YZ'nin QA sürecinin neresinde gerçek zaman kazandırdığını, nerede tehlikeli olduğunu, "sahte-geçiş" (false pass) denen aldatıcı yeşilin neden en büyük risk olduğunu, her çıktıyı nasıl doğrulayacağınızı ve hangi veriyi hangi araca verebileceğinizi öğreneceksiniz. Bu temeli atmadan sonraki üniteler havada kalır.
YZ, test sürecinin neresinde işe yarar?
Test işlerini iki büyük kümeye ayıralım. Birinci küme: tekrarlayan, üretilebilir, taslak işler. Bir gereksinimden test senaryosu taslağı çıkarmak, sınır değerlerini listelemek, bir ekran için otomasyon kodu iskeleti yazmak, karışık bir hata durumunu düzgün bir hata raporuna çevirmek, yüzlerce satırlık log dosyasını özetlemek, bir API yanıtından şema (schema — verinin yapısını tanımlayan sözleşme) çıkarmak. Bu işlerde YZ dakikaları saniyeye indirir ve yorulmaz.
İkinci küme: sonucu kalite, güven ve sorumluluk olan kararlar. "Bu sürüm yayına çıkabilir mi", "bu hata kritik mi yoksa ertelenebilir mi", "bu test kapsamı yeterli mi", "bu senaryo gerçek kullanıcı riskini yakalıyor mu" gibi kararlar bağlam, ürün bilgisi ve sorumluluk ister. YZ burada seçenek üretir, taslak hazırlar — ama "geçti/kaldı" ve "çıkabilir/çıkamaz" kararını siz verirsiniz.
Ayrımı bir cümleyle netleştirelim: YZ "hangi durumlar test edilebilir ve bunu test eden kod nasıl yazılır" sorusunda güçlüdür; "bu yazılım gerçekten çalışıyor mu ve buna kim kefil" sorusunda karar sizindir.
İpucu: Bir işi YZ'ye vermeden önce sorun: "Bu çıktı yanlış olur ve ben fark etmezsem ne olur?" Cevap "birkaç dakika kaybederim" ise rahatça devredin. Cevap "hatalı yazılım canlıya çıkar" ise YZ taslak üretsin, kararı ve doğrulamayı siz yapın.
Sahte-geçiş (false pass): QA'da YZ'nin bir numaralı riski
Bir testin yeşil yanması iki şey anlamına gelebilir: ya yazılım gerçekten doğru çalışıyordur ya da test yanlış yazıldığı için hatayı görmüyordur. İkincisine sahte-geçiş (false pass) denir — test "geçti" der ama aslında hiçbir şeyi doğrulamamıştır. YZ ile üretilen testlerde bu risk ciddi biçimde artar, çünkü YZ akıcı, düzgün görünen ama içi boş testler yazmakta çok başarılıdır.
En sık üç sahte-geçiş biçimi şudur: (1) Doğrulaması olmayan test — kod çalışır, hiçbir assert (doğrulama ifadesi, yani "sonuç şu olmalı" kontrolü) içermez, hep geçer. (2) Kendi kendini doğrulayan test — testin beklenen değeri, test edilen kodun çıktısından hesaplanır; yani kod ne üretirse test onu "doğru" kabul eder. (3) Yanlış şeyi doğrulayan test — assert vardır ama önemsiz bir şeyi kontrol eder (örneğin "yanıt boş değil"), asıl iş kuralını değil.
Dikkat: Yeşil bir test paneli, kalitenin kanıtı değildir; olsa olsa "yazdığımız kontroller şu an kırılmıyor" der. YZ ürettiği testte "geçti" görmek sizi rahatlatmasın — asıl soru şudur: bu test, kodu bilerek bozsam kırmızıya döner mi? Dönmüyorsa o test bir dekordur.
Bu modül boyunca tekrar eden altın kural: her YZ testini, kodu kasten bozarak sınayın. Test hâlâ yeşilse, o test işe yaramıyordur. (Bu fikri 10. ünitede mutasyon testi olarak derinleştireceğiz.)
Doğrulama disiplini: üç adım
YZ kendinden emin konuşur; bu doğru olduğu anlamına gelmez. Her çıktıya uygulanacak üç adımlık bir refleks geliştirin:
- Gereksinime bağla. YZ'nin ürettiği her test senaryosu ve assert, gerçek bir gereksinime veya kabul kriterine (acceptance criteria — bir işin "bitti" sayılması için karşılaması gereken koşullar) dayanmalı. "Bu senaryo hangi kuralı doğruluyor?" diye sorun.
- Kırmızıyı gör. Üretilen testi bir kez de kodu bozarak çalıştırın. Kırmızıya dönmüyorsa test geçersizdir. Bu, YZ testlerinde pazarlık edilemez adımdır.
- Bağlam süzgecinden geçir. Çıktı, sizin bildiğiniz ürün davranışına, mimariye, gerçek kullanıcı akışına uyuyor mu? Alan bilginiz son filtredir.
Veri gizliliği ve güvenlik: ne, nereye girer?
Test ortamında çalıştığınız veriler çoğu zaman hassastır: gerçek müşteri kayıtları, üretim veritabanı kopyaları, API anahtarları, iç sistem adresleri, henüz duyurulmamış özellikler. Basit bir sınıflama yapın: Açık veri (belgelenmiş, herkese açık) her araca girebilir. İç veri (kaynak kod parçaları, iç dokümanlar) yalnızca kurum onaylı araçlara. Gizli veri (gerçek müşteri verisi, kimlik bilgileri, güvenlik açığı detayları, anahtarlar) sadece kurumun sözleşmeli, verisi model eğitimine gitmeyen araçlarına, tercihen maskelenerek girer.
Güvenlik testi bağlamında ek bir sınır vardır: bu modülde öğrenilen her şey savunma amaçlıdır — kendi ürününüzün güvenliğini yetki dâhilinde sınamak için. YZ'yi başkasının sistemine izinsiz sızmak, gerçek açıkları silah hâline getirmek veya yetkiniz olmayan bir sisteme test yapmak için kullanmak hem etik dışıdır hem suçtur. Yetki belgesi (kapsam ve izin) olmadan hiçbir saldırgan test yapılmaz.
İpucu: Gerçek müşteri verisi yerine sentetik (yapay üretilmiş) test verisi kullanın. YZ'den "gerçekçi ama tamamen kurgusal test verisi üret" istemek, hem gizliliği korur hem de kenar durumları çeşitlendirir.
Üç mini vaka
Vaka 1 — Zaman kazancı doğru yerde. Bir ekomerce ekibinin test uzmanı, her sürümde 30 sayfalık gereksinim dokümanından elle test senaryosu çıkarıp 6 saat harcıyordu. Dokümanı (ticari sır içermeyen kısmını) YZ'ye verip yapılandırılmış senaryo taslağı istedi; süre 90 dakikaya indi. Kazanılan zamanı, YZ'nin atladığı iş-kuralı kenar durumlarını kendisi ekleyerek doğrulamaya ayırdı. YZ tekrarlayan işi aldı, yargı insanda kaldı.
Vaka 2 — Sahte-geçiş yakalandı. Bir geliştirici, YZ'ye bir hesaplama fonksiyonu için 12 birim test yazdırdı; hepsi yeşildi. Test uzmanı "kırmızıyı gör" adımını uyguladı: fonksiyonun içindeki toplama işaretini kasten çarpmaya çevirdi. 12 testten yalnızca 3'ü kırmızıya döndü. Diğer 9 test hiçbir gerçek doğrulama yapmıyordu; sadece "hata fırlatmadı" diye geçiyordu. 9 dekor test silindi, yerine 5 gerçek test yazıldı.
Vaka 3 — Gizlilik ihlalinden dönüş. Bir stajyer, üretim veritabanından aldığı gerçek müşteri e-postaları ve kart son dört hanesini içeren bir hata logunu, halka açık bir araca yapıştırıp "bu hatayı açıkla" dedi. QA lideri müdahale etti: bu, kişisel verinin kontrol dışına çıkmasıydı ve KVKK (Kişisel Verilerin Korunması Kanunu) ihlaliydi. Aynı iş, kişisel alanlar maskelenip yalnızca hata izi (stack trace) bırakılarak kurum onaylı araçta yapıldı.
Dört kopyalanabilir şablon
1) İş uygunluğu değerlendirme:
Rolün: kıdemli QA lideri.Sana bir test işi tarif edeceğim. Bana (1) bu işin YZ'yegüvenle devredilebilir taslak/analiz işi mi yoksa insanınkarar vermesi gereken bir kalite kararı mı olduğunu,(2) yanlış çıktının olası maliyetini,(3) devretmeden önce yapmam gereken doğrulamayı söyle.İş: [işi buraya yaz]
2) Sahte-geçiş denetimi:
Aşağıdaki testi incele. Bana şunu söyle:- Bu test hangi davranışı doğruluyor? (tek cümle)- Test edilen kodu nasıl bozarsam bu test KIRMIZIYA döner?- Bu testin hep geçmesine yol açabilecek bir zayıflık var mı (eksik assert, kendini doğrulama, önemsiz kontrol)?Test: [testi buraya yapıştır]
3) Test verisi maskeleme kontrolü:
Sana vereceğim log/veride kişisel veya gizli alan(e-posta, ad, kart, anahtar, iç adres) olabilir.Önce maskelenmesi gereken alanları listele; ben maskeleyipyeniden göndereceğim. Bu haliyle analiz yapma.
4) Sentetik test verisi üretimi:
[Şu alan yapısı] için 20 satır tamamen kurgusal, gerçekçitest verisi üret. Gerçek kişi/kurum verisi kullanma.Kenar durumları da ekle: boş alan, çok uzun metin,sınır değerler, geçersiz format.
Zayıf prompt / Güçlü prompt
Zayıf: "Bu koda test yaz."
Güçlü: "Bu hesaplaIndirim fonksiyonu için birim testleri yaz. Fonksiyonun kabul kriteri: 1000 TL üzeri %10, 5000 TL üzeri %20 indirim; negatif tutar hata fırlatmalı. Her test için hangi kuralı doğruladığını yorum satırıyla belirt. Sınır değerleri (999, 1000, 1001, 5000, 0, -1) ayrı ayrı test et. Kodu bozarsam kırmızıya dönecek gerçek assert'ler kullan; boş veya önemsiz assert yazma."
Güçlü prompt; kabul kriterini, sınır değerleri, doğrulama beklentisini ve sahte-geçişe karşı açık talimatı verir. Zayıf prompt ise YZ'yi dekor test yazmaya davet eder.
Sık yapılan hatalar
- Yeşile güvenmek. Testin geçmesini kanıt sanmak. Asıl soru: kodu bozunca kırmızıya dönüyor mu?
- Gereksinim vermeden test istemek. YZ, ne doğrulanması gerektiğini bilmeden ancak genel-geçer, çoğu zaman işe yaramaz testler üretir.
- Doğrulamayı atlamak. "YZ yazdı, herhâlde doğrudur" demek. Sorumluluk çıktıyı kullanan kişidedir.
- Gerçek/hassas veriyi araca yapıştırmak. Üretim verisi, anahtar veya kişisel veriyle çalışmak.
- Yetkisiz güvenlik testi. Kapsam ve izin belgesi olmadan saldırgan test denemek.
- YZ'yi kararı devretmek için kullanmak. "Bu sürüm çıkabilir mi" sorusunu YZ'ye sordurup cevabı imza yerine koymak.
Özetle
YZ, QA sürecinde tekrarlayan ve taslak üretilebilir işleri hızlandıran güçlü bir asistandır; ama kalite kararının sorumluluğu insandadır. Bu meslekte YZ'nin bir numaralı riski sahte-geçiştir: düzgün görünen ama hiçbir şeyi doğrulamayan yeşil testler. Her YZ testini kodu kasten bozarak sınayın; kırmızıya dönmüyorsa o test bir dekordur. Gereksinime bağlayın, kırmızıyı görün, bağlam süzgecinden geçirin. Gizli veriyi maskeleyin, güvenlik testini yalnızca yetki dâhilinde ve savunma amaçlı yapın.
Uygulama görevi
Kendi projenizden YZ ile üretilmiş (veya YZ'ye ürettireceğiniz) 5 birim testi alın. Her biri için: (1) hangi davranışı doğruladığını tek cümleyle yazın, (2) test edilen kodu kasten bozup çalıştırın ve kaçının kırmızıya döndüğünü not edin, (3) kırmızıya dönmeyenleri "dekor test" olarak işaretleyip gerçek assert ile yeniden yazın. Sonucu bir tabloya dökün: test adı / doğruladığı kural / bozunca kırıldı mı / aksiyon.
Kontrol listesi
- [ ] İşi devretmeden önce "yanlış olursa ne kaybederim" sorusunu sordum.
- [ ] Her YZ testini kodu bozarak sınadım; kırmızıya dönmeyeni gerçek test ile değiştirdim.
- [ ] Test senaryolarını gerçek gereksinime/kabul kriterine bağladım.
- [ ] Hassas/gerçek veriyi araca vermeden maskeledim; mümkünse sentetik veri kullandım.
- [ ] Güvenlik testini yalnızca yetki dâhilinde ve savunma amaçlı düşündüm.
- [ ] "Sürüm çıkabilir mi" kararını YZ'ye değil, kendime bıraktım.