Test kapsamı, gereksinimlerinizin, akışlarınızın ve davranışlarınızın çalışan bir test tarafından gerçekten doğrulanan yüzdesidir. Test kapsamı hissi ise Confluence'taki 200 test senaryosuna bakıp anlamlı bir şeyler olduğunu varsaymaktır.
Bunlar aynı şey değil. Canlı ortam hataları da tam bu ikisinin arasındaki boşlukta yaşıyor.
Yüksek Test Senaryosu Sayısı Neden Sahte Güven Yaratır
Araştırmalar bu konuda net: kod kapsamı (code coverage) size kodun hangi bölümlerinin çalıştırıldığını söyler. Test kapsamı ise hangi risklerin kullanıcının bakış açısından incelendiğini söyler. Çoğu ekip ilkini ölçer ve ikincisine de sahip olduğunu varsayar.
Bir dokümanında 200 test senaryosu olan ekibin 200 test senaryosu vardır. Açıkça eşleştirmedikleri sürece sahip olmadıkları şey ise şu sorulardan herhangi birinin yanıtıdır:
- Bu test senaryolarının kaçı gerçekten önemli olan entegrasyonları kapsıyor?
- Kaçı iki sprint önce kullanımdan kaldırılmış akışları anlatıyor?
- Kaçı, özelliğin yazıldıktan sonra önemli ölçüde değişmiş bir sürümü için yazıldı?
- Kaçı birbiriyle örtüşüyor, yani aynı mutlu yolu (happy path) beş farklı şekilde kapsarken koca uç durumlara hiç dokunmuyor?
Araştırmalar, kurumların %81'inin hâlâ ağırlıklı olarak manuel teste dayandığını gösteriyor. Otomasyona girişen ekipler arasında ise yalnızca %19,3'ü test kapsamının %50'sinden fazlasını otomatikleştirmiş durumda. Yani çoğu ekip için mevcut kapsam manueldir, test uzmanının muhakemesine ve zaman baskısına bağlıdır ve kimsenin güncellemediği her dokümanı etkileyen aynı eskime sorununa açıktır.
Entegrasyon Kapsamına Özgü Sorun
En ciddi canlı ortam hataları entegrasyonlarda saklanır. Tek bir özelliğin ana akışında değil. Özellikler arasındaki handoff'ta. Servisler arasında. Ürününüz ile bağlandığı üçüncü taraf sistemler arasında.
Bir ekip %100 kod kapsamına ulaşıp yine de hatalarla karşılaşabilir. Bir fonksiyon test ediliyor ama doğrulama dönüş değerini doğru kontrol etmiyorsa, kod yanlış sonuç döndürürken kapsam raporu yeşil görünür. Aynı mantık entegrasyon düzeyinde de geçerlidir: testler, sınırdan gerçekte neyin geçtiğini doğrulamadan entegrasyon yolunu çalıştırabilir.
Entegrasyon kapsamı, zaman baskısı altında ilk atlanan şeydir de. Birim testleri hızlıdır. Entegrasyon testleri yavaştır, ortam kurulumu gerektirir ve teşhisi daha zor biçimlerde bozulur. Ekipler de onları arka plana atar. Kapsam raporu boşluğu göstermez. Test senaryosu sayısı boşluğu göstermez. Boşluğu canlı ortamdaki olay gösterir.
Kullanımdan Kalkmış Akış Sorunu
Her ekibin, artık yazıldığı haliyle var olmayan özellikler için test senaryoları vardır. Özellik yayınlandı, üzerinde iterasyon yapıldı, şekil değiştirdi ve test senaryoları onu takip etmedi.
2024 State of Testing raporu, kurumların %50'sinin canlı ortama kaçan hataların maliyetini ölçmediğini ortaya koydu. Kaçan hataları ölçmüyorsanız, test senaryolarınızdan hangilerinin gerçekten bir şeyler yakaladığını, hangilerinin ise artık ürününüzü temsil etmeyen akışları test ettiğini belirleyecek bir geri bildirim mekanizmanız yoktur.
Kullanımdan kalkmış test senaryoları zararsız değildir. Çalıştırma süresi tüketir, sahte başarı oranlarına katkıda bulunur ve gerçek boşlukları ortaya çıkaracak kapsam analizine yer bırakmaz. 200 test senaryosu koşturup 180 başarılı sonuç alan bir ekip kendinden emin hisseder. O 200 testin 40'ı artık var olmayan akışları test ediyorsa, bu güven aritmetik bir kurgudur.
Gereksinim Kapsamı Gerçekte Neyi Ölçer
Anlamlı kapsam metriği kaç testiniz olduğu değildir. Gereksinimlerinizin kaçına bir test senaryosunun eşlendiğidir.
TestRail, gereksinim kapsamını mevcut testlerin kapsadığı gereksinim sayısının toplam gereksinim sayısına bölünmesi ve yüzde olarak ifade edilmesi şeklinde tanımlıyor. Bu formül, yazılım özelliklerinin tamamının ya da çoğunluğunun QA tarafından kontrol edildiğini doğrulamak açısından özellikle önemli.
Çoğu ekip bu soruyu yanıtlayamaz. Test senaryoları, doğrulamaları gereken gereksinimlerle hiçbir bağlantısı olmayan bir dokümanda ya da araçta durur. Gereksinimler Jira'da yaşar. Test senaryoları Confluence'ta ya da bir tabloda yaşar. Aralarındaki bağ, yalnızca birinin testin yazıldığı güne dair hafızasında vardır.
Gereksinim değiştiğinde test senaryosunun bundan haberi olmaz. Yeni bir gereksinim eklendiğinde ona hiç test senaryosu yazılmayabilir. Derinliği olmayan yüksek kapsam yüzdesi sahte bir güvenlik hissi verebilir, en riskli hatalar ise keşfedilmeden kalır. Ekipler, gerçekten önemli testleri yazmak yerine rakamı tutturmaya daha çok zaman harcayabilir.
Kapsam Boşluğu Bir Keşif Sorunudur
Göremediğiniz kapsam boşluklarını kapatamazsınız. Kapsam boşluklarının çoğu da doğası gereği görünmezdir.
Test senaryosu sayıları boşlukları göstermez. Başarı oranları boşlukları göstermez. Yeşil CI build'leri boşlukları göstermez. Bir kapsam boşluğunu gösteren tek şey, test senaryolarınızı gereksinimlerinizle eşleştirmek ve testi olmayan gereksinimleri, güncel bir gereksinimi olmayan testleri ve gereksinimi test yazıldıktan sonra değişmiş testleri belirlemektir.
Test kapsamı izlenebilirliğini hayata geçirmek, gereksinimler ile test senaryoları arasındaki bağlantıları net biçimde ortaya koyabilir. Bir hatayı uygulama yayınlanmadan önce yakalasanız bile, bu hatanın ilk ortaya çıkışının üzerinden günler ya da aylar geçmiş olabilir. Bu da izini sürmeyi bir o kadar zorlaştırır. Düzeltmek, hatadan sonra yazılmış pek çok kodun yeniden düzenlenmesini gerektirebilir. Bu, geliştirme maliyetlerini ciddi biçimde artırır ve yayın takvimini geciktirir.
Boşluğu ne kadar erken bulursanız o kadar ucuza gelir. Sprint planlamasında bulunan bir kapsam boşluğunun maliyeti bir test senaryosudur. Canlı ortamda bulunan bir kapsam boşluğunun maliyeti ise bir olay, bir hotfix ve kullanıcı güvenidir.
Gerçek Kapsam Nasıl Görünür
Gerçek kapsam bir sayı değildir. Bir eşlemedir. Her test senaryosunun izi bir gereksinime kadar sürülebilir. Her gereksinimin en az bir test senaryosu vardır. Bir gereksinim değiştiğinde etkilenen test senaryoları görünür olur. Yeni bir gereksinim eklendiğinde test senaryosunun yokluğu görünür olur.
Bunun için test senaryosunun ve gereksinimin aynı sistemde olması ya da en azından birbirine bağlı olması gerekir. Ayrı ve bağlantısız dokümanlar olduklarında eşleme hemen bozulmaya başlar. Mühendisler gereksinimi günceller ama test senaryosunu güncellemez. Boşluk büyür. Kapsam sayısı aynı kalır.
Test Senaryolarınızın Bir Yarı Ömrü Var yazımızda ele aldığımız gibi, test senaryolarını gereksinimlere bağlı tutmanın bakım yükü gerçek ve süreklidir. Ama alternatifi daha düşük bir bakım yükü değildir. Canlı ortam olaylarına dönüşen görünmez boşluklardır.
LLM Yalnızca Yapıştırdığınızı Görür yazımızda da belirttiğimiz gibi, bir gereksinimin bir parçasından test senaryosu üretmek kapsam boşluklarını kapatmaz. Gereksinimin yapıştırmayı hatırladığınız kısmı için makul görünen testler üretir, spesifikasyonun geri kalanı ise test edilmeden kalır.
Her iki durumda da çözüm aynı: test senaryolarını gerçek tek doğru kaynağınızdan üretin, test ile gereksinim arasındaki bağlantıyı koruyun ve kapsam boşluklarını canlı ortam hatasına dönüşmeden önce görünür kılın.
Öne Çıkanlar
- Test senaryosu sayısı kapsam değildir. Kapsam, kendisine doğrulanmış ve güncel test senaryoları eşlenmiş gereksinimlerin yüzdesidir.
- Kurumların %81'i ağırlıklı olarak manuel teste dayanıyor. Otomasyona girişenler arasında yalnızca %19,3'ü kapsamının yarısından fazlasını otomatikleştirmiş durumda.
- Kurumların %50'si canlı ortama kaçan hataların maliyetini ölçmüyor. Bu da kapsam boşluklarını ortaya çıkaracak geri bildirim mekanizmasını ortadan kaldırıyor.
- Entegrasyon akışları, en sık kapsam dışı kalan alandır. Zaman baskısı altında arka plana atılır ve kapsam raporlarında görünmez.
- Kullanımdan kalkmış test senaryoları, başarı oranlarını şişirerek ve gerçek boşlukları maskeleyerek kapsam analizine doğrudan zarar verir.
- Gerçek kapsam izlenebilirlik gerektirir: her test senaryosu bir gereksinime, her gereksinim bir test senaryosuna eşlenmelidir.
Sıkça Sorulan Sorular
Test kapsamı ile kod kapsamı arasındaki fark nedir?
Kod kapsamı, test sırasında kaynak kodunuzun yüzde kaçının çalıştırıldığını ölçer. Test kapsamı ise gereksinimlerinizin, kullanıcı hikayelerinizin ve davranışlarınızın yüzde kaçının doğrulandığını ölçer. Testleriniz doğru davranışı doğrulamıyorsa ya da gereksinim alanlarının tamamını kaçırıyorsa, %100 kod kapsamına sahip olup yine de ciddi test kapsamı boşlukları yaşayabilirsiniz.
Bir test paketindeki kapsam boşlukları nasıl belirlenir?
En güvenilir yöntem izlenebilirliktir: her test senaryosunu doğruladığı gereksinimle eşleştirmek, ardından test senaryosu olmayan gereksinimleri ve güncel bir gereksinimi olmayan test senaryolarını belirlemek. Bu eşleme olmadan boşluklar ancak reaktif olarak, yani bir hata canlı ortama kaçtığında bulunabilir.
Entegrasyon testleri neden birim testlerinden daha sık atlanır?
Entegrasyon testleri daha fazla ortam kurulumu gerektirir, daha yavaş çalışır ve teşhisi daha zor biçimlerde başarısız olur. Sprint baskısı altında ekipler, daha hızlı olan birim testleri lehine onları arka plana atar. Sonuç yüksek birim kapsamı ve düşük entegrasyon kapsamıdır. Bu da canlı ortam hatalarının genellikle kaynaklandığı yerin tam tersidir.
Kullanımdan kalkmış test senaryosu nedir ve neden önemlidir?
Kullanımdan kalkmış bir test senaryosu, artık mevcut ürünle örtüşmeyen bir akışı ya da davranışı doğrular. Teknik olarak hâlâ çalışan bir şeyi test ettiği için istikrarlı biçimde geçebilir, ama mevcut ürün hakkında anlamlı hiçbir şeyi doğrulamaz. Kullanımdan kalkmış test senaryoları, gerçek kapsama hiçbir katkı sağlamadan test sayılarını ve başarı oranlarını şişirir.
Testleri gereksinimlerden üretmek kapsamı nasıl iyileştirir?
Test senaryoları hafızadan ya da metin parçalarından değil, gerçek gereksinimlerden üretildiğinde her gereksinim en az bir test senaryosu ortaya çıkarır. Gereksinimler değiştiğinde gereksinim ile test senaryosu arasındaki bağlantı görünür olur, böylece güncelleme tüm paketin denetimi yerine hedefli biçimde yapılır. Kapsam boşlukları, canlı ortam hatasına dönüşmeden önce görünür hale gelir.
Kaynaklar: PractiTest 2024 State of Testing, TestRail QA metrik kıyaslamaları (2026), Virtuoso QA test kapsamı araştırması (2026), Codecov kapsam analizi, Ranorex test kapsamı rehberi (2025).