Ne kadar test yeter? Test piramidi, kapsama oranı ve kararsız testler

Test otomasyonunda doğru soru "kaç test yazmalıyız" değil, "bu testler nereye yığılmış". Üç şey belirleyici: dağılım, geri bildirim süresi ve güvenilirlik. Dağılım için en çok atıf alan referans Google'ın önerdiği kabaca yüzde 70 birim, yüzde 20 entegrasyon, yüzde 10 uçtan uca oran. Geri bildirim için DORA'nın eşiği net: geliştirici sonucu on dakikanın altında görmeli. Güvenilirlik içinse tek ölçüt var, kırmızı gördüğünüzde ona inanabilmeniz. Kapsama oranı bu üçünün hiçbirinin yerine geçmez. Nerede test olmadığını gösteren bir teşhis aracıdır, tutturulacak bir hedef değil.

Piramidin arkasındaki hesap

Terim Mike Cohn'un 2009 tarihli Succeeding with Agile kitabıyla yayıldı, Martin Fowler 2012'de yazdığı kısa yazıyla kalıcı hâle getirdi. Mantığı basit: piramitte yukarı çıktıkça test pahalılaşır. Yazması pahalılaşır, çünkü daha fazla parçayı ayağa kaldırmanız gerekir. Koşması pahalılaşır, saniyeler dakikalara döner. En pahalı kısmı da teşhis: birim test kırıldığında hangi fonksiyonun bozulduğunu bilirsiniz, uçtan uca test kırıldığında yedi katmandan hangisinin bozulduğunu araştırırsınız.

Google'ın test ekibi 2015'te bu dengeyi bir orana bağladı, ama yazının asıl değeri oranda değil gerekçede. Uçtan uca testlerin derdi yavaş olmaları değil sadece. Kırıldıklarında sorunun ürün kodunda mı yoksa test altyapısında mı olduğunun günler alması. Ekibin bir haftasını bir teste harcayıp sonunda hatanın uygulamada değil test ortamında olduğunu bulması, o testin gerçek maliyetidir.

Ters piramit tercihle değil, kolaylıkla oluşuyor

Çoğu ekip piramidi bilerek ters çevirmiyor. Elinizde hiç testi olmayan bir sistem varsa en hızlı sonuç veren yol arayüzden kayıt yapan bir senaryo yazmaktır: tek test on ekranı birden dolaşır, bir haftada tablo güzelleşir. Bir yıl sonra elinizde 400 tane böyle test olur, koşum süresi kırk dakikayı bulur ve her koşumda birkaç tanesi nedensiz kırılır.

Google'ın 2017'de paylaştığı analiz bunun neden kaçınılmaz olduğunu gösteriyor: test ikilisinin boyutu büyüdükçe kararsızlık olasılığı da büyüyor, ilişki kabaca doğrusal. Yani "büyük testler daha çok kırılır" bir izlenim değil, ölçülmüş bir eğilim. Buradan çıkan sonuç büyük test yazmayın değil, kaç tane yazdığınıza dikkat edin.

Kararsız test bir rahatsızlık değil, güven kaybı

Google'ın kendi paylaştığı rakama göre test tabanının yaklaşık yüzde 16'sı bir noktada kararsız davranıyor. Yani yaklaşık her yedi testten biri, ne kod ne de test değişmediği hâlde ara sıra kırılıyor. Bu ölçekte bir şirketin bile kurtulamadığı bir şeyden sizin de kurtulmanız beklenmiyor. Asıl zarar oranda değil, oranın yarattığı alışkanlıkta: "yeniden çalıştır, geçer" yerleşince kırmızı bir bilgi olmaktan çıkar.

Aynı ekipten gelen bir gözlem bu alışkanlığın bedelini gösteriyor. Kararlı bir test kararsızlaşıp bu belirli bir kod değişikliğine bağlanabildiğinde, altı vakadan birinde sorun test tarafında değil üretim kodunda çıkmış. Otomatik yeniden deneme, o altıda biri sessizce çöpe atar. İşleyen yaklaşım şu: kararsız testi silmeyin, karantinaya alın, ama karantinanın bir sahibi ve bir tarihi olsun. Sahipsiz karantina, silmenin yavaş çekimidir.

