Test Kapsamı (Test Coverage) Nedir?

Yazılım projelerinde test süreçlerinin kalitesini ölçmek istediğimizde yönetim masalarından sıklıkla şu soru yükselir: "Sistemi ne kadar test ettiniz?" Bu soruya "Her yere baktık, çok test ettik" gibi soyut cevaplar vermek yerine, elimizdeki matematiksel ve mantıksal metrikleri sunmamız gerekir. İşte bu noktada devreye Yapısal Test Kapsamı (Code Coverage) girer.

ISTQB ekosisteminde beyaz kutu (white-box) test tekniği olarak konumlanan kod kapsamı, yazdığımız testlerin kaynak kodun ne kadarını fiziksel olarak çalıştırdığını ölçen metrik tabanlı bir yaklaşımdır. Ancak unutulmaması gereken en önemli kural şudur: Kod kapsamı sadece peşinden koşulacak hedef yüzde değerinden ibaret değildir; koddaki mantıksal açık kapıları bulmamızı sağlayan bir pusuladır.

ISTQB müfredatının ve teknik mülakatların kalbini oluşturan üç temel kod kapsamı türünü ve aralarındaki güç dengesini inceleyelim.

ISTQB Standartlarında 3 Temel Kod Kapsamı

Koddaki mantıksal derinliğe göre kapsamı oranını ölçmenin üç farklı yolu vardır:

1. Komut Kapsamı (Statement Coverage)

Yazdığımız testlerin, koddaki çalıştırılabilir (executable) satırların yüzde kaçına en az bir kez çalıştırıldığını ölçer. En temel ve yüzeydeki kapsam türüdür.

2. Karar kapsamı (Decision / Branch Coverage)

Koddaki mantıksal kararların (örneğin if-else bloklarının veya switch-case yapılarının) hem Doğru (True) hem de Yanlış (False) yönlerinin test edilip edilmediğini ölçer. ISTQB standartlarına göre Karar Kapsamı, Komut Kapsamına göre çok daha güçlüdür. Bir kodun tüm satırlarını çalıştırmış olmanız, koddaki tüm mantıksal olasılıkları test ettiğiniz anlamına gelmez.

3. Koşul Kapsamı (Condition Coverage)

Karar kapsamının bir adım ötesidir. Tek bir if bloğunun içinde birden fazla mantıksal operatör (AND, OR) varsa, her bir alt bileşenin (koşulun) kendi içinde hem True hem de False durumunu tetiklemeyi hedefler.

Mülakat İpucu: if (isUserLoggedIn && isPaymentApproved) ifadesini ele alalım. Karar Kapsamı sadece bu parantezin içinin toplamda True ve False çıkmasıyla ilgilenir (2 senaryo). Koşul Kapsamı ise isUserLoggedIn değişkeninin ayrı, isPaymentApproved değişkeninin ayrı ayrı True/False durumlarını altüst etmenizi bekler.

Sektörel Araçlar ve CI/CD Entegrasyonu

Backend ve frontend ekosisteminde bu kapsamları ölçmek için mimarinize uygun şu popüler araçları CI/CD pipeline hatlarınıza entegre edebilirsiniz:

• JaCoCo: Java ve Spring Boot dünyasının sektör standardıdır. Hem komut hem de dal (branch) kapsamlarını detaylı HTML raporları olarak sunar.

• Istanbul (nyc): JavaScript ve TypeScript (Node.js/Next.js) projelerinde otomasyon veya birim testlerin kapsam oranını ölçmek için sık tercih edilen kütüphanedir.

• Coverage.py: Python tabanlı geliştirilen backend servislerinde kapsam analizini eksiksiz çıkaran popüler bir araçtır.

Kapsam Hedefleri ve %100 Kapsam Tuzağı

Sektörde genel kabul gören başlangıç barajı %70 - %80 arası bir kod kapsamıdır. Ancak bu oran projenin risk analizine göre esnemelidir. Kritik bir ödeme modülü %95+ kapsam hedeflerken, daha az riskli servislerinde bu oran esnetilebilir.

Bu arada %100 kod kapsamı, kodun hatasız olduğunu kanıtlamaz. Geliştirici koddaki tüm satırları ve branch'leri tetikleyen bir test yazmış olabilir; fakat bu durum, koda yanlış yazılmış bir iş mantığını veya tamamen unutulmuş bir gereksinimi (missing requirement) yakalayamaz. Başarılı bir mühendis, kod kapsamıyla koddaki kör noktaları tespit ederken; gereksinim kapsamıyla da sistemin iş mantığını güvence altına alır.