Geçen ay İstanbul’da bir fintech ekibinin pipeline’ına baktım. Aynı sahne yine karşıma çıktı: build yeşil, deploy tuşu parlıyor, test tarafı ise… eh, işte öyle. Maalesef. İşin aslına bakarsanız, CI/CD süreçlerinde test aşaması çoğu zaman bir dekor gibi orada duruyor — sanki “biz de test yapıyoruz” demek için konulmuş gibi (en azından benim deneyimim böyle). Oysa kırılgan bir şeyi prod’a iterek sonra yangın söndürmek, iyi kurulmuş bir test katmanından çok daha pahalıya patlıyor. Lafı gevelemeyeyim: test yoksa otomasyonun yarısı boşa gidiyor, nokta.
Bu yazıda “unit test, integration test, E2E” diye listeleyip geçmeyeceğim. Gerçek hayattan bakacağım çünkü küçük bir startup ile kurumsal ekip aynı testi aynı şekilde kullanmıyor — hatta bazen aynı kelimeyi telaffuz ediyorlar ama kastettikleri şey bambaşka oluyor. Bunu 2023’te Ankara’daki bir SaaS projesinde net gördüm: ekip smoke test ile sanity test’i birbirine karıştırıyordu ve her release öncesi ufak panikler patlak veriyordu. Kafa karışıklığı olunca pipeline da saçmalıyor, açık konuşayım.
Test katmanı neden bu kadar kritik?
Açıkçası, Build aşaması size tek bir şey söyler: “Kod derlendi, paket oluştu.” Güzel. Ama yeterli değil. Çünkü derlenen şeyin çalışması başka, doğru çalışması başka… ve bazen en sinsi hata tam da burada sessizce oturuyor: uygulama açılıyor ama yanlış veri gösteriyor, kimse fark etmiyor.
Evet, doğru duydunuz.
Ben buna mutfak örneğiyle bakıyorum — biraz klişe ama doğru. Yemek pişti diye tadı güzel olacak diye bir kural yok; önce kokusuna bakarsınız, sonra tadına, ardından misafire servis edersiniz. CI/CD’deki test de aynen (belki yanılıyorum ama) öyle: kaba kontrol, detaylı kontrol, en sonda kullanıcı senaryosu. Sırayı atlarsanız misafir zehirlenir, mecazi olarak tabii.
Test katmanı iyi kurulmamış bir pipeline hızlıdır ama güvenilir değildir; güvenilir olmayan hız ise genelde pahalıya patlar.
Hangi test neyi koruyor?
Dürüst olmak gerekirse, Konu biraz dallanıp budaklanıyor — ama mantık aslında basit. Her test türü farklı bir risk alanını kapatır, hepsi bu. Siz ne dersiniz? Unit test kodun minik parçalarını tutar; integration test parçaların birbirini bozup bozmadığını kontrol eder; E2E ise tüm akışı kullanıcı gözüyle yürütür.
Çok konuştum, örnekle göstereyim.
Bir de şu var. Herkes E2E’ye bayılıyor çünkü demo hissi veriyor, “bak sistemi baştan sona test ettik” diyebiliyorsunuz. Ama son yıllarda birkaç projede tam tersini gözlemledim — E2E sayısı arttıkça bakım yükü de şişiyor. Ekip yavaşlıyor, hem de fark edilmeden. Kağıt üstünde süper görünen şey, pratikte ağır gelebiliyor. Beklediğim kadar değildi dediğim yer tam da burası oldu.
Unit testing
Unit test benim gözümde ilk kapıdır. Fonksiyon ne yapacaksa onu yapıyor mu? İş orada bitiyor mu? Evet, büyük ölçüde evet. Validasyonlar, dönüşümler, edge case’ler… Bunlar unit seviyesinde yakalanınca hata büyümeden kapanıyor, başka bir şeye bulaşmadan.
Bilhassa de de para hesaplama ya da tarih işlemleri olan modüllerde unit testi eksik bırakmamaya çalışırım. Nisan 2024’te İzmir’de birlikte çalıştığım bir ekipte tek satırlık tarih farkı hesabı yüzünden yanlış fatura kesiliyordu; iki tane unit test o hatayı direkt yakalamıştı, insan eli değmeden. Küçük gibi duran meseleler büyük fatura kesiyor işte.
Integration testing
Integration testi biraz daha sosyal biri gibidir — sistem parçalarının birbirine nasıl selam verdiğine bakar, diyelim. Servis çağrısı veriyi çekiyor mu? API mock düzgün mu? Veritabanı bağlantısı kopuyor mu? Bunları görmek için birebir.
Dürüst olayım: entegrasyon tarafı bazen sıkıcı gelir çünkü ortam ister, veri ister, düzen ister… Ama burası atlanırsa sonra “neden local’de çalışıyordu ki?” cümlesi havada uçuşur. Benim en favori vakam buydu mesela — geliştirici harika çalışan feature teslim ediyor, tek başına muhteşem, ama staging’e çıkınca üçüncü servisten cevap gelmediği için her şey duruyor (buna dikkat edin). Sessizce. Kimse anlamıyor. Saatler geçiyor.
E2E testing
İtiraf edeyim, E2E testi görünce insanlar genelde heyecanlanır. Gerçek kullanıcı yolculuğunu taklit ediyor çünkü — login olunuyor, kayıt açılıyor, sipariş geçiliyor, form gönderiliyor (buna dikkat edin). Eğer bu zincir kırılmazsa iç rahat eder.
İtiraf edeyim, Ama E2E’nin gizli bedeli var. Yavaştır. Kırılgandır, özellikle UI değişikliklerinde. O yüzden her şeyi E2E’ye taşımak bana pek akıllıca gelmiyor — az ama hayati akışları kapsasın yeter diyorum. Mesela ödeme akışı veya ana giriş yolu gibi. Onlar olmazsa olmaz; geri kalanı tartışılır. Daha fazla bilgi için WhatsApp’ın Yeni Yüzü: Sohbetler, Durumlar ve Küçük Bir Sürpriz yazımıza bakabilirsiniz.
| Test Türü | Neyi Korur? | Ana Artısı | Zayıf Noktası |
|---|---|---|---|
| Unit | Tek fonksiyon / yöntem | Çok hızlı ve erken hata yakalar | Sistemin bütününü göstermez |
| Integration | Bileşenler arası iletişim | Mimari sorunları yakalar | Daha fazla kurulum ister |
| E2E | Tam kullanıcı akışı | Kullanıcı gözüyle güven verir | Yavaş ve kırılgan olabilir |
Klasik ara filtreler: Smoke ve Sanity nerede duruyor?
Pek çok kişi bu iki kavramı karıştırıyor. Haklılar da, isimler yakın duruyor ama görevler farklı. Smoke testi kaba kuvvet kontrolüdür — uygulama ayağa kalktı mı? Ana rota açılıyor mu? Giriş ekranı cevap veriyor mu? Hepsi bu kadar. Ciddi bir şey beklemeyin ondan.
Ankara’da geçen yıl katıldığım küçük bir ürün sprintinde tam olarak Şubat 2025’ti — smoke testi atladıkları için gece yarısı alarm aldılar. Uygulama build olmuştu ama ana sayfa bir CSS bağımlılığı yüzünden çöküyordu. Smoke olsa beş dakikada anlaşılırdı. Beş dakika. Onun yerine gece iki buçukta herkes uyandı. MCP ve A2A: 2025’te Çok Ajanlı Mimari Neden İkisine de Muhtaç? yazımızda bu konuya da değinmiştik. Daha fazla bilgi için PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza bakabilirsiniz.
Çok konuştum, örnekle göstereyim.
Sanity ise daha hedefli gelir. Belirli bir değişiklikten sonra “bu dokunduğum yer hâlâ sağlam mı?” sorusuna cevap verir. Bug fix sonrası çok değerlidir. Refactor’dan sonra nefes aldırır. Ama kapsamlı regresyon yerine geçmez — asla geçmez!
Kısaca ayrım nasıl yapılır?
- Smoke: Sistem yeterince ayakta mı?
- Sanity: Değiştirilen kısım hâlâ düzgün mü?
- Error budget: Hayır, buraya girmeyeyim — konu dağılıyor. — ciddi fark yaratıyor
Peki regression olmadan olur mu?
Yani, Kısa cevap: zor olur. Uzun cevap biraz tatsız.
Bakın, Her yeni özellik, eski davranışlardan bazılarını istemeden etkiler — bu neredeyse kaçınılmaz. Bazen sadece kenarda köşede duran bir validasyon bozulur, fark edilmez. Bazen login sonrası yönlendirme sapar, kimse test etmediği için haftalarca öyle kalır. Bazen de hiçbir uyarı vermeden rapor export’u saçmalar ve müşteri sizi arar.
Bak şimdi, Regression testi tam burada devreye giriyor ve geçmiş davranışı koruyan bir bekçi gibi duruyor. En çok da kurumsal projelerde bu katman olmadan release günü kumar masasına dönüyor — gerçekten. Ben bunu kendi gözümle defalarca gördüm. Haziran 2024’te Bursa’daki perakende projesinde küçücük bir fiyat etiketi güncellemesi tüm kampanya hesaplarını bozmuştu; regression seti zayıf olduğu için hata ancak müşteriden geldi. Pek hoş değildi doğrusu.
Hmm, bunu nasıl anlatsamdı…
Küçük startup’ta yaklaşım farklı olur: daha az fakat hayati regression senaryosu seçersiniz, öncelik para kazandıran akışlara gider. Enterprise tarafta ise işler kabarıyor — rol bazlı erişimler, çoklu servis bağımlılıkları, bölgesel varyasyonlar, uyumluluk kontrolleri… Regression listesi uzadıkça uzar.
Şimdi gelelim pratik tarafa: iyi tasarlanmış bir regression paketi illa yüzlerce teste ihtiyaç duymuyor. Ama stabil olmalı, sahipliği belli olmalı ve sık sık revize edilmeli. Aksi halde yaşayan belge değil, tozlu raf olur. İşte en sinir bozucu nokta da bu zaten.
Koddan ziyade strateji önemli mi?
# Basit bir CI mantığı örneği
jobs:
— build
— smoke_test
— unit_test
— integration_test
— e2e_test
— deploy
rules:
if build_success == true and smoke_success == true:
continue_pipeline()
else:
stop_pipeline()Küçük ekipler ile büyük organizasyonların farkı ne?
Küçük ekiplerde hız baskın gelir. İki geliştirici varsa kimse on ayrı environment kurmak istemez; o yüzden hızlı koşan unit testleri ve birkaç can alıcı integration testi çoğu işi halleder. Hani her şeyi kusursuz yapmak yerine işleri döndürmek gerekir ya — tam o çizgide ilerlenir.
Bir şey dikkatimi çekti: Kurumsal tarafta ise durum değişiyor; orada hata maliyeti yüksek olduğu için kalite kapıları çoğalır. QA ekibi vardır, release manager vardır, bazı projelerde security taramalarıyla gelen ekstra kontroller de eklenir. İşe yarar mı? Genelde evet. Ama fazla kapı koyarsanız teslimat hızı düşer — bunu da görmüşümdür. Bu konuyla ilgili OpenRig Neden Doğdu: Ajan Karmaşasına Son Veren Fikir yazımıza da göz atmanızı tavsiye ederim. Bu konuyla ilgili Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza da göz atmanızı tavsiye ederim.
Ben açıkçası hibrit modeli seviyorum: küçük PR’larda hafif gate’ler, main branch’te sertleşen kontroller, prod öncesinde kısa fakat anlamlı son filtreler. Bu denge bayağı iyi oturuyor pratikte.
Ne yalan söyleyeyim, Bir dakika, şunu da ekleyeyim: test otomasyonu tek başına mucize yaratmıyor. Testlerin kendisi kötü yazılmışsa pipeline sadece kötü alışkanlığı hızlandırır. Yani yanlış şeyi otomatikleştirmek — hele hele tutarlı biçimde — ayrı bir dert.
İlginç olan şu ki, Peki hiç hayal kırıklığı yaşamadım mı? Yaşadım tabii. Mart 2026’da baktığım AI destekli bir iç araçta bin küsur snapshot testi vardı ama hepsi gereksiz yere geniş tutulmuştu; sonuçta küçük bir UI değişikliğinde onlarca false positive çıktı. Takım resmen yoruldu. O noktada dedim ki: “Az olsun, öz olsun.” Kaliteli birkaç hayati senaryo, rastgele yığılmış elli zayıf senaryodan kesinlikle iyidir.
Neye odaklanmalı?
- Kritik akışları belirleyin: ödeme, login, kayıt, yetki kontrolü. (bence en önemlisi)
- Pahalı hataları önceleyin: müşteri kaybına yol açan yerleri koruyun. (bence en önemlisi)
- Sahiplik tanımlayın: her setin sahibi belli olsun, kimin neye baktığı net olmazsa bakım düşüyor. (bence en önemlisi)
Sıkça Sorulan Sorular
CI/CD’de testing neden bu kadar önemli?
Bi saniye — Testing olmadan pipeline yalnızca kodu taşıyan hızlı bir bant gibi kalır. Hataları erken yakalamazsanız üretimde hem maliyet hem itibar kaybedersiniz. En büyük fayda, riskleri canlı sisteme gitmeden önce görmek.
Smoke testing ile sanity testing arasındaki fark nedir?
Smoke testing sistemin temel olarak ayakta olup olmadığını kontrol eder. Sanity testing ise belirli bir değişiklikten sonra ilgili kısmın sağlıklı kalıp kalmadığına bakar. Biri geniş buton kontrolü gibiyken diğeri nokta atışı yapar.
Regression testi ne sıklıkla koşulmalı?
En ideali her anlamlı değişiklikten sonra koşmaktır. Büyük takımlarda nightly veya merge sonrası otomatik tetikleme yaygındır (ben de ilk duyduğumda şaşırmıştım). Kritik sistemlerde prod öncesi muhtemelen çalıştırmak gerekir.
Küçük startup için hangi test türleri yeterlidir?
Çoğu durumda güçlü unit testleri, kritik birkaç integration testi ve az sayıda smoke/regression senaryosu yeterli. Her şeyi E2E’ye yüklemek genelde gereksiz ağırlık yaratır. Önce riskin yoğun olduğu yerlere odaklanmak daha akıllıca olur (yanlış duymadınız)
E2E testi neden pahalı bulunur?
Çünkü yavaştır, ortam bağımlılığı yüksektir ve UI değişikliklerinden kolay etkilenir. Bu yüzden sadece gerçekten değer üreten ana kullanıcı akışlarında kullanmak daha mantıklıdır.
Kaynaklar ve İleri Okuma
GitHub Actions Resmi Dokümantasyonu
Azure DevOps Pipelines Dokümantasyonu
Practical Test Pyramid — Martin Fowler
Atlassian Yazılım Test Türleri Rehberi
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