Kapsama oranını hedefe çevirdiğinizde ne oluyor

Fowler'ın cümlesi kısa: bir kapsama seviyesini hedef hâline getirirseniz insanlar ona ulaşır. Ulaşma biçimi de tahmin edilebilir. İddiası olmayan testler, kodu çalıştırıp hiçbir şey doğrulamayan çağrılar, getter ve setter turları. Sayı yükselir, güvence yükselmez. Fowler'ın kendi beklentisi, düzgün test alışkanlığı olan bir ekipte oranın doğal olarak yüzde 80'lerin üstünde ya da yüzde 90'larda çıkacağı yönünde. Yüzde 100 gördüğünde şüpheleniyor, yüzde 50'nin altını ise gerçek bir sorun sayıyor. Rakam bir çıktı, girdi değil.

Google'ın pratiği aynı yere çıkıyor. Şirket genelinde zorunlu bir kapsama eşiği yok. Yayımladıkları rehberde yüzde 60 kabul edilebilir, yüzde 75 takdire değer, yüzde 90 örnek gösterilebilir diye bir çerçeve veriliyor, hemen ardından yukarıdan dayatmadan kaçındıkları ve eşiği her ekibin kendi işine göre seçmesi gerektiği söyleniyor. İlginç kısım şu: zorunlu olmamasına rağmen kullanım kendiliğinden yayılmış, 2018'in ilk çeyreğinde projelerin yüzde 90'ından fazlası kapsama araçlarını kullanıyormuş. Uygulamada işe yarayan ayar da oranı depo geneline değil değişen koda bakarak okumak. Kod incelemesinde "bu değişiklikte eklenen satırların ne kadarı test ediliyor" sorusunun cevabı, beş yıllık toplam yüzdeden çok daha fazla iş görür.

Kapsama yerine bakılacak şey: testler gerçekten yakalıyor mu

Kapsama bir satırın çalıştırıldığını söyler, doğrulandığını söylemez. Aradaki farkı ölçen yöntem mutasyon testi. Araç kodunuza kasıtlı küçük hatalar yerleştirir, bir karşılaştırma operatörünü değiştirir ya da bir dönüş değerini boşa çevirir, sonra testlerinizin bunu yakalayıp yakalamadığına bakar. Yakalamıyorsa o satır kapsam içinde görünse bile korumasızdır.

Google'ın 1.000'den fazla proje ve 24.000'den fazla geliştirici üzerinde yürüttüğü çalışma yöntemin ham hâlinin işe yaramadığını da gösteriyor: geliştiriciler bildirilen mutantların yüzde 85'ini işe yaramaz olarak işaretlemiş. Çözüm aracı tüm depoya salmak yerine yalnızca incelemedeki değişikliğe uygulamak ve mutantları filtrelemek olmuş. Aynı çalışmanın kayda değer bulgusu ise şu: mutasyon testi uygulanan projelerdeki geliştiriciler, yalnızca kapsama oranına bakan projelere göre zaman içinde daha fazla test yazıyor. Java tarafında PIT, JavaScript ve C# tarafında Stryker ile bunu küçük ekiplerde de deneyebilirsiniz. Kuralı unutmayın: depo geneline değil, değişen dosyalara.

Entegrasyonlarda uçtan uca test yerine sözleşme testi

Birden fazla servisin ya da bir ERP ile bir e-ticaret sitesinin birlikte çalıştığı yerlerde piramidin tepesi hızla şişer, çünkü "gerçekten çalışıyor mu" sorusunun tek cevabı her şeyi birden ayağa kaldırmak gibi görünür. Sözleşme testi bu varsayımı kırar. Çağıran taraftaki servis, karşı taraftan tam olarak neye ihtiyacı olduğunu bir sözleşme dosyasına yazar; sağlayıcı da kendi hattında bu sözleşmeye hâlâ uyduğunu doğrular. İki sistem hiçbir zaman aynı anda ayağa kalkmaz, uyumsuzluk yine de yakalanır.

