Kazanimlar:
- Satır, dal ve koşul kapsamı gibi metrikleri bir güven değil harita olarak okuyup yüksek kapsamın sahte-güven verebileceğini kavrayabilme
- Kod kapsamının yanına gereksinim kapsamını koyup yapay zeka ile izlenebilirlik boşluklarını görünür kılabilme
- Risk = olasılık × etki formülüyle özellikleri puanlayıp sınırlı test emeğini en yüksek riske yönlendirebilme ve bilinçli kapsam dışını belgeleyebilme
Her yazılımı sonsuza kadar test edemezsiniz; zaman ve kaynak sınırlıdır. O hâlde asıl soru şudur: sınırlı test emeğini nereye harcamalı? İki kavram bu soruya cevap verir. Test kapsamı (test coverage — kodun veya gereksinimlerin ne kadarının testlerce dokunulduğunu ölçen metrik) neyin test edildiğini gösterir. Risk bazlı test (risk-based testing — test önceliğini, bir alanın bozulma olasılığı ve bozulunca yol açacağı zarara göre belirleme yaklaşımı) ise emeği en çok riske yönlendirir. Yapay zeka (YZ), her ikisinde de güçlü bir analiz ortağıdır: kapsam boşluklarını görünür kılar, riskli alanları önerir. Ama merkez uyarı geçerli: YZ'nin gördüğü kapsam sayısı yanıltıcı olabilir; %100 satır kapsamı bile hiçbir şeyi doğrulamayan testlerle elde edilebilir. Sizin işiniz, kapsamı bir güven değil, bir harita olarak okumaktır.
Kapsam metriklerini doğru okumak
Kapsamın birkaç türü vardır ve hepsi eşit anlamlı değildir:
- Satır kapsamı (line coverage): Kaç kod satırı en az bir kez çalıştırıldı. En yaygın ama en zayıf ölçüt; bir satırın çalışması, doğru davrandığının kanıtı değildir.
- Dal kapsamı (branch coverage): Her if dalının (hem doğru hem yanlış) test edilip edilmediği. Satırdan daha anlamlı.
- Koşul kapsamı (condition coverage): Karmaşık koşullardaki her alt-koşulun ayrı ayrı test edilmesi.
- Yol kapsamı (path coverage): Kod içindeki mantıksal yolların kombinasyonları. En kapsamlı ama pratikte tam ulaşmak zor.
Dikkat: Kapsam yüzdesi bir "kalite puanı" değildir. %100 satır kapsamı, satırların çalıştığını söyler; doğru sonuç ürettiğini değil (1. ünitedeki sahte-geçiş). Kapsamı "nereye hiç bakmadım" sorusunun cevabı olarak kullanın, "her şey test edildi" güvencesi olarak değil.
Kapsamın kör noktaları
Kapsam metrikleri yalnızca kodun ne kadarının çalıştırıldığını ölçer; şunları göremez: (1) test edilmeyen gereksinimler (kod var ama iş kuralı yanlış), (2) eksik kod (hiç yazılmamış bir kontrol için kapsam da olmaz), (3) veri/durum kombinasyonları, (4) kullanılabilirlik, performans, güvenlik. Bu yüzden kod kapsamının yanına gereksinim kapsamı (her kabul kriterinin en az bir testle karşılanması) koyulmalıdır. YZ, gereksinim-test eşlemesini (izlenebilirlik matrisi) üretmekte çok yardımcıdır.
Risk bazlı test: emeği nereye koyarız?
Risk = olasılık (bozulma ihtimali) × etki (bozulursa zarar). YZ ile bir özellik listesini bu iki eksende puanlayıp bir ısı haritası çıkarabilirsiniz. Yüksek olasılık × yüksek etki alanlar (ödeme, kimlik doğrulama, veri bütünlüğü) en yoğun testi hak eder; düşük × düşük alanlar (nadir kullanılan bir tercih ekranı) hafif test yeterlidir.
Alan
Olasılık
Etki
Risk
Test yoğunluğu
Ödeme akışı
Orta
Çok yüksek
Yüksek
Derin + otomasyon
Kimlik doğrulama
Orta
Çok yüksek
Yüksek
Derin + güvenlik
Ürün arama
Yüksek
Orta
Orta-Yüksek
Otomasyon + keşif
Profil fotoğrafı
Düşük
Düşük
Düşük
Hafif kontrol
Yardım sayfası
Düşük
Çok düşük
Çok düşük
Gözden geçirme
Kapsamın peşinde koşmanın tuzağı
Kapsam yüzdesini bir hedef hâline getirmek (örneğin "ekip %90 kapsamı geçmeli" kuralı) tehlikeli bir yan etki doğurur: geliştiriciler ve testçiler, gerçek riski karşılamak yerine yüzdeyi yükseltmeye odaklanır. Sonuç, çoğu zaman assert'siz veya önemsiz testlerle şişirilmiş bir kapsamdır — sayı güzel görünür ama koruma yoktur. Bu, ölçütün kendisi hedefe dönüşünce bozulması olgusudur: "bir ölçü hedef hâline gelince, iyi bir ölçü olmaktan çıkar." Kapsamı bir teşhis aracı olarak kullanın, bir performans karnesi olarak değil.
Daha sağlıklı bir yaklaşım, kapsamı yönlü okumaktır: "Kritik ödeme modülünde dal kapsamı neden %40'ta kalmış?" sorusu, "genel kapsam %90 mı?" sorusundan çok daha değerlidir. YZ'ye kapsam raporunu modül ve risk düzeyine göre böldürün; düşük kapsamlı yüksek riskli alanları öne çıkarın. Böylece kapsam, kör bir yüzde olmaktan çıkıp emeği yönlendiren bir pusulaya dönüşür.
Dikkat: "%100 kapsam" sloganı bir tuzaktır. Bazı kodları (basit erişimciler, otomatik üretilen kısımlar) test etmek düşük değerlidir; oraya harcanan emek, yüksek riskli iş kurallarından çalınır. Hedef, her satırı değil, her önemli davranışı ve riski test etmektir.
Zayıf prompt / Güçlü prompt
Zayıf: "Test kapsamımı artır."
Güçlü: "Şu kabul kriteri listesi ve şu mevcut test vakaları verildi. (1) Hangi kabul kriterinin hiç testle karşılanmadığını (gereksinim kapsam boşluğu) tablo hâlinde çıkar. (2) Her özelliği olasılık ve etki eksenlerinde 1-5 puanla; risk = olasılık×etki'ye göre sırala. (3) Sınırlı zamanım için, en yüksek riskten başlayarak hangi 5 boşluğu önce kapatmam gerektiğini gerekçesiyle öner. Kod satır kapsamını tek başına ölçüt alma; iş riskini önceliklendir. Kriterler: [...] Testler: [...]"
Güçlü prompt; kapsamı iş riskiyle birleştirir ve sınırlı emeği önceliklendirir.
Dört kopyalanabilir şablon
1) Gereksinim kapsam boşluğu:
Şu kabul kriterleri ve şu test vakaları verildi.Bir izlenebilirlik tablosu üret: her kriter -> onu karşılayantest(ler). Hiç testi olmayan kriterleri "KAPSAM BOŞLUĞU",hiçbir kritere bağlanmayan testleri "GEREKSİZ?" diye işaretle.Kriterler: [...] / Testler: [...]
2) Risk puanlama:
Şu özellik/modül listesini olasılık (bozulma ihtimali) veetki (bozulursa zarar) eksenlerinde 1-5 puanla.Risk = olasılık × etki. Tablo halinde sırala ve her yüksekriskli alan için önerilen test türünü (birim/API/UI/keşif/güvenlik)belirt. Liste: [...]
3) Kapsam yorumlama:
Şu kapsam raporu verildi (satır %, dal %). Bana şunu söyle:- Bu sayılar neyi KANITLAMAZ?- Yüksek satır kapsamına rağmen risk taşıyabilecek alanlar neler?- Kapsamın göremediği (gereksinim, veri kombinasyonu, güvenlik) boşluklar için hangi ek testleri önerirsin?Rapor: [yapıştır]
4) Sınırlı zaman planı:
Yayına [X saat] kaldı. Şu risk sıralaması ve kapsam boşluklarıverildi. Bu sürede maksimum risk azaltacak test planını önceliksırasıyla çıkar. Nelerin bilinçli olarak test EDİLMEYECEĞİNİve bunun kabul edilen riskini açıkça yaz.Veriler: [...]
Üç mini vaka
Vaka 1 — %100 kapsam, sıfır güven. Bir ekip %94 satır kapsamıyla gurur duyuyordu. "Kapsam yorumlama" analizi, testlerin çoğunun assert'siz olduğunu, yani satırları çalıştırıp hiçbir şey doğrulamadığını gösterdi. Gerçek koruyucu kapsam çok daha düşüktü. Ekip sayıya değil, mutasyon testine (10. ünite) yöneldi; gerçek hata yakalama oranı iki katına çıktı.
Vaka 2 — Risk haritası önceliği düzeltti. Bir ekip test emeğinin %40'ını nadir kullanılan bir raporlama ekranına harcıyor, ödeme akışını "nasılsa çalışıyor" diye hafif geçiyordu. YZ risk puanlaması bu dengesizliği gösterdi. Emek yeniden dağıtıldı; iki hafta sonra ödeme akışında yüksek etkili bir hata bulundu ve canlı öncesi kapatıldı.
Vaka 3 — Bilinçli kapsam dışı. Bir sürüme 4 saat kala ekip, "sınırlı zaman planı" şablonuyla neyi test edip neyi bilinçli atlayacağına karar verdi. Yüksek riskli iki akış derin test edildi; düşük riskli bir tercih ekranı "kabul edilen risk" olarak belgelenip atlandı. Karar şeffaf ve gerekçeliydi; sürüm güvenle çıktı.
Sık yapılan hatalar
- Kapsam yüzdesini kalite sanmak. Yüksek satır kapsamını "test edildi" güvencesi olarak okumak.
- Sadece kod kapsamına bakmak. Gereksinim kapsamını (her kabul kriterinin test edilmesi) atlamak.
- Riski hesaba katmadan eşit test etmek. Emeği düşük riskli alanlara dağıtıp kritik akışları ihmal etmek.
- Kapsam dışını gizlemek. Zaman yetmediğinde neyin test edilmediğini belgelememek; sürüm sonrası sürprizler.
- YZ'nin risk puanını sorgusuz kabul etmek. Ürün bağlamını YZ tam bilmez; puanları uzman gözüyle ayarlayın.
Özetle
Test kapsamı ve risk bazlı test, sınırlı emeği en doğru yere yönlendirmenin iki aracıdır. Kapsam metrikleri (satır, dal, koşul, yol) neyin dokunulduğunu gösterir ama doğru davrandığını kanıtlamaz; kapsam bir harita, güven değildir. Kod kapsamının yanına gereksinim kapsamı koyun. Risk = olasılık × etki formülüyle özellikleri puanlayıp emeği en çok riske yöneltin. YZ boşlukları görünür kılar, riski puanlar, sınırlı zamanı planlar; ama nihai öncelik ve "bilinçli kapsam dışı" kararı, iş bağlamını bilen uzmanındır.
Uygulama görevi
Kendi projenizden bir modül seçin. YZ ile "gereksinim kapsam boşluğu" şablonunu çalıştırıp hangi kabul kriterlerinin test edilmediğini bulun. Sonra "risk puanlama" ile modülün alt özelliklerini olasılık×etki eksenlerinde sıralayın. Elinizdeki (varsayımsal) 3 saatlik test süresini "sınırlı zaman planı" ile dağıtın; neyi bilinçli olarak test etmeyeceğinizi ve kabul edilen riski yazın. Bulduğunuz en yüksek riskli kapsam boşluğunu kapatacak somut bir test ekleyin.
Kontrol listesi
- [ ] Kapsam yüzdesini kalite değil, harita olarak okudum.
- [ ] Kod kapsamının yanına gereksinim kapsamını da çıkardım.
- [ ] Özellikleri olasılık × etki ile puanlayıp riske göre sıraladım.
- [ ] Test emeğini en yüksek riske yönlendirdim.
- [ ] Bilinçli test edilmeyen alanları ve kabul edilen riski belgeledim.
- [ ] YZ'nin risk puanlarını ürün bağlamıma göre gözden geçirdim.