Kazanç iki yerde. Birincisi süre: paylaşılan ortamda on beş yirmi dakika süren entegrasyon koşumlarının sözleşme doğrulamasıyla birkaç dakikaya indiği raporlanıyor. İkincisi ve daha önemlisi zamanlama. Uçtan uca test kırıldığında bozan değişiklik çoktan birleşmiş ve ortak ortama dağıtılmıştır; sözleşme testi ise aynı değişikliği birleşmeden önce durdurur. Pact bu işin en yaygın aracı. Senkronizasyonun tam olarak nerede ve neden bozulduğunu ERP ve e-ticaret veri senkronizasyonu yazımızda ayrıntılı ele almıştık.

On dakika kuralı ve testlerin sahibi

DORA'nın test otomasyonu maddesinde açık bir eşik var: geliştirici sonucu on dakikanın altında görmeli. Bunun üstüne çıkan her dakika, geliştiricinin başka işe geçmesi ve dönüp bağlamı sıfırdan kurması demek. Süreyi düşürmenin yolları sıradan ama etkili: koşumu paralelleştirin, takımı ikiye ayırın (her gönderimde hızlı olanlar, gecelik koşumda yavaş olanlar), değişen dosyalara göre test seçimi yapın.

Aynı maddenin ikinci bulgusu sahiplik üzerine. Testleri geliştiricilerin yazıp bakımını üstlendiği ekiplerde teslimat performansı daha yüksek çıkıyor. İş ayrı bir birime devredildiğinde iki şey oluyor: kırılan testler kimsenin işi olmadığı için öylece duruyor, ve geliştiriciler test edilmesi zor kod yazıyor. Bu, test uzmanına gerek yok demek değil. Keşif testi, kullanılabilirlik değerlendirmesi ve takımın kendisini geliştirmek uzmanlık isteyen işler. Ama günlük bakım yükü kodu yazanın üstünde kalmalı.

Yapay zekâ testleri: kapsama artıyor, güvence tartışmalı

2026 Mart'ında yayımlanan bir çalışma açık kaynak projelerdeki 2.232 test commit'ini inceledi ve test ekleyen commit'lerin yüzde 16,4'ünün yapay zekâ ajanları tarafından yazıldığını buldu. Oran projeden projeye çok değişiyor: 600'den fazla katkıcısı olan büyük bir depoda yüzde 1,9, beş kişilik bir projede yüzde 100. Aynı çalışma üretilen testlerin insan yazımı testlere göre daha fazla iddia içerdiğini de gösteriyor, medyanda 2'ye karşı 1.

Daha fazla iddia otomatik olarak daha iyi test demek değil. Tek testin içine yığılan iddialar, test kırıldığında hangisinin kırıldığını bulmayı zorlaştırır. Asıl risk ise incelemede: derlenen ve kapsama oranını yükselten bir test, itiraz edilmesi zor olduğu için geçer. Ucuz bir savunma var. Yeni gelen testin doğruladığı satırı kasıtlı bozun; test kırılmıyorsa o test hiçbir şey doğrulamıyordur. Bu kontrolü yapay zekâ üretimi testlerde standart hâle getirin.

Testi olmayan bir sistemde ilk üç hafta

Sıfırdan kapsamlı bir takım kurmaya çalışmayın. Birinci hafta: para ve veri kaybının geçtiği yolları listeleyin, ödeme, sipariş oluşturma, stok düşme, yetki kontrolü, ve yalnızca bunlar için uçtan uca test yazın. Beş taneyi geçmesin. İkinci hafta: bu yolların içindeki iş kurallarını birim testle örtün, fiyat hesabı, indirim, vergi, iade koşulu. Hataların çoğu bu kuralların kenar durumlarında oturur. Üçüncü hafta: takımı dağıtım hattına bağlayın ve koşum süresine sert bir tavan koyun.

Sonrası için tek bir kural yeterince güçlü: üretimde çıkan her hata, düzeltilmeden önce kırılan bir testle belgelensin. Bu alışkanlık test takımınızı kimsenin tahminine göre değil, sizin gerçek hata profilinize göre büyütür. Hattı nasıl kuracağınızı küçük ekipler için CI/CD yazımızda anlattık. Testsiz kalmış geniş bir kod tabanında hangi dosyadan başlayacağınızı seçmek içinse teknik borcu ölçme ve önceliklendirme yazısındaki sıcak nokta yöntemi işinizi görür.